Highload chat on node.js, clustering, redis. How is message broadcasting done?

Question

JavaScript

I found an example of a chat on a node under the highload ( code , description ). Made using workers through the built-in cluster + redis hashring library. Broadcasting of messages, judging by the description, is done through redis pub/sub, but I can't understand how it works. Workers do not communicate with the master in any way.
Initially, the connection starts with a handshake, a random id is generated, which serves as a key for each connection. The connection itself, as far as I understood in the node style, is a readable stream. When a message arrives, a command is extracted from it and the corresponding function is called in accordance with it. Handshake calls initSession from chatManager.js , which is passed a message and a connection stream as arguments. In initSession, fields are created and initialized in the connection stream and a subscription to the group channel is created.
Here are my main questions, in terms of functions: subscribe(connection) from the initSession file and listenChannel(channelId, onMessageCallback, context, callback) from messageManager.js.
Why store connections everywhere in arrays and objects, because they are not synchronized between workers in any way, and why do this if everything happens through pub/sub? Accordingly, why is the distribution of messages (the onMessage function, which is passed as a callback) going through the enumeration of these saved connections, and not just through a callback on a message from a radish with a passed stream as a closure?
I think there's something here that I'm missing

Answer 1

Passing socket handles to child processes here is in the built-in cluster library and is hidden from the developer. Also, all processes write and read from the radish (see incr/decr, zrem/zadd calls in the code). Processes subscribe to Redis channels (see conn.on('message'...) and conn.on('subscribe'...) in the code). The code in this repository has not changed for three years, scaling only to a few processes on one machine, nothing unique has been written, all this functionality is in radish, a lot of resources will be spent to ensure inter-process communication of the node with it, it’s not even interesting to watch this implementation . This is outdated rubbish, the node has already changed in three years, but how the infrastructure and the possibilities of additional packages have changed...