当连接socket.io/node.js和redis pub/sub以尝试创建由可处理多个传输的服务器事件驱动的实时Web广播系统时,似乎有三种方法:
'createClient'是一个redis连接并订阅了频道.在socket.io客户端连接上,将客户端加入socket.io会议室.在redis.on("message",...)事件中,调用io.sockets.in(room).emit("event",data)以分发给相关房间中的所有客户端.喜欢如何在socket.io中重用redis连接？
'createClient'是一个redis连接.在socket.io客户端连接上,将客户端加入socket.io会议室并订阅相关的redis频道.在客户端连接闭包内和收到消息调用client.emit("event",data)时包含redis.on("message",...)以在特定客户端上引发事件.就像在socket.io中使用RedisStore的示例中的答案一样
使用RedisStore烘焙到socket.io和'广播'从Redis中的单个"调度"通道遵循socketio-spec协议.
Number 1允许为所有客户端处理一次Redis子和相关事件.Number 2为Redis pub/sub提供了更直接的钩子.3号更简单,但几乎无法控制消息传递事件.
但是,在我的测试中,所有连接的客户端都表现出意外的低性能.有问题的服务器事件是尽快发布到redis频道的1,000条消息,以便尽快分发.性能是通过连接客户端的时间来衡量的(socket.io-client基于该日志时间戳到Redis列表中进行分析).
我猜测在选项1中,服务器接收消息,然后顺序将其写入所有连接的客户端.在选项2中,服务器多次接收每个消息(每个客户端订阅一次)并将其写入相关客户端.在任何一种情况下,服务器都不会进入第二个消息事件,直到它被传递给所有连接的客户端.随着并发性的上升,情况显然更加恶化.
这似乎与堆栈功能的感知智慧不一致.我想相信,但我在苦苦挣扎.
这种情况(大量消息的低延迟分布)是不是这些工具的选项(但是？),还是我错过了一个技巧？