search

SocketCluster / socketcluster

Highly scalable realtime pub/sub and RPC framework
https://socketcluster.io
MIT License
6.15k stars 314 forks source link

Queries on SCC architecture #525

Closed Energytechglobal closed 4 years ago

Energytechglobal commented 4 years ago

Hi Jonathon,

We are using SCC in our chat application. We have gone through the documentation to scale our application horizontally and have got some questions. Could you please go through our understanding and provide us with the answers for the questions asked?

Our understanding of SCC architecture:

  1. In order to scale socketcluster horizontally, we use SCC.
  2. SCC is made up of:
    • Socketcluster or scc-workers
    • scc-state
    • scc-brokers
  3. scc-state needs to be running only while scaling. Whenever scc-broker joins the cluster, this helps in sharding pub/sub channels across all the available scc-broker instances. What does sharing mean here?
  4. scc-workers consists of workers and brokers.
    • This config is given via command line or can be maintained in .env file.
    • The workers are used for handling requests from clients(chat admin, web). These are child processes forked from Worker cluster.
    • The brokers are used for communication with scc-state.
  5. Please find the below diagram of SCC as per our understanding:

scc_architecture

Questions:

  1. What is the relationship between brokers and workers in scc-worker? When a socket connection is established with a worker, how is the request served and what is the role played by broker here?
  2. What is the use of scc-broker? Explain the wording “to broker messages between multiple frontend-facing scc-worker instances”.
  3. How is Redis or Redis cluster used in SCC?
  4. What is the difference between an scc-broker service and a broker of scc-worker?
  5. Do we need to have sticky sessions for sockets to work?
  6. As per scc-broker documentation, “All the pub/sub channels in your entire system will be sharded evenly across available scc-broker instances”. Please elaborate sharding here.
  7. Note: In the diagram, we have placed ‘?’ where we need to understand the relationship between entities.

Thanks in advance.

Regards, EnergyTech Global

jondubois commented 4 years ago
  1. Based on your description, it seems that you're using an SC version v14 or earlier. These versions of SC could scale both vertically and horizontally at the same time; the brokers inside inside scc-worker instances are local broker processes which have two jobs:

The existence of local broker processes in SC v14 and earlier means that (for certain use cases), fewer messages need to pass through the network because each message from the cluster is only delivered once per host (no matter how many worker processes there are on that host).

  1. scc-broker instances route messages between multiple scc-worker instances which are running on different hosts. Note that scc-worker instances contain local broker processes as you correctly pointed out - These local broker processes are part of the scc-worker instances and they're the ones which connect with the remote scc-broker instances and forward messages to the local worker processes. A broker process is both a server and a client; it's a server to worker processes but it's also a client of scc-broker instances and it proxies messages between the two based on who is subscribed to what channels. Note that even though this approach was more efficient for certain use cases, the concept of local broker processes was removed in SC v15 to simplify the architecture and provide more flexibility to developers.

  2. It's not by default, but it could be used instead of scc-broker instances with some work because Redis supports similar pub/sub features those of scc-broker.

  3. Hopefully the first two points answer this.

  4. No, unlike other solutions which rely on HTTP polling, with SC, once the initial connection is passed to one of the local worker processes, the client will stay connected that worker so there is no need for session stickiness in the load balancers.

  5. This is to prevent all the channel data in the entire system from passing through a single scc-broker instance. That would overwhelm the instance; that is why, if you have multiple scc-broker instances, it will apply a mapping function (on the scc-worker) to decide which of the x available scc-broker instances should manage each channel based on its name. The mapping function is deterministic but it ensures even distribution between all available scc-broker instances so that the load is split evenly between them. The mapping function uses an algorithm called rendezvous hashing (skeleton-based) which gives even distribution and is efficient at handling scenarios where scc-broker instances are regularly added to and removed from the cluster.

  6. Channel messages do not pass through the scc-state instance. scc-state only keeps track of and tells scc-worker instances about the state of the cluster; that's all. scc-broker instances are the ones which actually forward the messages. scc-state is only needed when the state of the cluster has changed.

Energytechglobal commented 4 years ago

Thanks, Jonathan for the explanation. Yes, we are using socketcluster version 14.4.2.

Could you also suggest the following?

  1. What is an ideal ratio between local brokers and local workers within an scc-worker?
  2. What is an ideal ratio between scc-brokers and scc-workers?

Regards, EnergyTech Global

frank-dspeed commented 4 years ago

@Energytechglobal you will need to benchmark this on your environment there is no one fit all recipe.

a good starting point is 1 broker per worker

Energytechglobal commented 4 years ago

Thanks, Frank for the suggestion. And once again thanks, Jonathan for the detailed explanation. It was really helpful. I am closing this one.

Regards, EnergyTech Global