Как консолидировать распределённые серверы игры?

Question

[Сергей Соколов]

Допустим, простая браузерная викторина. По WebSocket подключаются к серверу и отправляют ответы.
Игра на время. У всех появился вопрос, 10 секунд на раздумья и выбор варианта ответа.
Сервер приинял ответы, разослал всем статистику: вариант А: 100 человек, вариант Б: 200.

Просто, пока не ломится туда по 100 тыс. участников. Приходится масштабировать.

Несколько серверов. Каждый обслуживает свой пул WS-соединений == пул игроков.
Данные игроков — только в памяти этого сервера.

Закончилось время вопроса. Надо собрать общую статистику между всеми серверами и отправить каждый своим игрокам.

Какой паттерн (?) есть для этой ситуации?

Пришло в голову пока 2 варианта.

1. Серверы полностью одинаковы и равноправны. Знают контакты остальных. Каждый шлёт остальным свои данные, ждёт (определённое время?) от остальных их инфу. Суммирует, рассылает по своему пулу.
   
2. Мастер-сервер и «рабы». Мастер собирает со всех инфу, у себя суммирует, отправляет по всем итог. Те рассылают по пулу.
   

Какой из вариантов лучше и почему, как считаете?

Answer 1

[Армянское Радио]

Однослойная структура, теоретически, может быть более устойчива, чем структура с выделенным сервером.

Comments

[Сергей Соколов]

это с точки зрения отказоустойчивости? Тут пока не встаёт вопрос, что во время игры вылетит один из боксов. Если такое случится, наверное, игру перенесут/повторят. Т.к. потеряются все игроки вылетевшего.

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

[Армянское Радио]

Зависит еще от того, какое время отклика надо получить, должны ли все серверы в пуле в итоге собрать у себя все данные, и так далее.

[Сергей Соколов]

Армянское Радио, должны все. Время минимизировать.
Несколько белых IP, на каждом load balancer и от каждого потенциально к любой из нод подключит очередного пользователя.

[Армянское Радио]

Сергей Соколов, Все серверы в одном ДЦ?

[Сергей Соколов]

Армянское Радио, в одном. Внутр, сеть между ними, по идее, гига-быстра.

[Армянское Радио]

Сергей Соколов, Тогда одноранговый режим с UDP-Multicast. Это самый быстрый способ в одноранговой сети плюнуть с одного сервера сообщение так, чтобы его одновременно получили все серверы, находящиеся с ним в одном домене вещания.

Также можете посмотреть на MPI

[Сергей Соколов]

по числу=объёму сообщений вариант с мастером экономнее: N * 3 сообщений: запрос, ответ, запрос-с-итогом-для-рассылки. O(n) ?
А с одноранговыми сообщений будет N * 2 * N = O(n^2) ?

Но сеть быстра, сообщения легкие и это не то, на чём, наверное, стоит экономить.

[Сергей Соколов]

UDP вроде бы не надёжен? Т.е. может случиться недоставка. Теоретически.
Поэтому все сообщения по TCP: HTTP или WebSocket.

[Армянское Радио]

Сергей Соколов, MPI решает эту проблему путем добавления подтверждений. TCP, которым вы собираетесь пользоваться, также ненадежен, и будет генерировать дополнительные пакеты для поддержания целостности.

[Армянское Радио]

Сергей Соколов, с другой стороны, MPI просто цеплять программе, у которой бэк на C++/Fortran

[Армянское Радио]

Сергей Соколов, перечисленные вами протоколы - все Point-to-Point, что создает кучу дополнительных накладных расходов.
Если использовать мультикаст, можно с большой вероятностью успеха доставить все сообщения за N рассылок, а то, что не доставилось, уже дослать отдельными запросами.

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

Answer 2

[Владимир Олохтонов]

Скорее всего для такой задачи хватит одного сервера за глаза.

Если понадобится масштабировать, то сделаете несколько одинаковых машин с общей базой и балансер перед ними.

Comments

[Сергей Соколов]

уже не хватило. Тяжелое наследство неоптимального кода загружает на 100% все 16 cpu.

"База" там в памяти. Поэтому надо консолидировать всем-между-всеми.

[Владимир Олохтонов]

Сергей Соколов, база в памяти - это redis/memcached или что-то самописное?
А чем программа занимается, раз она так активно CPU кушает? Может есть смысл именно на это место обратить внимание, вместо выдумывания распределённой системы?

[Сергей Соколов]

Владимир Олохтонов, четвёртое: Swoole\Table

Answer 3

[xmoonlight]

1. Отправка ответов на вопросы - через POST.
2. Получение серверных событий браузером (новый вопрос, синхр.таймера, кто онлайн?) - websocket.
3. Остальное - GET.

Comments

[Сергей Соколов]

Так было поначалу. Плохо тем, что открываются новые соединения для HTTP POST/GET.
Теоретический лимит одного IP 65535 соединения. Практический ниже.
Прибежало 65к WS соединений, и висят. И ни один AJAX уже не пройдёт.
Поэтому решили все коммуникации перевести в WS.
Один игрок – одна «ниточка». Одна пуля — один труп.

[xmoonlight]

Сергей Соколов, вроде больше должно быть... Я б потестил на лимит в локалке вторым сервом.