共计 3239 个字符，预计需要花费 9 分钟才能阅读完成。
世界杯 ⚽️ 期间，我与其余的梅西粉丝在某 APP 里建了个梅粉聊天群，群内人数上万人，大家一起探讨赛事热点，堪称热气腾腾，此起彼伏，这是四年一度的狂欢，虽值夏季，但激情不减。
“阿根廷 1 比 2 遭沙特逆转！！！！”
“反对阿根廷队！！！！”
“球王梅西加油啊”
“想梅西有一个好的闭幕”
……
梅西进球的一刻，冲动的心颤动的手，霎时中转高兴巅峰，万人齐呼梅西英武；遭沙特逆转之时，情绪失落无以言表，群内刷满了对梅西率领下的阿根廷队惜败沙特的震惊、恍惚、悲哀、可惜。
是的，我被梅粉群的万条音讯刷屏了。
大型群聊汇集了同一我的项目爱好者，将单纯的群聊性能转变为线上俱乐部性质的大型发烧友群聊，上述场景中大规模球迷们的即时消息推送，是区别于一般 IM 房间的，相似这种超大规模 IM 通信场景，如 万人观看直播并进行互动评论 、 万人搭建趣味群聊 等都会面临 人数无下限、音讯高并发的状况，所以设计一套稳固牢靠的架构来保障用户通信的稳定性与可靠性就十分必要。
百万人超大房间即时通讯面临的问题
所谓百万人超大房间即时通讯，就是指反对百万人同时在房间中发送即时消息，进行线上互动。越是这种大规模即时通讯的背地，越是须要进行精心的架构设计，接下来咱们以一个百万人超大房间为例，来看看针对这种大规模互动的 IM 通信场景，到底要在架构设计环节中思考到哪些问题能力更好的保障用户通信的高质量。
- 高并发进出房间：比方定期做流动时，面对房间内霎时涌入的大量用户，就须要解决高并发房间的进出，以及推送房间进出变更告诉；
- 音讯推送：每发送一条音讯，都要推送给近一百万人，推送压力极大；
- 客户端性能：同一时段往房间内发送大量音讯，如果将所有音讯都推送给客户端，很可能导致客户端呈现卡顿、音讯提早等问题，进而重大影响用户体验；
- 对外感知：百万级超大房间与一般房间反对性能是否有差异，对外感知是否一样，客户是否有额定的接入老本；
- 音讯存储：海量音讯的状况下，如果每条音讯都长期存储，将导致服务缓存使用量激增，使得内存、存储成为性能瓶颈。
上述列出的这些问题，是咱们在设计百万人超大房间架构时须要思考到的。ZEGO 即构科技在之前推出的 ZIM（ZEGO Instant Messaging） 中，针对大规模百万人房间即时通讯做了非凡的架构设计，以实现安全可靠、有序稳固的线上互动！
房间性能个性比照首先，咱们来比照下一般房间与 ZIM 中超大房间在性能个性上的差别，次要体现在以下两点：
- 对超大规模房间的人数不做限度；
- 收发音讯，设置房间 kv 属性等性能要保障可靠性。
下图列出了 ZIM 中超大房间与一般房间的性能个性比照：
从上图中咱们能够清晰的看到一般房间与超大房间的差别，接下来咱们一起看下即构 ZIM 在超大房间架构模型设计上的思考与实际。
ZIM 超大房间架构模型
ZEGO 实现超大房间的服务架构如下图所示，其中次要的设计理念是：将超大房间拆分成多个子房间，散布到不同的 worker 节点来解决，以解决单点问题。
作为 to B 公司，子房间的概念只在咱们的 SDK 与后盾服务之间交互时应用，能够 平滑的从一般房间切换到超大房间，对客户是齐全无感知 的，不须要为此减少接入老本。
超大房间架构图
对于上图中的各服务，咱们来具体的介绍下各模块的具体性能：
- 接入服务：负责客户端的接入；
- room-router：路由服务（简称 router），来自客户端的申请会随机抉择一台 router 节点，而后 router 依据特定规定路由到 room-worker 节点；
- room-worker：工作过程（简称 worker），负责具体的业务解决，比方进入房间、退出房间、发送房间音讯等；
- 推送服务：负责各种信令与音讯的推送，比方进出房间告诉，音讯推送等。推送服务与工作过程之间通过音讯队列解耦；
- 缓存数据库：存储房间各种信息，包含房间用户列表、房间 kv 属性、音讯列表等。
技术实现的要害逻辑
为实现超大房间，咱们对许多逻辑性能做了针对性的优化，次要体现在以下几点：
1 房间扩大
概念上，咱们称最后建设的房间为“主房间”，如果主房间人数满了（比方 500 人），则为其调配“子房间”。当有新用户进入房间时，如果主房间或者子房间还有空位，则进入相应房间；如果人数都满了，则会持续调配新的子房间。
为了正当抉择房间（包含主房间与子房间）进入，须要 保护每个房间的人数信息，做好房间人数信息同步，以及正当设计房间抉择策略。
1.1 房间人数信息同步
对于高并发的进房间申请，每次进房间解决是须要工夫的，等进房间胜利了再更新房间人数，很可能导致大量申请涌入到同一个房间。
为了解决高并发进房间的问题，即构提出 “预调配人数”概念，即调配给某个房间一个新的用户，就将预调配人数加一，预调配人数满了，则不再进入新的用户。
1.2 房间抉择策略
router 依据缓存的房间人数信息，抉择没有满员的房间进入。如果所有房间都满了，随机抉择一个，由 worker 做下一步解决。
因为 router 节点有多台，且缓存的房间人数信息有可能滞后，worker 节点解决进房间申请时，该房间可能曾经满了，如果呈现这种状况则执行“重定向逻辑”，从新抉择或新建一个子房间。
重定向逻辑次要有：
- 抉择没有满员的房间进行重定向；
- 如果所有房间都满了，则新建一个子房间；
- 为了避免进入房间时，呈现间断屡次重定向，对于曾经是重定向的申请，能够超出房间人数下限，保障进入房间胜利。
2 房间合并
随着房间用户的进出，如果呈现多个子房间人数较少的状况，则被动合并子房间，缩小服务端性能耗费。合并中的房间不容许新的用户进入，房间合并后，客户端与新的子房间进行交互。
3 房间音讯的发送与拉取
用户发送房间音讯时，由该用户所在子房间进行解决，以防止单点问题。子房间同时会将音讯扩散给其它子房间，拉取音讯时只须要从子房间进行拉取。音讯的发送与拉取过程如下：
房间音讯发送与拉取过程图
这其中蕴含的次要步骤如下：
发送房间音讯：由子房间解决，并扩散给其余子房间节点。
音讯扩散：子房间所在节点会在服务缓存内保护一份音讯列表，一个节点只须要保留一份，如果一个节点蕴含多个子房间，则共享这份信息。
音讯存储：将全量音讯保留在缓存数据库，worker 节点重启或者音讯不间断时，能够从缓存数据库中复原。
音讯拉取：音讯拉取同样会扩散到各 worker 服务，防止单点问题。
房间 kv 属性的批改与房间音讯的实现相似，此处不再独自进行介绍。
4 音讯推送
音讯推送最大的难点就是推送的扩散，在超大房间场景中，房间成员变更、房间属性变更，聊天音讯都会扩散给房间内所有用户，对于百万人数级别的房间，这个扩散量是十分大的，对服务器性能与带宽都是很大的考验。
4.1 推送扩散问题解决
为解决扩散问题，在接入层间接保留房间的用户列表信息，推送音讯时，外部服务只须要推送一个包到接入服务，而后由接入服务进行扩散，能够大幅升高推送扩散水平。
咱们以发送房间音讯为例，看下推送过程：
音讯推送过程图
4.2 进一步优化推送包数量
推送到客户端的音讯包量过多时，对服务端与客户端都有很大的压力，咱们通过合并推送进一步升高推送包的数量。
将多条音讯合并后一起推送给客户端，意味着有些音讯会产生推送提早。为了兼容推送速度与推送性能，即构应用 分阶梯推送策略：音讯量比拟小时，不做合并，逐条即时推送；音讯量比拟大时，再逐渐晋升合并条数。
总结
在已有实例参考的一起看球、一起看电影的场景中，从数十人的小型同好会变成超大型的线上俱乐部、论坛等，ZEGO 即构科技在 ZIM 中的大规模房间架构设计让更多人实时在线互动成为可能，也让泛滥不可线下观球的梅粉们远距离嗨翻屋顶、百万人同频交换！
ZEGO 即构科技 ZIM 大规模房间架构设计——
可反对房间人数无下限，超大房间与一般房间之间平滑切换；
可在接入层保留房间信息，晋升推送性能，并且大幅度降低带宽耗费；
有灵便的推送策略，兼顾低频时的推送速度，以及高频时的推送性能；
收发音讯与设置属性都保障牢靠！
最初，让咱们祝愿梅西 ⚽️，捧得大力神杯🏆！
