Implementing WebSocket in Projects - Cluster Scenarios

· 1 min read

Recently, WebSocket was implemented in our site, and immediately we faced communication issues in Web service clusters. In a multi-instance Web service environment, if user A subscribes to a WS channel on server A, but server B initiates a broadcast in the background, user A won’t receive the message. So the question is: how to handle broadcasts and send accurate messages to individual users in a cluster scenario?

Tech Stack

First, let me introduce our current project’s tech stack:

  • React v16.4.2
  • SpringBoot v2.1.6.RELEASE

Solution

Use Redis to share user information and implement message subscription broadcasts.

How to write the specific code? Without further ado, click here

General Process

  • When a user connects to WS, Redis stores the user information. All cluster instances are connected to Redis, so theoretically they can all access all user information.
  • If you want to send a point-to-point message, initiate a Redis broadcast. All instance Redis services will receive the message, find the target UID, and send the message if matched.
  • If you want to broadcast, initiate a Redis broadcast. All instance Redis services will receive the message and subsequently send it, so all users will receive it.

Is it necessary to add Kafka or MQ?

Many WebSocket cluster solutions found online mention adding a message queue. Currently, I don’t use it in the project. I personally think Redis is sufficient if the message volume is not large.

Conclusion

If you think about it, without a cluster, this problem wouldn’t exist.

So why do we need a cluster? Clustering physically increases the service instances to provide services to more clients. The service content is the same, but it also brings problems, like the one mentioned at the beginning of the article. To face such problems, Redis, as a NoSQL storage service, can be exposed to multiple clients to solve the issue.

This is the general idea, and I hope it can inspire some thoughts.

References

Authors
Developer, digital product enthusiast, tinkerer, sharer, open source lover