Комментарии 62
А самое главное, что монолит не заточен на построение распределенной архитектуры и, как следствие, обладает низкой эффективностью.
Распределенная (микросервисная) архитектура это в первую очередь про масштаб. Масштаб команды, масштаб нагрузки, масштаб проекта.
Как именно поддерживаются все механики сервера? Передвижение не игроков, а NPC, их социальное поведение, а не тупо стояние на месте. Там многие ходят порыкивают, травку жуют, есть и более сложные поведенческие скрипты.
Расскажите как игроки в вашем мире могут взаимодействовать, например присутствуя в одном городе в количестве 500+ человек? Тут как бы больше на клиент нагрузка идет, и особо нет смысла в поддержании всего на одном месте.
Минусы:
не поддерживает масштабируемость сервисов;
ограничение игроков в 5 тыс. на одной инсталляции;
Кроме поддержки какого-то максимального онлайна, для него должно быть достаточно контента. А его в Lineage2 как раз примерно на 5000 игроков уже впритык. Зачастую на официальном сервере при превышении среднего онлайна в 3000, уже старались регистрироваться на другом шарде. Ну и ограничение в 5000 чисто на уровне кода, его можно убрать и проверить насколько действительно нагрузочный тест покажет.
Плюс существующие сервисы легко разносятся на разные машины, а MSSQL кластеризируется сам по себе.
А не делиться не то, чтобы готовым кодом, а даже простыми вопросами о реализации — ну крутитесь в своем компоте, зачем тогда вообще статья?
Я спрашивал — как вы проверяли, что оригинальный бэкенд не держит подобную нагрузку, если ограничение в 5000 сделано не потому, что сильно перенагружено, а просто для того, чтобы в шард, контент которого рассчитан на 3000-4000 человек, не налезало сверх головы.
Насколько я помню, когда я держал шард еще 4-х хроник, то при наличии онлайна около 1000-2000 человек, больше всего напрягался компонент, отвечающий за поведение NPC. А основной сервер не более 10-15% cpu на древних каких-то двухядерных атлонах и 4 гб оперативки. Да, для 5000 возможно было бы лучше гигабитный канал, а не 100мбитный. Но «шардировать» пространство? Это не поможет, если много игроков соберутся в одном «квадрате». А гигабит легко выдержит 5000 игроков.
Вы ведь тестировали нагрузку, имитируя онлайн, а не проверяя что должно быть с каналом?
Делать универсальный бэкенд для «любой ММО», не вникая в суть этого ММО — явно не подход. Например банальная вещь — Lineage2 — псевдо3д игра. Геодата у нее хитро оптимизирована для минимальной нагрузки на клиент и AI.
Думаете в eve online именно архитектура позволяет 20.000 игрокам играть с минимальными лагами?
Насколько я знаю, eve online — полный 3д, с кучей нюансов. И решить вопрос масштабирования конкретной локации пришлось трюком со временем, а не шардированием пространства на кусочки (что скорее всего практически нереально сделать красиво).
Я спрашивал — как вы проверяли, что оригинальный бэкенд не держит подобную нагрузку
Простите, но где?
10-15% cpu на древних каких-то двухядерных атлонах и 4 гб оперативки
А вы проверяли в текущей реальности свои же показатели, перед тем как написать? Явно же нет.
Вам точно хватило на запуск С4 4гб ОЗУ? Да это же смешно, С4 Retail минимум требует 8гб ОЗУ не считая вспомогательный систем WS.
Вы почему-то в упор не видите очевидной реальности — статья абсолютно не заставляет никого брать и делать сейчас свой L2 сервер, пользуясь этой архитектурой, а наоборот — дает эталон архитектуры, которой не стоит пренебрегать в том или ином проекте. Дальнейшая полемика бессмысленна.
— А как вы решили такую-то проблему?
— Это военная тайна.
— Но всё же, как?
— Не скажу!
— Ладно, поясните тогда, почему ваше решение правильное?
— Идите прочь, я Д'Артаньян!
Дальнейшая полемика бессмысленна.
Вы правы, действительно бессмысленна.
статья абсолютно не заставляет никого брать и делать сейчас свой L2 сервер, пользуясь этой архитектурой, а наоборот — дает эталон архитектуры, которой не стоит пренебрегать в том или ином проекте.
Да, не заставляет.
Однако настолько громкое название статьи («Правильная архитектура MMO эмулятора») и радикальная позиция автора («архитектура подходит к любой игре, и точка») вызывает много вопросов, на которые вопрошающие так и не получают конкретного ответа.
Меня больше впечатлит не 18 тысяч ботов которые просто ходят по миру, а 2-4 тысячи игроков которые дерутся у замка. Причём это обязательно должны быть «живые» клиенты-боты, которые по настоящему подключаются к серверу.
И NPC и мобы так же могут очень сильно нагружать сервера. В некоторых эмуляторах их вообще во время осад отключали, т.к других вариантов не было.
Основная нагрузка при нахождении игроков рядом приходится на сеть и на клиент, а не на CPU.
Отправить сообщение 2000 игрокам с точки зрения CPU несильная разница.
А вот отправить 2000 лишних пакетов?
А 2000 игроков когда кастуют что-то в бою каждые пару секунд — в одной локации это насколько больше трафика нужно отправлять каждому игроку?
При этом опять таки, нагрузка на CPU — не большая.
p.s. Насколько я помню, как раз NPC и составляли основную нагрузку на процессор в оригинальном сервере.
Прикол в том, что серверу совершенно все равно где находятся игроки — рядом или далеко.
А 2000 игроков когда кастуют что-то в бою каждые пару секунд — в одной локации это насколько больше трафика нужно отправлять каждому игроку? При этом опять таки, нагрузка на CPU — не большая.
Нагрузка на CPU, когда игроки находятся в одном месте и воюют — в разы больше, чем когда они в разных местах.
Если одно АОЕ задевает 20 игроков — надо для каждого игрока просчитать повреждения, а там уже десятки формул и проверок. Какой уровень, какой шмот, какие баффы, является противником или союзником. И этих АОЕ каждую секунду так же кидаются десятки.
Ни один сервер не любит массовых баталий. Сейчас это конечно уже не так очевидно, потому что железо стало в десятки раз мощнее и появились SSD, а количество игроков в игровых мирах увеличилось не так значительно.
Фри шард образца 2001года на POL эмуляторе тянул 350 игроков, но уже захлёбывался когда был массовый бой примерно 50х50.
Так же сервер очень плохо переносил «прокачку резиста», когда в одной кучке собиралось по 10-30 игроков и постоянно использовали массовый каст дебаффа друг на друге.
Рост нагрузки при массовом пвп — не линейный. Лучше чтобы дрались 100 кучек по 10 игроков, чем 1000 игроков в одном месте.
Если одно АОЕ задевает 20 игроков — надо для каждого игрока просчитать повреждения, а там уже десятки формул и проверок. Какой уровень, какой шмот, какие баффы, является противником или союзником. И этих АОЕ каждую секунду так же кидаются десятки.
Ну реально, это для современных процессоров просто семечки.
Про фришард, у меня вроде более-менее норм воспоминания, я уже говорил что держал и свой шард, и общался с «коллегами» других шардов.
Основная проблема высокого онлайна упиралась больше не в CPU, а во внешний канал. Из CPU в официальном шарде, напрягался в основном процесс отвечающий за NPC.
И соответственно вопрос о 17.000 живых игроках, я уверен что в первую очередь упрется в то, как организовано сетевое подключение и балансировка игроков, и намекал автору статьи, что имитация 17.000 человек на локалхосте это некорректно. Что 5000 лимит в том же Lineage2 стоял не потому, что он не мог выдержать, а потому что существуют расчету по комфортному количеству людей в созданном контенте, и проблемы с внешним каналом, а не невозможности просчитать нахождение игроков рядом. Плюс опять таки — на стороне сервера просчитать урон это одно. А на стороне клиента отрисовать тысячи игроков рядом, на обычных домашних десктопах?
Архитектура должна оптимизировать в первую очередь то, где находится реальное бутылочное горлышко, а не придуманное.
C EVE Online долго страдали разработчики. И писали об этом.
Там не только в архитектуре дело.
Там очень многое на дизайне висит.
Из примеров (далеко не полных, и все о чем я говорю — не раз писалось CCP):
- из Jita выкинуто вообще все что только можно (миссии агентов, возможность майнить)
- прикрыта возможность запускать слишком много дронов — как порезкой бонусов тому же Dominix'у так и установкой явных ограничений на количество дронов для карриеров с мазершипами (чтобы они не запускали их сотнями за раз — по drone bandwith то могут, и нести на борту их тоже могут)
- полетов на слишком высокой скорости — быть не должно а если игроки находят — ну ребаланс будет значит (речь именно про полеты в локальном гриде)
- Time Delay — мы признаем что система БУДЕТ лагать в некоторых случаях, и в некоторых случаях — зверски. Но пусть хоть одинаково и предсказуемо у всех кто в данной солсистеме. Ну да, послетают таймеры активации но решаемо другими путям
- убирать необходимость для достижения важных целей летать огромными флотами (нет — это осталось, но можно и без этого достичь чего то)
- MSSQL — живет на RAMSAN'ах ("рамдиск в терабайт", если еще не подняли размеры)
- игрокам запретили варпать в ноль на гейты и они начали создавать массово букмарки с читерными схемами (в результате у каждого этих букмарков — десятки тысяч) — ок разрешим в ноль опять но только на ручном управлении а букмарки рядом с гейтами — потрем и запретим делать
- рынок — на отдельные серверы (вроде по регионам деление), как и чат, как и сервисы обслуживающие персонажа
- возможность кому то из руководства конкретной корпорации попросить reinforced-ноду где то за сутки (ну вот знают что вероятно будет мочилово в системе — можно просить).
- из одной системы влиять на другую напрямую — невозможно. ну разве что маркет.
- переход между системами либо через джамп-гейты (при этом джамп-гейт может либо предложить позднее попробовать либо вообще сказать про перегрузку) либо прыжок корабля с джамп-двигателем(они на маяк прыгают и это тоже не мгновенно) либо мобильные порталы можно открыть (некоторые корабли умеют), опять же не мгновенно либо еще некоторая экзотика (вормхолы например) но опять же — это просто переход и сервер несущий целевую ноду даже за некоторое время (пусть даже минуты) знает что будет переход. Система где никого нет — может вообще быть в оффлайне (загрузится когда нужна будет).
кстати там не 20к игроков система держит. она спокойно держит 200-300к игроков в онлайне.
А вот как работает подход, чем то похожий на описанный — можно в SecondLife наблюдать. Куча проблема с переходами между рядом стоящими регионами, особенно если высокий пинг. И пофиксить что-то не особо получается. Хотя потихоньку решают.
Сейчас уже по сути больше ограничение из-за того что само железо не вытянет слишком большой онлайн, без ощутимых лагов. Опять же в этом большей частью архитектура самого сервера виновата.
В ВоВ как раз смена карты (данжи, БГ, остров ночных эльфов) позволяет использовать под каждую локацию отдельную ноду, хоть это и используется только для Battlegrounds.
В ВоВ как раз смена карты (данжи, БГ, остров ночных эльфов) позволяет использовать под каждую локацию отдельную ноду, хоть это и используется только для Battlegrounds.
А вы уверены? Или вы сейчас не о современном ВоВе, а о каком-то древнем? Уже давно при смене локации имеется приличный шанс перелететь на другой шард.
Особенно сильно это проявлялось, когда появилась возможность сделать свою крепость — сделать так, чтобы друзья в пати попали в тот же шард с твоей крепостью — целый квест нещадно приправленный надеждой на рандом.
В общем, не очень комфортно было играть, когда появилось шардирование такое…
Для одного игрока.
https://wowpedia.fandom.com/wiki/Garrison
А войны гильдий и захваты замков там ещё не прикрутили?
Не прикрутят. Большинство игроков в ВоВ не заинтересованы в этих вещах.
Что дает… а хз… Немножко ресурсов…
Скажу лучше так. Как по мне, близзы, чтобы увеличить аудиторию, в какой-то момент начали впихивать всякую несуразную чушь в игру (чушь — именно в контексте «первоначальной» ММО-игры, по отдельности, эти механики вполне себе неплохи).
Это были и «покемоны» — ловишь по Азероту существ и воюешь ими.
Это были и «весёлые фермы» — где мужественный паладин в сияющих доспехах выращивает свеклу и копает картошку.
И «крепость» — одна из механик пришитых белыми нитками, это такой микроменеджмент крепости, наполненный до безобразия одинаковыми повторяющимеся ежедневными заданиями.
Короче забудьте про крепость, скорее всего она вам не понадобится никогда :)
Не совсем. Шардирование и phasing — разные вещи. Если вы про гарнизоны в WoD — там работало фазирование, которое как раз-таки и ломалось довольно часто. Шардирование к тому времени в игре уже было и довольно активно использовалось, начиная с пандарии (предыдущего аддона). Шардинг в WoD можно было увидеть, проходя квест-лайны и стартуя последний квест-сценарий в открытом мире, который незаметно переносил игрока на инстанс-шард со сценарием.
Спасибо за разъяснение.
А вот когда бегая по локации (или по границе локации, точно не помню уже, кажется всё же не по границе), я видел как другой игрок то исчезал, то появлялся, и при этом в чате были сообщения переключения глобальных каналов, и кроме этого у ника игрока был написан сервер, на который я изначально не заходил — это ведь шардинг?
Сейчас же с этим все более-менее нормально.
Насчет фризов — этим и офф-сервера грешат бывает — на любом ЯП можно написать программу так что она будет «константно тормозить» при определенных условиях. К тому же там, из-за их своеобразной архитектуры работы с бд, это приводит к возможности с гарантией дюпать вещи и т.д. Из последнего подобного — косяки на серверах Essence — думаю те кто в теме помнят об этом и о том какой срач на эту тему был на офф форуме у Инновы.
В линейке по сути сейчас самое узкое место — это сетевая часть, а конкретно пакеты и их размеры. И самая проблема как раз таки в ситуациях когда куча игроков тусуется в одном месте — на осадах, в городах и т.п. В эти моменты клиентам летят просто дикие объемы пакетов с состоянием и изменяющимся статусом окружающих игроков, того что они кастуют и т.д. и т.п. Притом сами эти пакеты достаточно немаленькие по размерам. Хотя конечно нцсофт уже несколько хроник подряд старается это дело оптимизировать, делая все больше и больше крупных пакетов динамическими по структуре, т.е. отсылая их не полностью, а только те части что реально изменились.
Ну и еще сам допотопный движок клиента вносит конечно свою лепту. Все же как бы корейцы не старались, но UE2 полноценно в многопроцессорность и все такое не может, так что в ситуациях «куча народа на экране» клиент тормозит и лагает даже на вполне современном железе…
З.Ы. Сам потихоньку вожусь с одной из версий эмуляторов, на базе ветки Phoenix/OverWorld, так что по сути знаю о чем говорю…
CCP вон даже обработку фрагментарных пакетов реализовывали… сейчас правда наверное проще географический распределенные ноды разместить на крупных IX и сделать оптимизацию пакетной обработки через что-то похожее на «Оптимизирующее сжатие трафика»…
Существует несколько настроек клиента, которые позволяют ограничивать видимость PC/NPC
Игроку в этом случае не будут пакеты отправляться? Я думал это только для того, чтобы их на уровне клиента не рисовало.
Про блокирующие read/write-операции у Apache Ignite не понял. Всегда можно сделать async read/write. Данные, кстати, хранятся в оффхипе и, если вам надо получить лишь часть данных, а не весь объект, то такая возможность тоже есть
Что-то это не выглядит как высокая производительность.
Во-первых, не нужно сохранять в persistent каждый чих. Сохранение либо по завершении сделки, либо по решению алгоритма (редкий дроп), либо по таймауту. Всё остальное — in memory.
500k в секунду — это одна NVME'шка DC-уровня.
те почему выбрана именно такая механика Шардирования — почему не выбрана тактика тех же CCP когда шарды привязываются к узлам с максимальной нагрузкой?
А еще не совсем тривиальный вопрос — если я на бегу через границу уроню предмет в зоне одного шарда он у меня останется? или Дуплицируется если я его успею выложить до прохода обновления данных между шардами?
У CCP все несколько веселее — ищите Дев блоги где они рассказывали про физику и логику работы своей системы в 2018-19 годах навряд ли есть что то более новое.
Если что на физике у них RAM-Drive для БД тогда было сейчас скорее всего переехали на IN-memory…
просто при географическом Шардинге у вас встает вопрос передачи данных о взаимодействии больших групп игроков. и что Будет происходить при Обсчете взаимодействия скажем 1000 игроков
Дельта данных каждого игрока уже существует во всех шардах кластера средствами репликации. Так что это особого аффекта не должно вызвать, как и сейчас с перемещением. А взаимодействие игрок-игрок на границах — обмен трафика между шардами.
А еще не совсем тривиальный вопрос — если я на бегу через границу уроню предмет в зоне одного шарда он у меня останется? или Дуплицируется если я его успею выложить до прохода обновления данных между шардами?
Предмет перекочует вместе с игроком в том состоянии, в котором он находился до балансировки. Т.е. тут можно рассмотреть два варианта
1. игрок выбросил предмет в регионе 1, перешел через границу, и видит его в выброшенном месте
2. игрок выбросил предмет в регионе 1 и в этот же момент произошло добавление нового шарда, который сузил границы региона 1 и поделил его напополам. В последствии предмет «перекочевал» обратно к игроку в новый шард.
P.s. чтобы каких-то неочевидных багов не происходило, я блокирую любое телодвижение объектов в мире при «расширении/сужении» кластера, увы операция сама по себе дорогостоящая.
Дельта данных каждого игрока уже существует во всех шардах кластера средствами репликации. Так что это особого аффекта не должно вызвать, как и сейчас с перемещением. А взаимодействие игрок-игрок на границах — обмен трафика между шардами.
и насколько быстро оно работает? Вот два шарда 500 человек в одном 500 человек в Другом — атакуют друг-друга через границу шарда… что-то мне сомнительно что у вас будет происходить всё без проблем — по сути БД будет обновляться Двумя шардами, нагрузка на БД практический удваивается, а то и учетверяется, тк запросы идут под одними тем же объектам для двух шардов, реплики здесь не особо помогут тк взаимодействие идет МЕЖДУ объектами на разных шардах…
В общем думается мне что без механизма динамического шардирвоания который создаст Зону в которую уместятся обе группы игроков и выделит им отдельный шард у вас не будет без явных фризов и багов… технический я бы Шардировал именно по группам игроков по сути генерируя для каждой группы псевдо мир в котором они крутятся и старался бы сделать систему в которой не было вобще привязки к статичным объектам…
Предмет перекочует вместе с игроком в том состоянии, в котором он находился до балансировки. Т.е. тут можно рассмотреть два варианта
1. игрок выбросил предмет в регионе 1, перешел через границу, и видит его в выброшенном месте
2. игрок выбросил предмет в регионе 1 и в этот же момент произошло добавление нового шарда, который сузил границы региона 1 и поделил его напополам. В последствии предмет «перекочевал» обратно к игроку в новый шард.
вы делаете расчет на идеальный мир — "… а он имеет свойство тормозить!!!" — игрок бежит в шарде №1 и выкидывает объект ровно за Тик до границы объект выпадает тк условия проверки проходят нормально — у игрока объект в ТЕОРИИ должен пропасть Транзакция на удаление Объекта в БД улетела — НО она не мгновенная(!!!) и Вот тут начинается веселье, тк Игрок попадает на другой Шард где ЕЩЁ нет информации о Отсутствии объекта у Игрока и он может выложить его повторно… И возникает очень интересная коллизия — объект Валиден и есть На шарде №1 Объект Валиден и Есть на шарде №2 и Объекта нет у игрока о чем прилетает подтверждение из БД в реплики обоих шардов…
Даже если у вас есть четкое отслеживание ID-ов Объектов и каждый ID уникален и это проверяется — вопрос в том как у вас происходит обработка свободно «лежащих» на «Земле» объектов? Если вы думаете что тут проблема только с Дюп-ом объектов то вы сильно заблуждаетесь Босы, Мобы и NPC тоже Дюпаются…
Кому в настоящий момент может понадобиться сервер Lineage 2 для больших онлайнов?
Правильная архитектура MMO эмулятора