Node.js, Socket.io, Redis Pub / Sub большой объем, трудности с низкой задержкой

При соединении socket.io/node.js и redis pub / sub в попытке создать систему веб-трансляции в реальном времени, управляемую серверными событиями, которая может обрабатывать несколько транспортов, кажется, что есть три подхода:

'createClient' a redis connection and subscribe to channel(s). On socket.io client connection, join the client into a socket.io room. In the redis.on("message", ...) event, call io.sockets.in(room).emit("event", data) to distribute to all clients in the relevant room. Like How to reuse redis connection in socket.io?

'createClient' a redis connection. On socket.io client connection, join the client into a socket.io room and subscribe to relevant redis channel(s). Include redis.on("message", ...) inside the client connection closure and on receipt of message call client.emit("event", data) to raise the event on the specific client. Like the answer in Examples in using RedisStore in socket.io

Use the RedisStore baked into socket.io and 'broadcast' from the single "dispatch" channel in Redis following the socketio-spec protocol.

Номер 1 позволяет обрабатывать подпункт Redis и связанное с ним событие один раз для всех клиентов. Номер 2 предлагает более прямой доступ к Redis Pub / Sub. Номер 3 проще, но предлагает мало контроля над событиями обмена сообщениями.

Однако в моих тестах все показали неожиданно низкую производительность с более чем 1 подключенным клиентом. Рассматриваемые события сервера - это 1000 сообщений, опубликованных на канале Redis как можно быстрее, чтобы распространяться как можно быстрее. Производительность измеряется по времени на подключенных клиентах (на основе socket.io-client, которые записывают метки времени в список Redis для анализа).

Я предполагаю, что в варианте 1 сервер получает сообщение, а затем последовательно записывает его всем подключенным клиентам. В варианте 2 сервер получает каждое сообщение несколько раз (один раз для клиентской подписки) и записывает его соответствующему клиенту. В любом случае сервер не получает второе событие сообщения до тех пор, пока оно не будет передано всем подключенным клиентам. Ситуация явно обостряется с ростом параллелизма.

Это, кажется, противоречит воспринятой мудрости возможностей стеков. Я хочу верить, но я изо всех сил.

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

Ответы на вопрос(1)

Ваш ответ на вопрос