Какой-то мейнстрим вокруг spring и всей его экосистемы. Есть кучу компаний и решений, не использующих spring, в которых нужны core разработчики. Новичок, конечно же, сразу пойдет хайпить по новомодному стеку, прочитав эту статью - зачем знание core разработки, когда можно писать MVC сутками и плевать как оно работает, имхо. Как будто бы все программирование на Java сводится к построению веб-решений и только.
Тащить в проект inMemory бд ради того что бы не хранить в ней данные, а использовать распределенные блокировки.. слишком много оверхеда. Для каждой задачи есть свой инструмент, и этот не подходит под вашу задачу. Нужны распределенные воркеры, которые будут запускаться поочередно на каждой ноде - quartz в помощь. Даже банальная таблица синхронизации в реляционной базе с запросами вида select for update, решает эту задачу.
Согласны с тем, что Reactive-фреймворки хорошо подходят для программирования интерфейсов в web и мобильных приложениях, и что они просто прекрасны везде, где есть взаимодействие с человеком через UI. Но не на бэкенде! Там это прекращается в боль.
Отнюдь не верное утверждение. Существует множество сетевых решений, построенных на базе реактивного стека, превышающих нагрузку и в 50 тыс. активных соединений. Конечно, порог вхождения куда выше, чем в императивном программировании. А не разобравшись с технологией, и пробовать даже не стоит. Про любую технологию, в неумелых руках, можно сказать, что она для чего-то не подходит.
Ну смотрите, идея виртуальных регионов тоже уже предусмотрена, и включатся они должны в момент этих самых скоплений персонажей на границах, как и с массовыми мероприятиями (вдруг замок попадет в границу). Сама бд не нагружена от слова совсем, а вот сокет — да. Для промежуточного состояния используется не бд, а память и репликация, также для консистентной обработки планируется использовать распределённый CAS ключей.
Существует несколько настроек клиента, которые позволяют ограничивать видимость PC/NPC, но чтобы полностью отключать анимацию того или иного действия — нужно делать реализацию привязки некоторых настроек игрока, и резать по ним исходящие пакеты.
просто при географическом Шардинге у вас встает вопрос передачи данных о взаимодействии больших групп игроков. и что Будет происходить при Обсчете взаимодействия скажем 1000 игроков
Дельта данных каждого игрока уже существует во всех шардах кластера средствами репликации. Так что это особого аффекта не должно вызвать, как и сейчас с перемещением. А взаимодействие игрок-игрок на границах — обмен трафика между шардами.
А еще не совсем тривиальный вопрос — если я на бегу через границу уроню предмет в зоне одного шарда он у меня останется? или Дуплицируется если я его успею выложить до прохода обновления данных между шардами?
Предмет перекочует вместе с игроком в том состоянии, в котором он находился до балансировки. Т.е. тут можно рассмотреть два варианта
1. игрок выбросил предмет в регионе 1, перешел через границу, и видит его в выброшенном месте
2. игрок выбросил предмет в регионе 1 и в этот же момент произошло добавление нового шарда, который сузил границы региона 1 и поделил его напополам. В последствии предмет «перекочевал» обратно к игроку в новый шард.
P.s. чтобы каких-то неочевидных багов не происходило, я блокирую любое телодвижение объектов в мире при «расширении/сужении» кластера, увы операция сама по себе дорогостоящая.
Я, довольно таки, плохо знаком с архитектурой решения ССР, и как они осуществляют балансировку ибо в публичных данных этого не написано. Предположительно они делают тоже самое — при подключении нового шарда, игроки распределяются равномерно между ними. Но и им это проще делать, поскольку данные централизовано хранятся на RAID массивах. У моего решения — в памяти, а шарить память между двумя процессами, даже с помощью nmap, гиблая затея. Здесь, возможно, же, все тоже самое. Первоначальное состояние S1 (100 игроков), подняли S2, оркестратор перебросил какой-то процент игроков, охватывающий те регионы, в которых они находятся, на S2.
Скорее всего. Я описывал два состояния игровых объектов — базовое и промежуточное. Базовое — складывается в базу по таймауту. Промежуточное — складывается в off-heap память и реплицируется в кластере. Уточните пожалуйста — tps.
Я спрашивал — как вы проверяли, что оригинальный бэкенд не держит подобную нагрузку
Простите, но где?
10-15% cpu на древних каких-то двухядерных атлонах и 4 гб оперативки
А вы проверяли в текущей реальности свои же показатели, перед тем как написать? Явно же нет.
Вам точно хватило на запуск С4 4гб ОЗУ? Да это же смешно, С4 Retail минимум требует 8гб ОЗУ не считая вспомогательный систем WS.
Вы почему-то в упор не видите очевидной реальности — статья абсолютно не заставляет никого брать и делать сейчас свой L2 сервер, пользуясь этой архитектурой, а наоборот — дает эталон архитектуры, которой не стоит пренебрегать в том или ином проекте. Дальнейшая полемика бессмысленна.
Сохранять что и куда? Persist каких-либо промежуточных данных происходит в память шарда, а уже, как Вы и сказали, основного состояния, часть которого хранится в базе, выполняется по таймауту в data-service. Уточните утверждение, абсолютно не понятен посыл.
А давайте заведем практику - вместо инъекции зависимостей, будем напрямую инициализировать их из контекста во всем приложени.
Какой-то мейнстрим вокруг spring и всей его экосистемы. Есть кучу компаний и решений, не использующих spring, в которых нужны core разработчики. Новичок, конечно же, сразу пойдет хайпить по новомодному стеку, прочитав эту статью - зачем знание core разработки, когда можно писать MVC сутками и плевать как оно работает, имхо. Как будто бы все программирование на Java сводится к построению веб-решений и только.
Окей, это все круто, что вы смогли элегантно обойти проблему. Но, зачем велосипед если есть vavr?
Удивительно.
Имхо, стоит внимательней вчитываться в код того же IntegrationFlowBuilderRegistry...
Тащить в проект inMemory бд ради того что бы не хранить в ней данные, а использовать распределенные блокировки.. слишком много оверхеда. Для каждой задачи есть свой инструмент, и этот не подходит под вашу задачу. Нужны распределенные воркеры, которые будут запускаться поочередно на каждой ноде - quartz в помощь. Даже банальная таблица синхронизации в реляционной базе с запросами вида select for update, решает эту задачу.
Как это не может "многопоточно"?
С точки зрения выполнения команд в коре - да. С точки зрения вашего кода - CAS и Retry уже не используется?
А индексы уже не используют? Почитайте спеку на монгу более детально.
Бегло пробежался по save/load, подойдет банальный mmap. Как одно из готовых решений - https://github.com/odnoklassniki/shared-memory-cache
А это такой новый тренд хранить статичные списки данных в бд? Ладно инвентарь игрока, куда складируются предметы, но список наград..
Отнюдь не верное утверждение. Существует множество сетевых решений, построенных на базе реактивного стека, превышающих нагрузку и в 50 тыс. активных соединений. Конечно, порог вхождения куда выше, чем в императивном программировании. А не разобравшись с технологией, и пробовать даже не стоит. Про любую технологию, в неумелых руках, можно сказать, что она для чего-то не подходит.
Дельта данных каждого игрока уже существует во всех шардах кластера средствами репликации. Так что это особого аффекта не должно вызвать, как и сейчас с перемещением. А взаимодействие игрок-игрок на границах — обмен трафика между шардами.
Предмет перекочует вместе с игроком в том состоянии, в котором он находился до балансировки. Т.е. тут можно рассмотреть два варианта
1. игрок выбросил предмет в регионе 1, перешел через границу, и видит его в выброшенном месте
2. игрок выбросил предмет в регионе 1 и в этот же момент произошло добавление нового шарда, который сузил границы региона 1 и поделил его напополам. В последствии предмет «перекочевал» обратно к игроку в новый шард.
P.s. чтобы каких-то неочевидных багов не происходило, я блокирую любое телодвижение объектов в мире при «расширении/сужении» кластера, увы операция сама по себе дорогостоящая.
Простите, но где?
А вы проверяли в текущей реальности свои же показатели, перед тем как написать? Явно же нет.
Вам точно хватило на запуск С4 4гб ОЗУ? Да это же смешно, С4 Retail минимум требует 8гб ОЗУ не считая вспомогательный систем WS.
Вы почему-то в упор не видите очевидной реальности — статья абсолютно не заставляет никого брать и делать сейчас свой L2 сервер, пользуясь этой архитектурой, а наоборот — дает эталон архитектуры, которой не стоит пренебрегать в том или ином проекте. Дальнейшая полемика бессмысленна.