                        课程
                    
                        /后端开发
                        
                            /Go
                        
                        /GO实现千万级WebSocket消息推送服务

逻辑层广播到网管层会不会太浪费资源了呢

上一节课，不是说可以维护，用户连接，房间一个映射关系吗，通过这个映射关系推送到指定的网管层，与直接广播到所有的网管节点有啥利弊呢

i岁月无声

2018-07-31

源自：GO实现千万级WebSocket消息推送服务 5-3

关注问题我要回答

1183

操作

收起

3 回答

小鱼儿老师
2018-08-01

前置前置再前置，把合并越推向原点，对系统整体优化效果更佳，掌握这一点即可！

0 回复有任何疑惑可以回复我~

收起回答

小鱼儿老师
2018-08-01

字数限制。

实际上内部通讯也需要合并推送，这个出于简化原因我没有实现在开源代码里。所有的无状态logic应该按room推送消息到消息队列（按room分区），然后通过pusher服务去完成房间粒度的消息合并，并广播给gateway。

思考架构问题需要考虑场景，切忌空谈性能，在具体场景下有具体的难点和具体的应对方案，这个思想很重要。

1 回复有任何疑惑可以回复我~

收起回答

小鱼儿老师
2018-08-01

嗯，这个问题很有意思，引申出了这个分布式系统后续的一些走向，我简单延伸一下。

如果是定向给某个用户推送，我们一般会在逻辑服务器后面设计一层session服务，记录用户在哪些gateway上，从而减少不必要的广播。
如果是定向给某个房间推送，需要我们主动的连接调度，用户进入房间前先询问服务端，由服务端指派网关节点地址，这样尽量来把同一个房间的用户聚集在一起，你可以想一下增加这个特性的性价比有多少。

我觉得在弹幕场景里，内部节点之间的广播消息量并不是瓶颈（特指内网带宽瓶颈），因为100万人*10个网关在线，你推送1条弹幕的瓶颈永远在网关层。

所以，在考虑生产环境的扩展性架构决策时，gateway+logic应该作为一个服务单元（我们也称为set），通过部署多套set来实现大规模集群部署，具体一个房间只需要调度到某个set即可保障其高可用和高吞吐。

1 回复有任何疑惑可以回复我~

收起回答

i岁月无声提问者

对于一个直播平台除了几个大房间之外还有其他的房间，有任何一个消息，都广播到所有网关层，这个压力不会成为系统瓶颈吗？

2018-08-01 回复有任何疑惑可以回复我~

小鱼儿老师回复 i岁月无声提问者

嗯，弹幕系统是读比写要多多多多多多多的场景，大主播的弹幕频率你完全可以以1万/秒来计算，对每个gateway的广播压力就是1万/秒，gateway来说是毛毛雨，对logic来说也是毛毛雨。在这个量级下，对外推送的带宽就很大了，要乘上在线用户数（比如100万），那就是1000万/秒的推送系统啦。上述是一个set内的情况，你能无限的部署set，那么扩展性就永远不是问题，大不了一个主播一个set，只要公司有钱买服务器和带宽。

2018-08-01 回复有任何疑惑可以回复我~

精慕门4429612

哈哈哈哈哈

2018-08-03 回复有任何疑惑可以回复我~