An overview of the

This paper discusses the webSocket cluster scheme:

  1. In webSocket cluster, the back end accurately pushes the specified message to the specified user, and the front end receives the message pushed by the service in real time
  2. Discuss the scheme of Websocket cluster, and determine the best scheme

Webscoket cluster solution

Cluster Scheme Analysis

In the last post, Spring Boot series 20 Spring Websocket implementation sends a message to a specified user, but we will provide Websocket services for clustering (as shown in the figure above), there are the following problems:

In the figure above, user A registers with service A via webSocket, and service A subscribes to RabbitMQ messages via STOMP, as does user B. If user A is connected to service A, even if the MQ module on service B uses the SimpMessagingTemplate instance to send A message to user A, the message cannot reach user A because service B does not have the registration information of service A and cannot push the message accurately. The message will only reach user A if the MQ module on service A sends the message to this user using the SimpMessagingTemplate instance

In view of this problem, the following three solutions are adopted to solve this problem, and the shortcomings of each solution are analyzed in detail.

WebSocket cluster solution 1

No matter which service the recipient of A message is connected to, each service A/B receives the message and pushes the same message using the SimpMessagingTemplate instance to ensure that A message will always be received by the user.

The detailed process is as follows:

  1. User A and user B connect to service A and Service B through WS, and service A and Service B access RabbitMQ through STOMP
  2. Message senders send messages to RabbitMQ switches, using sector switches. This ensures that the same message can be received by service A/B at the same time
  3. The MQ module on both services receives the message and pushes the message directly to the user specified in the message using the SimpMessagingTemplate instance, regardless of whether the user is connected to RabbitMQ
  4. User A or B receives the corresponding message. Procedure

Advantages:

  1. It’s easy to implement

Inadequate:

  1. The RabbitMQ switch to which message producers send messages must be broadcast, such as a sector switch
  2. In order for the message to reach the user, the same message must perform the same operation on both services A/B. The more services there are, the more repeated messages will be sent
  3. If the user is not online, no matter how many messages are sent, the user cannot receive them

WebSocket cluster solution 2

Redis is used to cache the user’s WebSocket connection information, record which service the user is logged in to, and push the message to the service the user is logged in to when a message comes in. Then the service is pushed using SimpMessagingTemplate instance

The following functions are added on the basis of scheme 1:

  1. Add MQ modules to service A/B, which will connect to RabbitMQ and subscribe to queues A/B, respectively
  2. Service A/B adds WS module. When Websocket connects, the connection information of this user is stored in Redis, and the system remembers which service each user logs in to
  3. Message producers push messages to the switch, not directly to service A/B
  4. Add a new module dispatch, which receives the message, then reads from Redis to push the message to the server to which the user connects, and then sends the message to the queue corresponding to the user connection service. If a message is to be sent to user B, the Dispatch module sends the message to queue B
  5. When the MQ module of service A/B receives the message, it pushes the message to the specified user using the SimpMessagingTemplate instance

Advantages:

  1. This scheme overcomes the shortcomings of the previous one

disadvantages

  1. complex
  2. The number of MQ messages sent is doubled

WebSocket cluster solution 3

Overview Without using SimpMessagingTemplate, the Client API uses RabbitMQ to send messages directly to queues subscribed to by users on RabbitMQ

When a user logs in to websocket through a browser and registers for RabbitMQ, the connection will be queued up at RabbitMQ with a name similar to STOMp-subscription -***, bound to the default switch AMq. topic. The routing key is “Web subscription queue name +’-user’+ webSocket sessionId” (demo-userPjPLGGBL, demo is the queue name of stomp Weboscket connection, PJPLGGBL WebSocket sessionId value at webSocket login.

Based on this, the following architecture is designed:

The following modifications are made on the basis of scheme 1. The flow of the new architecture diagram is as follows:

  1. Service A adds A WS module to store the connection information of the user (mainly the WebSocket sesionId value) in Redis when the WebSocket connects
  2. The switch to which the message producer sends the message. These services do not push service A/B directly
  3. A new module dispatch is added, which receives the pushed information, reads the message from Redis and receives the corresponding Websocket sesionId value of the user, calculates the routing key corresponding to the user according to the above rules, and then sends the message to the queue subscribed by the user
  4. Front-end receiving messages

Advantages:

  1. It is easier than the second plan to overcome the shortcomings of the first plan

conclusion

Plan 3 is the best plan. In the next article, we’ll talk about how to implement Plan 3 in code. Okay