Pergunta

I have noticed that Socket.io is using two separate connections for Pub and Sub to Redis server. Is it something that could improve the performance? Or is it just purely a move towards more organized event handlers and code? What are the benefits and drawbacks of the two separate connections and one single connections for publishing and subscribing.

P.S. The system is pushing about an equal number of messages that it is receiving. It pushes updates to the servers, which are on the same level in the hierarchy, so there is no master, pushing all of the updates, or slave, consuming the messages. One server would have about 4-8 subscriptions and it will send the messages back to these servers.

P.S.S. Is this more of a job for a purpose-built job queue? The reason I am looking at Redis. is that I am already keeping some shared objects in it, which are used by all servers. Is message queue worth adding yet another network connection?

Foi útil?

Solução

You are required to use two connections for pub and sub. A subscriber connection cannot issue any commands other than subscribe, psubscribe, unsubscribe, punsubscribe (although @Antirez has hinted of a subscriber-safe ping in the future). If you try to do anything else, redis tells you:

-ERR only (P)SUBSCRIBE / (P)UNSUBSCRIBE / QUIT allowed in this context

(note that you can't test this with redis-cli, since that understands the protocol well enough to prevent you from issuing commands once you have subscribed - but any other basic socket tool should work fine)

This is because subscriber connections work very differently - rather than working on a request/response basis, incoming messages can now come in at any time, unsolicited.

publish is a regular request/response command, so must be sent on a regular connection, not a subscriber connection.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top