Какой сокет ZeroMQ рекомендуется для этого сценария?

Question

Мы строим платформу онлайн-игр (на основе браузера) поверх WebApi и SignalR. Одним из наших приоритетов является время отклика с малым временем ожидания и масштабируемость. Что касается масштабируемости, мы рассматриваем метод масштабирования, чтобы распределять нагрузку приложения на несколько узлов сервера. Однако эта архитектура не возникает без дополнительных сложностей.

Позвольте мне описать проблему, прежде чем задавать свой вопрос. Рассмотрим, что у нас есть 2 серверных узла для целей балансировки нагрузки. И мы говорим, что 50 000 игроков онлайн. 50% игроков подключены к Node1 и еще 50% к Node2 с помощью SignalR/Websockets. Теперь проблема возникает, когда Node1 должен доставить сообщение игроку, который подключен к Node2. Между Node1 и игроком нет физической связи.

Так что теперь у нас есть 2 возможных решения:

1. Force группа аналогичных игроков присоединиться и тот же узел. Однако этот подход поставил больше проблем, чем он исправил (особенно во время восстановления после сбоев), для нашего сценария. Я не буду вдаваться в подробности.
2. Разрешить узлам связываться друг с другом, поэтому, когда node1 необходимо отправить сообщение клиенту, подключенному к узлу2, node1 сделает это с помощью node2 (что-то вроде node1 -> node2 -> client). В этом случае каждый узел будет связан с каждым другим узлом.

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

Именно поэтому мы решили использовать ZeroMQ. Мы протестировали его (REQ-REP), а производительность - это больше, чем наш приемлемый запас. Но есть улов. Я несколько раз читал documentation, но это смутило меня больше, чем дал мне идеи. Короче говоря, я понятия не имею, какой тип сокета использовать в моем сценарии. Мне не нужны очереди сообщений, если узел отключен, просто чтобы игнорировать его.

Так что любая рекомендация/помощь будет приятной. Кроме того, если кто-то найдет время для краткого описания того, почему конкретный сокет/паттерн лучше подходит для нас, будет еще лучше :)

Answer 1

Один из способов добиться этого - предоставить каждому клиенту (игроку) возможность иметь маршрутизатор сокет с идентификатором сокета, являющимся идентификатором игрока, чтобы обеспечить связь между узлом и игроком. Затем вы можете использовать некоторые шаблоны брокера, доступные на 0MQ - The Guide, для поддержки того, что вы собираетесь делать. Документация на роутер-сокет также доступна по ссылке.

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