Архитектура сервера - Redis vs Socket server

Question

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

Мир 1, Мир 2, Мир 3

Каждый мир - это сервер, который работает с другим IP-адресом.

Вот список того, что должна иметь игра:

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

Есть два подхода к этому, о которых я могу подумать:

Подход 1 - Сервер входа в систему TCP / IP

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

• Сервер входа в систему всегда обновляет все миры со списком игроков онлайн, а также состояние каждого игрока, в каком мире он находится и т. Д.

• При отправке сообщения игроку Y от игрока X, когда оба находятся в разных мирах, мировой сервер отправит сообщение на сервер входа в систему, а сервер входа передаст его в целевой мир этого игрока, чтобы игрок в другом Мир получит сообщение.

Подход 2

Работают так же, как и подход 1 , но вместо сервера входа в систему имейте сервер HTTP API и обновляйте друг друга событиями, используя сервер Redis. Почему я считаю, что это лучше? Потому что будет проще интегрировать веб-приложение в игру, поэтому разрешите пользователям подключаться и общаться друг с другом через веб-приложение.

Чтобы сделать это в подходе 1, вам нужно добавить новый туннель к вашему серверу входа TCP / IP для поддержки соединений WebSocket.

Извините за плохие рисунки.

Возможен ли подход 2? Как вы думаете, какой подход лучше, и если есть какой-то другой подход, о котором вы можете подумать?

Answer 1

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

Затем вы будете использовать базу данных для учетных данных, которые каждый мир будет проверять для каждого входа.Затем вы должны использовать Redis (вы можете использовать базу данных, но Redis работает быстрее), чтобы отслеживать текущих пользователей, в каком мире они были, и т. Д. Вы также можете использовать его для отправки сообщений или очередь сообщений (с источником /раковина для каждого мира).Этот метод также очень масштабируемый.Если вам нужно больше миров, просто добавьте больше той же машины за балансировщиком нагрузки, не меняя код.

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

Answer 2

Я работал с подобным подходом, как номер два. У меня была служба, которая регистрирует пользователей в той части системы, где используется их учетная запись Gmail. Служба входа в систему отправляет пользовательские данные, хранящиеся в базе данных, в службу соединителя Gmail, которая создает URL-адрес для проверки подлинности, и отправляет их обратно в службу входа и входа. Служба отправляет URL-адрес во внешний интерфейс, чтобы открыть URL-адрес для проверки подлинности во всплывающем окне, так что redis - это здорово и очень быстро по моему опыту.

Для отправки сообщений игроку каждый игрок может подписаться на уникальную тему, а другие игроки могут отправлять сообщения по этой теме для этого конкретного игрока, используя redis pub / sub , и все игроки могут подписаться на глобальную тему, как только они вошли в систему, чтобы иметь личные сообщения и глобальные сообщения.

Легко кешировать идентификатор активных игроков в redis и обновлять его каждый конкретный промежуток времени или когда происходит конкретное событие, например, вход в систему или выход из системы, возможно, используйте Hash map, чтобы пометить пользователей как активных или нет HMSET .

Redis очень быстр, вы можете использовать его для сравнения .

Но обратите внимание, что redis хранится в памяти, поэтому вы должны быть осторожны и помнить, что отказоустойчивость читается о Redis Sentinel .