i岁月无声
2018-07-31 23:25
上一节课,不是说可以维护,用户连接,房间一个映射关系吗,通过这个映射关系推送到指定的网管层,与直接广播到所有的网管节点有啥利弊呢
前置前置再前置,把合并越推向原点,对系统整体优化效果更佳,掌握这一点即可!
字数限制。
实际上内部通讯也需要合并推送,这个出于简化原因我没有实现在开源代码里。 所有的无状态logic应该按room推送消息到消息队列(按room分区),然后通过pusher服务去完成房间粒度的消息合并,并广播给gateway。
思考架构问题需要考虑场景,切忌空谈性能,在具体场景下有具体的难点和具体的应对方案,这个思想很重要。
嗯,这个问题很有意思,引申出了这个分布式系统后续的一些走向,我简单延伸一下。
如果是定向给某个用户推送,我们一般会在逻辑服务器后面设计一层session服务,记录用户在哪些gateway上,从而减少不必要的广播。
如果是定向给某个房间推送,需要我们主动的连接调度,用户进入房间前先询问服务端,由服务端指派网关节点地址,这样尽量来把同一个房间的用户聚集在一起,你可以想一下增加这个特性的性价比有多少。
我觉得在弹幕场景里,内部节点之间的广播消息量并不是瓶颈(特指内网带宽瓶颈),因为100万人*10个网关在线,你推送1条弹幕的瓶颈永远在网关层。
所以,在考虑生产环境的扩展性架构决策时,gateway+logic应该作为一个服务单元(我们也称为set),通过部署多套set来实现大规模集群部署,具体一个房间只需要调度到某个set即可保障其高可用和高吞吐。
GO实现千万级WebSocket消息推送服务
21352 学习 · 56 问题
相似问题