Scaling Web Sockets with Message Queuing

Question

I built a WebSockets server that acts as a chat message router (i.e. receives messages from clients and redirects them to other clients according to client ID ).

The requirement is that the service can scale to handle many millions of concurrent open socket connections, and I want to be able to scale the server horizontally.

The architecture that I had in mind is to place the websocket server nodes behind the load balancer, which will create a problem because clients connected to different nodes will not know about each other. If both clients A and B LoadBalancer via the LoadBalancer , client A can have an open connection to node 1 , and client B connected to node 2 - each node contains its own dictionary of open socket connections.

To solve this problem, I thought to use some MQ system, for example ZeroMQ or RabbitMQ . All nodes of the websocket server will be subscribers of the MQ server, and when node receives a request to send a message to a client that is not in the local connection dictionary, it will be a pub -lish message to the MQ server in which all sub nodes will search for this client and display a message, if it is associated with this node.

Q1: Does this architecture make sense?

Q2: Is the pub-sub template described here what I'm looking for?

Answer 1

ZeroMQ will be my option - both in architecture and in performance

- fast and low latency (you can measure performance and overhead, up to the sub [usec] scale)

- without intermediaries (does not introduce another point of failure, but itself may have a self-healing architecture {N + 1 | N + M})

- Smart ready-to-use Formal Communication Pattern primitives ( PUB / SUB are the least cardinal)

- built-in queue and load balancing architecture (invisible to an external observer)

- a lot . Transport classes for server-side internal multiprocessor / multi-threaded distributed / parallel processing.

- ready for almost linear scalability

Adaptive node re-discovery

This is a more complicated question. Your intention to create an acceptable architecture will have to be deployed in more detail for the solution.

• Node authentication and peer-to-peer messages
• Node (re) -opening against legal and confidential issues
• Node based standalone self-organizing agents versus central policy application needs.