Вопрос плагин + redis + mysql (синхронизация)

[acv]

Здравствуйте! Хочу попробовать построить проект на мульти-серверной системе. Обычно у нас принято так: анархия-1, анархия-2 или бедварс-1, бедварс-2 и т.д. По сути ты зашел на монолитный сервер котором и арены и лобби. С точки зрения поддержки это удобно, просто пишешь 1 плагин и добавляешь копию сервера, может используешь mysql для хранения постоянных данных.
На западных серверах или крупных серверах мини-игр принято делать вообще, отдельно лобби и игру и использовать балансировщики нагрузки, чтобы отправлять на разгруженный сервер, хаба, если лобби, то ни игровой, а игровой обратно лобби.

Такое начало... Будем использовать proxy velocity, paper сервера и самописы под них, mysql, redis. Сразу скажу что я разобрался как все это работает. Вопрос больше к архитектуре, а именно использование redis в проекте.

Берем просто для примера, стикфайт (пвп 1на1 на палках), бедварс. Сразу хочется дать метку, что каждый мини режим это кластер (грубо говоря мини сеть серверов). Один режим не должен знать про сервера другого.

1. Так вот, есть лобби сервера например их 2 шт каждый по 100 онлайна, игровые 4 шт, каждый по 100 онлайна. Каждый лобби сервер должен знать сколько онлайна на игровых, чтобы выбрать разгруженный сервера и по его названию отправить команду на velocity сервер "перекинь p1 на stickFight-game-2". Игровые серверы должны знать о лобби серверах, цифре онлайна, чтобы механизм сработал в обратку. Так вот на redis как такое реализовать? Используя ключи в его памяти? Для выбора сервера метод балансировки постоянно шлет пакет чтобы получить онлайн каждого сервера (асинхронно) или делать локальные hashmap кэши? И там держать под рукой каждый сервера и обновлять системой уведомлений redis? Первый способ дает центр данных, второй копии, но локальность.


2. хранение статистики игрока и настроек, эти данные я принимаю за профиль игрока, так и назовем, а java на сервере у меня это объект с полями, в котором настройки игрока и стата. так вот получить из бд не проблема. а хранить? при входе можно делать локальные копии данных ка каждом сервере кластера, но это тупик полный, жрет память. хранить в ключах? а например сделать проверку глобальную "находится ли игрок в дуэли?" придется слать асинхронный метод чтобы проверил. понятно что локал хост будет все но тем не менее не могу определиться.

3. хранение пати. в redis? с ttl? просто опять же нужно что то проверить с другого сервера идешь в redis.

Вот так. По большей части вопрос "где хранить"? Архитектурный. Типо закодить смогу, но определиться все никак, чтобы чисто и без костылей, если такое вообще возможно. Тот же хайпиксель или еще какие нибудь сервера на таких же принципах сделали, но я просто боюсь сразу проект пустить по говну. Делаю чисто для себя, для понимания...

 

[Mioji]

Возможно я напишу позже подробную статью про архитектуры на сервера.

У тебя немного неправильное видение кросс-серверности и серверных архитектур. Ты очень сильно путаешь серверную архитектуру (на каком по запускаются режимы и проект) и логику самих режимов. Не буду внедряться в подробности устройства кастомных микросервисов, систем, кор и башень на таких проектах как cristalix, vimeworld, funtime, holyworld и так далее, т.к у всех они разные и под разные потребности. Но пройдусь просто поверхностно, чтобы ты понял куда двигать разработки.

Каждый лобби сервер должен знать сколько онлайна на игровых, чтобы выбрать разгруженный сервера и по его названию отправить команду на velocity сервер "перекинь p1 на stickFight-game-2"

Это называется оркестрация серверов и игровых сессий. И они работают совсем иначе и выполняют другие функции, нежели межсерверность серверов и игровой контент внутри Minecraft режимов. Например ты можешь использовать для кубов Kubernetes, но поймёшь, что нативно он не подходит под Minecraft и придётся писать что-то кастомное поверх Kubernetes или делать кастомные системы оркестрации (Что обычно делают крупные сервера). Но изобретать велосипед не надо, уже давно придумали Cloudnet V4, который изначально и делался как стабильный оркестратор для Minecraft. То есть по факту он выполняет те же функции, но оптимизированный и созданный исключительно под Minecraft сервера. И самое главное тебе на оркестрацию нужно много времени и тестов, так ещё и стоить это может быть до 500к рублей.

Тебе не нужно писать отдельное ПО для оркестрации, а можно сосредоточиться уже не решению проблем с самим Minecraft для твоего кастомного контента. А теперь перейдём к контенту.

Будем использовать proxy velocity, paper сервера и самописы под них, mysql, redis

Для полной поддержки кросс-серверности нужен и multi-proxy. В cloudnet частично он есть, другие проблемы ты решаешь уже на стороне своих плагинов. Можешь использовать что-то по типу RediaBungee и так же в самих плагинах "например авторизация" предусмотреть Мульти-прокси.

Сразу хочется дать метку, что каждый мини режим это кластер (грубо говоря мини сеть серверов). Один режим не должен знать про сервера другого.

Это правильный подход. Но подмечу, что например на новых версиях ты можешь бедварс сессии игр запускать на кластерах сессии. Это означает, что физички сервер держит на себе 70-80 человек и по 4-6 игр одновременно, которые для взгляда игрока будто-то отдельные сервера. Так можно выделять на игру мало памяти и ресурсов процессора. Раньше можно было запускать 1 сервер на 1 игру, сейчас же для каждого запущенного сервера тебе надо 2 гб памяти для стабильной игры, а в случае minestom около 400. Так что выгоднее делать как я тебе сказал.

Игровые серверы должны знать о лобби серверах, цифре онлайна, чтобы механизм сработал в обратку. Так вот на redis как такое реализовать?

Если будешь использовать cloudnet, тебе это не нужно, он будет знать об состоянии каждого сервера на десятках разных хостингах. Я тестировал на одновременно 8, это работает хорошо. В таком случае, тебе лучше сосредоточиться на кастомном модуле для cloudnet, который будет создавать поведение сервисов таким, какой необходим для твоего режима. Например можешь взять за основу модуль smart для более продвинутой балансировки конкретно под режим.

Мы делали систему внутри лобби, где как на vimeworld, можно подключаться уже к заказанным серверам. На сервере всегда были сервера, потому что система понимала нагрузку по онлайну, запущенные сервера и потребности в новых. В простонароде это называется "Заказ серверов".

хранение статистики игрока и настроек

Вот это уже логика режимов и проекта. Ты можешь написать целый сервис статистики (отдельное по), которое работает с core/api на сервер, через который работают все режимы. Так ещё можешь разделить разную систатистику и сервера на типы. На самом деле выбор у тебя частично правильный, redis тут выступает в роли кэширования например, чтобы снизить нагрузку с базы данных. А вот какю бд выбрать - вопрос уже твоих потребностей. Для большинства достаточно MariaDB.

хранение пати. в redis? с ttl? просто опять же нужно что то проверить с другого сервера идешь в redis.

Ну ваще, частично да, многие системы пати кросс-серверности основаны либо на кастомном сервисе, либо redis. Тут тоже верно. Просто погугли в инете, много публичных разработок на этот счет, даже от прошлых серверов по мини игр. Даже у самого популярного плагина на пати есть работа с RedisBungee.

Авторизуйтесь для просмотра ссылок.

По большей части вопрос "где хранить"? Архитектурный. Типо закодить смогу, но определиться все никак, чтобы чисто и без костылей, если такое вообще возможно

Это все зависит от твоих потребностей и замашек на проект. На самом деле Hypixel устроен намного иначе, они первооткрыватели, они годами делали свои кастомные технологии, свою оркестрацию, прокси и ядро. Это проект другого уровня по тех части, делать как они не имеет смысла, потому что дорого и в современных реалиях можно сделать лучше. Ты не обязан использовать cloudnet или тому подобное, что я писал, ты можешь взять их за основу, если хочешь так же как крупные проекты 100% сделать все кастомное. Но задайся себе вопросом нужно ли тебе оно и хватит ли тебе сил.

Ты можешь использовать навороченную систему аналитики и статистики, разделять данные и хранить их отдельно по назначению в InfluxDB для логов, ElasticSearch/Prometheus для метрик, ClickHause для экономики, статистики или AI. Использовать одновременно MariaDB и MongoDB для разных сценариев. Использовать одновременно Redis, Nats и RabbitMQ для своих отраслей, ведь одни могут дешево и хорошо выполнять только свою задачу в инструкции. Ты можешь поднять и держать кластеры Kubernetes, использовать на серверах продвинутые автоматизации на основе какого-нибудь Ansible и мощных скриптов. Хватит ли у тебя денег на то, чтобы это все месиво обслуживать? У тебя проект будет на 10к+ онлайна?

 

[acv]

Возможно я напишу позже подробную статью про архитектуры на сервера.

У тебя немного неправильное видение кросс-серверности и серверных архитектур. Ты очень сильно путаешь серверную архитектуру (на каком по запускаются режимы и проект) и логику самих режимов. Не буду внедряться в подробности устройства кастомных микросервисов, систем, кор и башень на таких проектах как cristalix, vimeworld, funtime, holyworld и так далее, т.к у всех они разные и под разные потребности. Но пройдусь просто поверхностно, чтобы ты понял куда двигать разработки.


Это называется оркестрация серверов и игровых сессий. И они работают совсем иначе и выполняют другие функции, нежели межсерверность серверов и игровой контент внутри Minecraft режимов. Например ты можешь использовать для кубов Kubernetes, но поймёшь, что нативно он не подходит под Minecraft и придётся писать что-то кастомное поверх Kubernetes или делать кастомные системы оркестрации (Что обычно делают крупные сервера). Но изобретать велосипед не надо, уже давно придумали Cloudnet V4, который изначально и делался как стабильный оркестратор для Minecraft. То есть по факту он выполняет те же функции, но оптимизированный и созданный исключительно под Minecraft сервера. И самое главное тебе на оркестрацию нужно много времени и тестов, так ещё и стоить это может быть до 500к рублей.

Тебе не нужно писать отдельное ПО для оркестрации, а можно сосредоточиться уже не решению проблем с самим Minecraft для твоего кастомного контента. А теперь перейдём к контенту.


Для полной поддержки кросс-серверности нужен и multi-proxy. В cloudnet частично он есть, другие проблемы ты решаешь уже на стороне своих плагинов. Можешь использовать что-то по типу RediaBungee и так же в самих плагинах "например авторизация" предусмотреть Мульти-прокси.


Это правильный подход. Но подмечу, что например на новых версиях ты можешь бедварс сессии игр запускать на кластерах сессии. Это означает, что физички сервер держит на себе 70-80 человек и по 4-6 игр одновременно, которые для взгляда игрока будто-то отдельные сервера. Так можно выделять на игру мало памяти и ресурсов процессора. Раньше можно было запускать 1 сервер на 1 игру, сейчас же для каждого запущенного сервера тебе надо 2 гб памяти для стабильной игры, а в случае minestom около 400. Так что выгоднее делать как я тебе сказал.


Если будешь использовать cloudnet, тебе это не нужно, он будет знать об состоянии каждого сервера на десятках разных хостингах. Я тестировал на одновременно 8, это работает хорошо. В таком случае, тебе лучше сосредоточиться на кастомном модуле для cloudnet, который будет создавать поведение сервисов таким, какой необходим для твоего режима. Например можешь взять за основу модуль smart для более продвинутой балансировки конкретно под режим.

Мы делали систему внутри лобби, где как на vimeworld, можно подключаться уже к заказанным серверам. На сервере всегда были сервера, потому что система понимала нагрузку по онлайну, запущенные сервера и потребности в новых. В простонароде это называется "Заказ серверов".


Вот это уже логика режимов и проекта. Ты можешь написать целый сервис статистики (отдельное по), которое работает с core/api на сервер, через который работают все режимы. Так ещё можешь разделить разную систатистику и сервера на типы. На самом деле выбор у тебя частично правильный, redis тут выступает в роли кэширования например, чтобы снизить нагрузку с базы данных. А вот какю бд выбрать - вопрос уже твоих потребностей. Для большинства достаточно MariaDB.



Ну ваще, частично да, многие системы пати кросс-серверности основаны либо на кастомном сервисе, либо redis. Тут тоже верно. Просто погугли в инете, много публичных разработок на этот счет, даже от прошлых серверов по мини игр. Даже у самого популярного плагина на пати есть работа с RedisBungee.

Авторизуйтесь для просмотра ссылок.

Это все зависит от твоих потребностей и замашек на проект. На самом деле Hypixel устроен намного иначе, они первооткрыватели, они годами делали свои кастомные технологии, свою оркестрацию, прокси и ядро. Это проект другого уровня по тех части, делать как они не имеет смысла, потому что дорого и в современных реалиях можно сделать лучше. Ты не обязан использовать cloudnet или тому подобное, что я писал, ты можешь взять их за основу, если хочешь так же как крупные проекты 100% сделать все кастомное. Но задайся себе вопросом нужно ли тебе оно и хватит ли тебе сил.

Ты можешь использовать навороченную систему аналитики и статистики, разделять данные и хранить их отдельно по назначению в InfluxDB для логов, ElasticSearch/Prometheus для метрик, ClickHause для экономики, статистики или AI. Использовать одновременно MariaDB и MongoDB для разных сценариев. Использовать одновременно Redis, Nats и RabbitMQ для своих отраслей, ведь одни могут дешево и хорошо выполнять только свою задачу в инструкции. Ты можешь поднять и держать кластеры Kubernetes, использовать на серверах продвинутые автоматизации на основе какого-нибудь Ansible и мощных скриптов. Хватит ли у тебя денег на то, чтобы это все месиво обслуживать? У тебя проект будет на 10к+ онлайна?

Могу в тг написать ? Там буквально пару вопросов. В целом спасибо за описание, некоторых моментов не знал . В целом проект не прямо большого размаха в целом можно на редисе справится, просто зовется четкую карту выстроит и по ней идти