Шаблоны проектирования процессов обновления сервера

Question

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

Функциональность
По сути, серверное программное обеспечение (которое разрабатывается на Java с использованием JBoss Netty) просто позволяет аутентифицированным клиентам устройства передавать и контролировать данные объекта, которые затем передаются клиентам устройства с указанным диапазоном.

Рассмотренные подходы
1. Используйте фиксированный пул потоков и периодически обновляйте устройства в очереди, в которых сервер выполняет проверку объектов в зоне действия устройства и передает соответствующие порождает / обновляет / уничтожает пакеты.
2. Используйте модель стиля ректора, где события регистрируются в реакторе и обрабатываются
синхронно. Например, событие может быть опубликовано при обновлении устройства сущность или устройство обновляет свое местоположение. Затем сервер может выбрать объекты в дальность действия устройства и передача соответствующих пакетов создания / обновления / уничтожения
асинхронно.
3. Выполните обновления в потоке событий Netty. Например, клиент обновляет это
местоположение, сервер выполняет проверку сущностей в пределах диапазона и отправляет соответствующие создавать / обновлять / уничтожать пакеты. Проблема в том, что при таком подходе сервер будет
не передавать объекты, если устройство не обновляет свое местоположение. Средство, чтобы решить это проблема также может заключаться в выборе устройств в радиусе действия объекта при создании / обновлении / уничтожении сообщение от устройства и обновлять каждый из них синхронно.

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

Мои извинения, если в моем вопросе недостаточно информации, я с удовольствием исправлю любые ошибки или предоставьте дополнительную информацию по запросу.

Спасибо за ваши ответы.

Answer 1

Это сервер многопользовательской игры netty Я написал. Вы можете найти ответы на свои вопросы там. Я пока не определился с масштабируемостью. Я смотрю несколько вариантов здесь.

1. Не делить состояние между несколькими виртуальными машинами. Это означает, что игроки получат минимальную задержку. Недостатком является то, что они не смогут прыгать с одного виртуального канала на другой, если там играют их сверстники. В этой модели входящие события будут сохраняться / записываться в журнал, а в случае сбоя и т. Д. Они будут воспроизводиться ради долговечности. Помогло бы что-то вроде следующего Хроника .
2. Делить состояние между виртуальными машинами. Задержка может нанести удар, но масштабируемость определенно будет выше. Я смотрю на фундук . Что позволяет осуществлять прозрачное совместное использование состояний.