使用消息队列扩展 WebSocket
我已经构建了一个 WebSockets 服务器，它充当聊天消息路由器(即从客户端接收消息并根据客户端 ID 将它们推送到其他客户端).
I have built a WebSockets server that acts as a chat message router (i.e. receiving messages from clients and pushing them to other clients according to a client ID).
要求服务能够扩展以处理数百万并发打开的套接字连接，并且我希望能够水平扩展服务器.
It is a requirement that the service be able to scale to handle many millions of concurrent open socket connections, and I wish to be able to horizontally scale the server.
我想到的架构是将 websocket 服务器节点放在负载均衡器后面，这会产生问题，因为连接到不同节点的客户端不会相互了解.当客户端 A 和 B 都通过 LoadBalancer 进入时，客户端 A 可能与节点 有开放连接>1 而客户端 B 连接到节点 2 - 每个节点都拥有自己的开放套接字连接字典.
The architecture I have had in mind is to put the websocket server nodes behind a load balancer, which will create a problem because clients connected to different nodes won't know about each other. While both clients A and B enter via the LoadBalancer, client A might have an open connection with node 1 while client B is connected to node 2 - each node holds it's own dictionary of open socket connections.
为了解决这个问题，我想使用一些MQ系统，比如ZeroMQ或RabbitMQ.所有的 websocket 服务器节点都将是 MQ 服务器的订阅者，当一个节点收到一个请求将消息路由到不在本地连接字典中的客户端时，它会pub-lish 向 MQ 服务器发送消息，该消息将告诉所有 sub-scriber 节点查找此客户端并在它连接到该客户端时发出消息节点.
To solve this problem, I was thinking of using some MQ system like ZeroMQ or RabbitMQ. All of the websocket server nodes will be subscribers of the MQ server, and when a node gets a request to route a message to a client which is not in the local connections dictionary, it will pub-lish a message to the MQ server, which will tell all the sub-scriber nodes to look for this client and issue the message if it's connected to that node.
Q1:这个架构有意义吗?
Q2:这里描述的 pub-sub 模式真的是我想要的吗?
Q2: Is the pub-sub pattern described here really what I am looking for?
ZeroMQ 将是我的选择 - 无论是在架构方面还是在架构方面性能方面
-- 快速 &低延迟(可以衡量您的实施性能和开销，低至亚 [usec] 规模)
ZeroMQ would be my option - both architecture-wise & performance-wise
-- fast & low latency ( can measure your implementation performance & overheads, down to sub [usec] scale )
-- broker-less(不会引入另一个故障点，而本身可以具有{N+1 | N+M}自愈架构)
-- broker-less ( does not introduce another point-of-failure, while itself can have { N+1 | N+M } self-healing architecture )
-- smart 准备使用的正式通信模式原语 ( PUB/SUB 是最不重要的 )
-- smart Formal Communication Pattern primitives ready to be used ( PUB / SUB is the least cardinal one )
-- 公平队列 &负载平衡架构内置(外部观察者不可见)
-- fair-queue & load balancing architectures built-in ( invisible for external observer )
-- many 用于服务器端内部多进程/多线程分布式/并行处理的传输类
-- many transport Classes for server-side internal multi-process / multi-threading distributed / parallel processing
-- 准备好几乎线性可扩展性
-- ready to almost linear scaleability
这是一个更复杂的主题.您创建可行架构的意图必须深入研究更多细节才能解决.
This is a bit more complex subject. Your intention to create a feasible architecture will have to drill down into more details to solve.
- 节点身份验证与点对点消息传递
- 节点(重新)发现与合法&隐私问题
- 基于节点的自治自组织代理与中央政策执行的需求