Игровой сервер на node.js, используя cluster и redis, какую логику использовать?

Question

[Anubis]

Всем привет. Прошу у опытных коллег помощи в деле организации логики игрового сервера — на новой для меня платформе, из-за чего от недостатка практического опыта (за спиной тривиальнейшие браузерки на php-mysql-memcache) очень не хотел бы напортачить с точки зрения оптимизации, дабы потом не пришлось «на лету» переформатировать логику.

Цель — написать браузерку с «комнатной» пошаговой боёвкой (а-ля jrpg), где каждый игрок «отвечает» за своего персонажа. В качестве серверной платформы остановился на node.js, базой данных будет служить redis с orm jugglingdb. Общение с клиентами через tcp-сокеты.

Игрокам, участвующим в битве, сервер по очереди выдаёт право хода, ограничивая выбор применяемого удара/вещицы/скилла игроком заданным интервалом (допустим, 20 секунд), затем выжидает определённый интервал времени (в зависимости от длительности анимации того или иного действия активного персонажа, прописанное в базе сервера), после чего выдаёт право хода следующему игроку.

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

Пробуксовку в деле проектирования логики вызывает принципиальное желание задействовать cluster с целью выноса части обрабатываемых задач в параллельно запущенные worker'ы, подняв потолок производительности по сравнению с работой всей логики внутри одного процесса на одном ядре.

Какого рода задачи разумно вынести из главного процесса в «воркеры»? В голову приходит только подключение сокетов и общение с ними. Про redis, точнее про его функционал publish/subscribe, тоже хотелось бы узнать в плане производительности — подойдёт ли он для общения между потоками и мастер-процессом, или лучше организовать это через process.on('message') / worker.send(data)?

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

Буду очень признателен за любые советы, объяснения и примеры.

Answer 1

[evnuh]

Делать по потоку на коннект - худшая идея.
Использовать редис для межпроцессорной коммуникации - хорошая идея.
Как разбить задачи по воркерам. Думаю, отличным вариантом будет равномерно всё размазать на все ядра, то есть, главный поток выступает неким роутером, который по очереди раздаёт (по очереди воркеры сами забирают) себе инфу пришедшую по сокету в главный процесс. При этом всё можно разбить по игрокам, а привязывать на каком из поток обрабатывается какой игрок по его id, например. Для всего этого можно использовать редис, но лучше не поленитесь и хотябы чуточку почитайте про zeromq, там и сокеты, и concurrency framework и message passing.

Comments

[Alex Chistyakov]

> Использовать редис для межпроцессорной коммуникации - хорошая идея.

А зачем в этой схеме вообще нужна какая-то коммуникация?

[evnuh]

@alexclear межпоточной конечно, простите. Или вы про коммуникацию вообще? Ну не знаю, всякое же может быть, я игры не писал, может оно и вправду не надо.

[Anubis]

“Делать по потоку на коннект - худшая идея.”
Тут имел в виду коннектить игроков к воркерам, а число самих воркеров делать равным числу ядер процессора. Как в сэмплах кода по cluster — require('os').cpus().length.
Значит, вы рекомендуете tcp-сервер делать на главном потоке? Я просто не знаю, насколько ресурсоёмкой является работа с соединениями игроков.

С zeromq ещё не знаком, в первом примере кода на https://github.com/JustinTulloss/zeromq.node вижу как раз общение между потоками. Спасибо за наводку, попробую ознакомиться.

Отправлять задание в воркер, отталкиваясь от номера игрока в качестве метода распараллеливания, правильно понял?

[Alex Chistyakov]

@evnuh Да и межпоточная не нужна - достаточно в самом начале привязать игрока к одному из воркеров, так как работа идет по TCP, это делается довольно тривиально. Правда, воркеры должны быть stateless, я думаю, они такие и есть.

Answer 2

[Alex Chistyakov]

> Какого рода задачи разумно вынести из главного процесса в «воркеры»? В голову приходит только подключение сокетов и общение с ними.

Зачем Вам в этой схеме "главный процесс"? Для решения Вашей задачи достаточно запустить нужное количество воркеров (допустим, у Вас на машине 8 ядер - запустите 9 воркеров) на разных портах и поставить HAProxy в качестве балансировщика перед ними в TCP режиме. Правда, при этом у Вас будет теряться информация об IP-адресах клиентов, так как соединения терминируются на HAProxy, а в TCP режиме он сведения о клиентском IP на бэкенд не передает. Не беда - Вы можете использовать HTTP/1.1 и web sockets для решения Вашей задачи, тогда из заголовка X-Forwarded-For на бэкенде можно будет узнать адрес клиента.
Второй вариант более сложный - действительно, используйте мастер-процесс, порождающий нужное количество воркеров заранее. Схема хорошо описана здесь, и там даже приведена картинка, отличие Unicorn от Вашей схемы в том, что воркеры Unicorn работают синхронно, а Ваши будут работать асинхронно.

Comments

[Anubis]

> Зачем Вам в этой схеме "главный процесс"?

Для централизованного хранения информации о текущих боях, например. По-моему, это лучше, чем хранить их в redis и запрашивать при каждом шаге в бою. Или не лучше?

[evnuh]

@Anubis понятно что редис помедленнее будет, но зато думать о синхронизации доступа вам не надо будет самому.

[Alex Chistyakov]

@Anubis Лучше или нет мы сказать не можем до тех пор, пока Вы не сравните два этих решения экспериментально или, хотя бы, не назовете значения предполагаемой нагрузки. Да и с надежностью в случае хранения такой информации локально в воркере Node.JS будут проблемы. У V8 сборщик мусора не очень подходит для длительной работы, поэтому воркеры нужно время от времени заменять на новые - и как быть тогда? Терять при рестарте всю информацию о боях?

[Anubis]

@alexclear то есть, воркеры должны быть спроектированы таким образом, чтобы они могли время от времени перезапускаться без пагубного влияния на игровой процесс? Кажется, у меня совсем нет понимания того, какого рода задания в принципе делегировать им от главного процесса игры. В случае с моим предположением вешать на воркеры tcp-сервера для соединения игроков, при перезапуске воркера части игроков грозит дисконнект. Других предположений, какого рода задачи отдавать воркерам, я пока не выработал.

[evnuh]

@Anubis чтобы не бояться, что воркер отвалится и все сломается - их нужно делать stateless, как вам уже советовал @alexclear . Это значит что сами воркер ы не хранят ничего, а только производят действия с данными. Поэтому, с учётом того, что нам сказали про V8 - неплохой идеей будет хранить всё в Redis и общаться только через неё. Тогда респаун воркера при правильном подходе к маршрутизации игроков не повлечёт ничего страшного.

[Anubis]

@evnuh становится примерно понятно, спасибо!