thanks for the invitation.
first of all, I have never done a ws cluster myself, but I am interested in answering it.
generally speaking, whether tcp or ws (of course, ws is essentially tcp) actively push information out, relying on the fd file descriptor. Server1's clientA should have its own file descriptor on server1, and server2's clientB should have its own file descriptor on server2. You should understand this.

I think you can determine that "the long link of ClientA is on server1 and the long link of clientB is on server2". For example, you can use hash or uid to determine that a user will establish a long link with a server. As long as this is confirmed, you can also drop the "message sent to clientB" to the server where clientB establishes a long link, and then you can naturally push the message to clientB using fd through this server.

there should be a better solution. Follow.

uid+serverip+fd be implemented?

clientA --> server1 | send msg to clientB
            server1 | Find clientB at server2 (hash / radis / broadcast)
            server1 | connect server2 as websocket client
server1 --> server2 | msg to clientB from clientA
server2 --> clientB | receive msg from clientA

the same server message and different server message structure should be different
similar to Warcraft cross-server message

[from A:to B:msg] A(server1) => B(server1)
[from A@1:to B@2:msg] A(server1) => B(server2)

first of all, I would like to thank all the technical experts for their answers and ideas.

in practice, I found that native Swoole does not support Cluster, and then I have studied SwooleDistributed, for a long time, but it is also very troublesome to cooperate with the configuration of Consul,. I finally gave up. I chose Workman, that supports asynchronous MySQL, and asynchronous Redis, that supports Cluster. This is what is used in the temporary project, and we will continue to follow up Swoole's support for Cluster in the future.

Thank you all!

I answered casually. I didn't do anything like it. I just thought about the general idea. It may not be correct. There must be a lot of questions

ideas:

Store user session information, store user ID, server number, fd

when you want to send it to a user, check the server number and fd according to the user's ID,. Communicate with the specified server, specify the server, and then push the data to the specified fd

1. Add a nginx in front. Nginx supports websocket reverse proxy, while nginx also supports load balancing. It is up to nginx to decide which server to access
2. Message push, simple can use nsq, need more functions to use mq, these two are very stable, and support cluster

first of all, you need to understand that the essence of the problem is that you are not in the same process space (on different servers, of course) and you cannot communicate directly because you cannot share tcp connections or directly operate the corresponding tcp connections

now suppose you have a cluster with multiple machines with the same service (every day as a work process): An and B
now you want to communicate from a certain connection (a customer) in A to a connection (a customer) in B:

1. start a server M
2. in the startup process of An and B, open a client that connects to M (we call it C1MagneC2, respectively), and listen for events
3. A connection (a client) sends a message to A server. A server processes the relevant B identification user data, transfers it to C1, and then C1 sends a message to M server
4. then the M server sends messages to all connected clients (of course, if you make the appropriate user ID and identify C2, you can send a message directly to C2)
5. M sends a message to C2, then C2 finds a specific connection in B according to the identity, and then sends the message directly