TL; DR;- Я хочу использовать корреляционные фильтры 10–100 тыс. По теме ASB для маршрутизации входящих сообщений на серверы веб-сокетов и доставки уведомлений пользователям.
Контекст: я пытаюсь придумать дизайн для распределенногосистема доставки уведомлений, которая использует кластер серверов WebSocket (WS) для доставки уведомлений (включая чат и события учетной записи пользователя) клиентам, подключенным к серверам WS.Очевидно, что поскольку WS-соединения являются постоянными между клиентом и WS, когда событие отправляется где-то в моей системе, чтобы доставить его нужному клиенту, мне нужно знать, какой сервер WS должен обработать сообщение.
Хотя я не хочу использовать Redis pub / sub из-за отсутствия возможности подтверждения или организации очередей, RabbitMQ выглядит так, как будто это отвечает всем требованиям: я могу настроить прямой обмен таким образом, чтобы всякий раз, когда сервер WS запускался, он создавалновая очередь под этим обменом, и каждый раз, когда клиент подключается к серверу WS, я добавляю новый ключ привязки (равный идентификатору пользователя) между обменом и очередью сервера WS.Таким образом, когда событие публикуется в обмен с данным идентификатором пользователя, все серверы WS получат сообщение в своих очередях для обработки.
Однако я не хотел бы управлять своим собственным кластером RabbitMQ - нидля настройки / конфигурации, ни по причинам стоимости.Учитывая, что мое приложение, скорее всего, будет размещено в Azure, я мог бы также использовать Azure Service Bus.До недавнего времени я не знал, что он может справиться с такой рабочей нагрузкой, но я просто читал, что если я использую темы (эквивалентные обменам RMQ), каждый сервер WS может создать свою собственную подписку (эквивалентную очередь RMQ) и добавить фильтрдля этой подписки, чтобы при публикации сообщения с определенными свойствами в теме подписка (т. е. очередь сервера WS) получала сообщение, доставленное ей после фильтрации. Настройка будет заключаться в том, что каждый раз, когда клиент подключается к серверу WS, этот сервер добавляет в свою подписку новый фильтр, равный идентификатору пользователя.
Что это означает, что если яесли у меня 10 тыс. активных пользователей с подключениями WS, в моей теме будет установлено 10 тыс. фильтров.
Меня интересуют две основные вещи (но перспектива приветствуется!):
Быстрое ли добавление новой функции к подписке и эффективность использования ЦП и памяти?
Имеет 10k фильтров корреляции (и, возможно, больше! Кажется, ASB)поддерживать до 100 тыс. фильтров корреляции по теме) слишком много увеличится моя задержка, если я принимаю что-то вроде 100 сообщений в секунду?Я бы хотел, чтобы моя сквозная задержка (событие, опубликованное в ASB) -> (клиент получил сообщение) была меньше 100 мс.(поэтому необходимо принять к сведению ASB, доставку на сервер WS и доставку оттуда к клиенту).
Если нет хороших или прямых ответов, я также был бы признателен за качественную информацию:)
Спасибо!