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