Как происходит обмен с БД данными в Lineage2?

Question

[MishaXXL]

Как реализован регулярный обмен данными в играх?
В данном случае описываю игру Lineage 2.

1. Каждое открытие инвентаря это запрос к БД (т.е. при стоянии на месте и щелкая кнопку, мы будем нагружать БД запросами)?
2. Каждое выпадение золота в мир это новая запись в общую таблицу мира, что в такой-то точке есть объект "золото"?
3. Что происходит после того, когда золото было поднято, эта запись превращается в null?
4. При интенсивном обороте этих действий, как реализуется такая таблица, чтобы она не переполнялась за неделю?
5. Для игр подходит любая БД (например Postgres) или есть определенный тип игровых БД?

Answer 1

[Saboteur]

1. Каждое открытие инвентаря это запрос к БД (т.е. при стоянии на месте и щелкая кнопку, мы будем нагружать БД запросами)?

Нет. Данные загружаются в оперативку при логине персонажа. Изменения также касаются оперативки. В базу скидывается при логауте. Ну еще периодически для синхронизации.

2. Каждое выпадение золота в мир это новая запись в общую таблицу мира, что в такой-то точке есть объект "золото"?

Да. есть объект "предмет". Есть структура "список предметов", скорее всего двухсторонний список. Он обновляется, в него добавляется, из него извлекается. Предметы в мире не записываются в базу вообще (если вы помните, при ребуте все что не в чьем-то инвентаре, пропадает. Не так уж много оперативки это занимает. Просто посчитайте.
Максимальный онлайн на шарде - 5000 игроков.
Объект - ну учитывая тип предмета, уникальный айди, разные параметры типа заточки, владельца, место, и так далее - 10-20 байт более чем достаточно. Ну давайте 50 байт возьмем, хотя на деле я уже не помню сколько там было, явно меньше.
50 байт * 5000 игроков и скажем 100 предметом у каждого - получим примерно 23 мегабайта.
Добавить клановые хроанилища. ну 30 мегабайт. Много это оперативки на сегодня? По-моему вообще разговор ни о чем.

3. Что происходит после того, когда золото было поднято, эта запись превращается в null?

Объект удаляется из списка.

4. При интенсивном обороте этих действий, как реализуется такая таблица, чтобы она не переполнялась за неделю?

Нет никаких проблем с тем, чтобы удалить объект и освободить память.
Для оптимизации, можно делать так, что объекты не удаляются из памяти, а "очищаются", то есть структура в памяти остается, просто ее удаляют из основного списка и добавляют в список "нулл объектов". Если их там слишком много, удаляют из памяти, при этом отдельно есть счетчик количества объектов, и если надо создать новый объект, то вместо выделения памяти просто берется уже готовая структура из соседнего списка, заполняется.

5. Для игр подходит любая БД (например Postgres) или есть определенный тип игровых БД?

Любая. В Lineage2 использовался MSSQL, в самописном народном java эмуляторе использовался mysql

Comments

[Владислав Лысков]

Да. есть объект "предмет". Есть структура "список предметов", скорее всего двухсторонний список. Он обновляется, в него добавляется, из него извлекается. Предметы в мире не записываются в базу вообще (если вы помните, при ребуте все что не в чьем-то инвентаре, пропадает.

нет, там всё, что выпало с мобов лежит 5мин, то, что выбросил персонаж, лежит до ребута самого сервера

Нет. Данные загружаются в оперативку при логине персонажа. Изменения также касаются оперативки. В базу скидывается при логауте. Ну еще периодически для синхронизации.

и тут я думаю несколько не так

именно в ла2, коннект с сервером идёт всегда, даже при обычном движжении

[Saboteur]

нет, там всё, что выпало с мобов лежит 5мин, то, что выбросил персонаж, лежит до ребута самого сервера

То, что предметы с мобов автоудаляются это да. Но в базу сохраняется только то, что в инвентаре, а не в мире, акцент был на этом.

именно в ла2, коннект с сервером идёт всегда, даже при обычном движжении

Коннект идет, но синхронизация с базой не мгновенная, а параллельная. В основном для того, чтобы если сервер внезапно упал/был завершен насильно без graceful shutdown, не было слишком большой потери игрового времени.
Если игрок после ребута еще не логинился, его инвентаря в оперативке нет.
Вот после логаута, я не знаю точно выгружается ли из оперативки его стафф - в дебри официального сервера лазить неудобно.
Как минимум в одной другой ММОРПГ мы выгружали. Но это было задолго до линейки. даже в 2004 году вся база предметов не особо нагружала оперативку.
Там вообще основная нагрузка на сервер была из-за АИ мобов и поддержка всех подключений и их трафик.

[Владислав Лысков]

Saboteur, спасибо за разъяснение

[MishaXXL]

Saboteur, т.е. на сервере на каждого подключенного человека создается объект, куда мы вносим данные из БД и обновляем их в нем же до его отключения, после делаем PUT реквест нашего объекта игрока в БД?

И весь мир тоже хранит данные о его состоянии в оперативки, и лишь при падении сервера, он вносит обновленные записи в БД, которые касаются постоянных хранилищ, как клан холы и респ боссов?

По такой логике и чат тоже в оперативке лежит?

Получается не столь важна БД, сколько наличие оперативной памяти на сервере?

Что ваш коллега имел в виду, когда говорил про key-value dbms?

[Евгений Шатунов]

Владислав Лысков, чему и сколько времени лежать на земле - определяется конфигурацией конкретного сервера.
Сам сервер из себя представляет резидентную специализированную базу, но это только если рассуждать терминологически.
На деле же функционал резидентной базы, функции чтения и записи данных, игровые механики и сетевой протокол настолько переплетены между собой и весь этот клубок неделим по своей сути, что лично я бы этот корейский код выкинул бы с диким позором. Он не выдерживает никакой критики.
Традиционная БД там используется как средство бекапа посчитанных данных из резидентной. И дроп данных там идет очень часто, буквально на каждом такте мира для состояния каждой измененной за этот такт сущности.
Загрузку из традиционной БД сервер выполняет, обычно, по требованию. Но часть данных, например база информации о предметах, какие они вообще есть в мире и какие у них свойства, или расы/навыки/классы со всей информацией о них, загружается на этапе запуска и конфигурирования сервера.
После логоффа игрока его сущность еще какое-то время остается в памяти сервера. Чисто на случай повторного быстрого входа. Потому что тянуть игрока из традиционной БД дороже чем подержать лишние 30 минут в резидентной после его выхода. Тут важнее скорость входа игрока и снижение нагрузки на традиционную БД.

[Владислав Лысков]

Евгений Шатунов, вас тоже благодарю за поясняния, когда-то давно я провёл в ней так сказать мягко говоря очень много времени, и спястя годы, когда стал разработчиком, мне было интересно, а же как там это всё устроено
ибо клиент-серверное там как по мне очень сильно отличается от других ммо тех времен (2007г а их было по сути 4 (л2, вов, ева, да, пв)) (но я с геймдевом от слова совсем, поэтому могу заблуждаться)

[Евгений Шатунов]

Владислав Лысков, 2003-й :)
Она вышла в 2003м. Ragnarok Online вышла в 2002м. Rising Force Online - в 2004м. Cabal Online - в 2005м.

И у них у всех +/- схожий протокол. TCP на 4-м уровне OSI, командная структура на 6-м уровне, схожее строение пакета, примерно схожие ограничения по приему-передаче. Примерно схожий расход трафика.

И +/- одинаковые макароны в сетевой части, полное отсутствие понимания модели OSI в коде и, как следствие, характерная для корейского кода простота взлома протокола. Мне в те года, как игроку, за это было весьма обидно. Мне, как разработчику ММО проектов, сейчас весьма тяжело наставлять молодых ребят не то чтобы не повторять тех ошибок Корейцев, а хотя бы не использовать JSON с HTTP в сетевых проектах.

[Saboteur]

, т.е. на сервере на каждого подключенного человека создается объект, куда мы вносим данные из БД и обновляем их в нем же до его отключения, после делаем PUT реквест нашего объекта игрока в БД?

Ну не объект, структура. Структура есть для каждого персонажа (игрока, моба, NPC), для каждого предмета. Структура - вещь не большая, в памяти хранится в виде двухстороннего списка структур (массив тут не очень подходит, так как постоянно идут добавления/удаления). А список легко в этом плане модифицировать.
Список для игроков не связан со списком предметов, там как в реляционных базах - у предметов есть айдишник владельца

И весь мир тоже хранит данные о его состоянии в оперативки, и лишь при падении сервера, он вносит обновленные записи в БД, которые касаются постоянных хранилищ, как клан холы и респ боссов?

БД регулярно и асинхронно обновляется. Например в каждой структуре есть флаг "сохранен или нет". Если структура меняется, флаг скидывается. Потом какой-то поток сохраняет в базу все структуры без флага и устанавливает флаг. Так оптимизировано и безопасно обновляется база относительно текущего состояния в оперативке.

По такой логике и чат тоже в оперативке лежит?

Чату в оперативке вообще нечего делать. Это же просто фраза - появилась, разослалась, скинулась в лог. Логи в базе. Поток который пишет в базу - асинхронный.

Получается не столь важна БД, сколько наличие оперативной памяти на сервере?

Ну как не важна.. без базы игры не будет =), просто она не для того, чтобы постоянно ее дергать для каждой операции.

Что ваш коллега имел в виду, когда говорил про key-value dbms?

Ну тут он ошибся - как минимум для LineageII, да и для игр вообще, реляционные базы вполне даже удобны.

[MishaXXL]

Евгений Шатунов, т.е. ты при желании мог на любом сервере себе шмот нарисовать? )

[MishaXXL]

Saboteur, случайно не знаешь, есть ли какой-то опен сорс сервер л2 на джаве, который многие берут за основу своего?

[Saboteur]

ну поискать можно.
Я этим занимался очень, очень давно. лет 15+ назад, когда еще были 3-4 хроники.
погугли что-то такое

https://forum.monche.org/topic/1001-%D1%81%D0%B1%D...
https://github.com/topics/lineage2

что из этого рабочее и насколько легко завести не скажу..

Answer 2

[mayton2019]

Я не специалист в играх но обычно когда хотят гарантированное время выдачи ответа -
используют key-value dbms,. Они очень хорошо масштабируются и таблица с 10
записями и таблица с 10 миллиардами записей дают примерно одинаковый отклик.

Далее - искусство разработчика - уложить действия с инвентарем и действия с балансом золота
в 1 едиснственную операцию put/get или атомарную операцию с key-value системой.

Из недостатков. Никакие сортировки и группировки использовать нелзя. Если сильно хочется
- создается 1 запись типа JSON и там уже заранее лежат отсортированные дочерние записи.
И такая запись подготавливается в фоновом режиме обычно.