本文由微信开发团队工程师“ kellyliang”原创发表于“微信后台团队”公众号，收录时有修订和改动。php

一、引言

随着直播和类直播场景在微信内的增加，这些业务对临时消息（在线状态时的实时消息）通道的需求日益增加，直播聊天室组件应运而生。直播聊天室组件是一个基于房间的临时消息信道，主要提供消息收发、在线状态统计等功能。

本文将回顾微信直播聊天室单房间海量用户同时在线的消息组件技术设计和架构演进，但愿能为你的直播聊天互动中的实时聊天消息架构设计带来启发。

本文已同步发布于“即时通信技术圈”公众号，欢迎关注。公众号上的连接是：点此进入。html

二、相关文章

三、1500万在线的挑战

视频号直播上线后，在产品上提出了直播后台须要有单房间支撑1500w在线的技术能力。接到这个项目的时候，天然而然就让人联想到了一个很是有趣的命题：能不能作到把13亿人拉个群？

本文将深刻浅出地介绍聊天室组件在演进过程的思考，对这个命题作进一步对探索，尝试提出更接近命题答案的方案。node

四、直播聊天室1.0架构

如上图所示，能够看到直播聊天室1.0架构还比较原始和直接，没有太多复杂的技术应用。

这套架构诞生于2017年，主要服务于微信电竞直播间，核心是实现高性能、高实时、高可扩展的消息收发架构。程序员

五、消息扩散方案选型：读扩散

微信中标准的群消息使用的是写扩散机制，而直播聊天室跟微信标准群聊有着巨大的差别。

并且，对于同一人而言，同一时间只能关注一个聊天室，决定了直播聊天室中的消息扩散方案应该使用读扩散的机制。web

六、longpolling（长轮询）机制

为了让用户须要实时同步到新消息，咱们采用的是longpolling模式。

不少人会疑惑为何不用websocket，缘由有3个：redis

1）websocket主要考虑推模式，而推模式则有可能丢，作到不丢仍是有须要拉模式来兜底；
2）推模式下，须要精准维护每一个时刻的在线列表，难度很大；
3） longpolling本质是一个短连，客户端实现更简单。

七、无状态cache的设计

很明显，单纯的读扩散，会形成巨大读盘的压力。按照国际惯例，这里理所应当地增长了一个cache，也就是上面架构图中的recvsvr。

普通的cache都是有状态的、可穿透的，对常常会出现突发流量的聊天室不是特别友好。而经过异步线程任务，刚好能够解决这两个点。

① 实时通知：发送消息时，在写入列表后，向recvsvr集群发送通知。

② 异步拉取：recvsvr机器收到通知后，触发异步线程拉取。

③ 兜底轮询：当recvsvr机器上接收到某个聊天室的请求时，触发该聊天室的轮询，保证1s内至少访问一次消息列表，避免通知失效致使没法更cache，同时作到机器启动时数据的自动恢复：

④ 无锁读取：经过读写表分离和原子切换，作到消息的无锁读取：

⑤ sect化部署：群数量增多时，扩sect能够把群分摊到新的sect上。

无状态消息cache的设计，不只极大地提升了系统的性能，并且帮助聊天室创建了一个高扩展性消息收发架构。算法

八、技术痛点

尽管作到了高性能的消息收发，1.0版本却并不能实现单房间1500w同时在线的目标。

经过对整个架构和逻辑进一步的分析，咱们发现4个阻碍咱们前进的痛点：数据库

1）大直播间里，消息信道不保证全部消息都下发，连麦成功信令丢失会使得连麦功能不可用，大礼物打赏动画信令丢失会带来客诉；
2）一个房间的在线列表，是由recvsvr把最近有收取该房间的消息的user聚合到同一台statsvr获得的，有单点瓶颈，单机失败会致使部分房间在线数跳变、在线列表和打赏排行榜不可用等；
3）没有提供历史在线人数统计功能；
4）裸的longpolling机制在消息一直有更新的状况下，没法控制请求量。

九、直播聊天室2.0架构

从上面分析的痛点，咱们得出了聊天室2.0须要解决的问题：小程序

1）解决丢重要信令问题，保证热点访问下功能的可靠性；
2）解决在线统计的单点瓶颈，保证热点访问下在线统计模块的可扩展性；
3）实现一个高效准确的历史在线统计，保证大数据量下统计的高性能和准确性；
4）灵活把控流量，进一步提高隔离和容灾能力，保证热点访问下系统的可用性。

十、优先级消息列表

丢信令的本质缘由：recvsvr只保留最近2000条消息，大直播间里，有些消息客户端还没来的及收就被cache淘汰了。

在聊天室1.0版本，咱们已经证明了写扩散不可行，所以这里也不可能经过写扩散解决。

另一个比较直观的方案：是将重要的系统信令写到另一个列表里面，recvsvr同时读取两个消息表。带来的消耗是recvsvr对kv层增长将近一倍的访问量。因而，咱们思考有没有更优的方案。

回到1.0版本的一个方案细节：咱们能够看到大部分状况下，当新消息到来的时候，recvsvr它都是能及时感知到的，所以recvsvr一次拉取到的消息条数并不会不少，所以这一步骤上不会丢消息。

因此咱们是能够把消息表这个操做收归到recvsvr里面的：

① 打优先级标记：依然只写一张消息表，给重要的信令打上优先级标记。（目的：节省RPC消耗）

② cache内分表：recvsvr拉到消息后分开普通消息列表和重要消息列表；（目的：最小化改动）

③ 优先收取：收取时分normal seq和important seq，先收重要消息表，再收取普通消息表。（目的：优先下发）

经过一个简单的优化，咱们以最小的改造代价，提供到了一条可靠的重要消息信道，作到了连麦和大礼物动画的零丢失。微信小程序

十一、分布式在线统计

11.1 写共享内存，主从互备

参考微信设备在线模块，咱们能够有这个一个方案：

① 分sect，一个直播间选一个sect；
② 按roomid选一台机做为master，读写该机器的共享内存；
③ master把这个roomid的数据同步到sect内其它机器，master挂了的状况能够选其它机器进行读写。

上述方案的优缺点：

1）优势：解决了换机跳变问题。
2）缺点：主备同步方案复杂；读写master，大直播间下依然有单机热点问题。

结论：用分布式存储做为数据的中心节点。

11.2 写tablekv

如上图所示：

① 用tablekv的一个表来存在线列表，每行记录用户id和活跃时间；
② 按期更新用户的心跳时间，维护在线。

上述方案的优缺点：

优势：解决了换机跳变问题，数据作到了分布式；
缺点：1500w在线10s心跳一次 => 9000w/min，穿透写单表有并发和性能问题；离线不会实时从磁盘删数据，历史活跃人数远大于当前在线，形成数据冗余。

逐点击破，单key是能够经过拆key来解决的，数据冗余能够经过key-val存储作全量替换解决，而穿透问题其实能够参考recvsvr的实现方式。

所以，咱们获得一个比较好的方案：拆key + 读写分离 + 异步聚合落盘。

① 分布统计 :

(1) 每台机负责部分在线统计；
(2) 每台机内按uin哈希再分多shard打散数据；
(3) 每一个shard对应kv的一个key；

② 组合数据：让每台机都拉取全部key的数据，组合出一个完整的在线列表：

③ 异步聚合更新：心跳只更新内存，异步任务清理离线用户，并把列表序列化到一个key的val。

④ 异步拉取：由异步任务来执行②的拉取和组合数据。

⑤ 原子切换：完整的在线列表作双指针，利用原子操做无锁切换，作到无锁查询。

由此，咱们提升了心跳更新和在线查询的性能，作到了在线统计模块的分布式部署和可平行扩展。

十二、基于hyperloglog的历史在线统计

12.1 需求

历史在线统计，是要曾经看过该直播的用户数uv，在产品上的体验就是视频号直播的“xxx人看过”。

在分布式在线统计的章节，咱们已经谈到了，用tablekv来记录成员列表是不太可行的。

另一个想法：是利用bloomfilter作数据压缩和去重统计，额外去维护一个count作累加。

那么这里有两点：

一是bloomfilter和count之间要考虑一致性问题；
二是bloomfilter准确率跟压缩率相关，较好的准确率仍是须要比较大的数据量。

因而咱们调研了业界的一些uv统计方案，最终找到了redis的hyperloglog，它以极小的空间复杂度就能作到64位整形级别的基数估算。

12.2 hyperloglog是什么？

hyperLogLog 是一种几率数据结构，它使用几率算法来统计集合的近似基数，算法的最本源则是伯努利过程。

伯努利过程：设一个硬币反面为0，正面为1，抛一枚硬币直到结果为1为止。

若是作n次伯努利实验，记录每次伯努利过程须要抛硬币的次数为Ki，则能够估算：n=2^Kmax。

hyperloglog对Kmax的计算进行了分桶和调和平均值优化，使得在准确率比裸的伯努利估算要高。

优化的主要内容：

① 将要统计的数据hash成一个64位整形；
② 用低14位来寻找桶的位置；
③ 剩下的高位里寻找第一个1出现的位置，做为上述伯努利过程的Ki；
④ 对桶的值进行更新 Rj = max(Rj, Ki);
⑤ 估算时，对各个桶的值算调和平均值DV来替代上述的Kmax。

从上述算法的描述来看：hyperloglog无非就是存了m个桶的数值(m=10000+)，原本空间复杂度也不高了。再经过一些位压缩，hyperloglog把整个数据结构优化到了最大空间复杂度为12K。

12.3 tablekv+hyperloglog左右开弓

因为hyperloglog产生的毕竟是近似值，基数较少的时候偏差会更明显，因此咱们能够用tablekv来补全历史在线数较小时的体验。

① 历史在线数较小时，双写tablekv + hyperloglog，以tablekv selectcount为准；
② 历史在线数较大时，只写hyperloglog，以hyperloglog估算值为准；
③ 在线统计模块按期把在线列表merge到hyperloglog避免丢数据。

最终咱们达到的效果是：历史在线不超过1w时彻底准确，超过1w时准确率大于95%。

1三、流量隔离vipsect

你们都知道：大直播间会带来爆发式的请求量，咱们不能让大直播间引发的失败影响占大多数的小直播间。

另外：大直播间影响力大，也要去保证它的良好体验，那须要用比小直播间更多的机器去支撑。

并且：聊天室对kv层的请求数，跟机器数成正比，小直播间在多机器下会形成大量没必要要的消耗。

对于这种状况：咱们参考了微信支付应对大商户和小商户的方法，流量隔离，在聊天室的里设立vip sect。

如上图所示：

① 对可预测的大直播提早加白，直接走vip sect；
② 其它直播直走普通sect；
③ 大小直播策略分级，大直播在线列表才拆key。

虽然还有些依赖运营，可是经过这种方式，咱们切走大部分的大直播流量，也下降了整个系统对kv层的压力。

那么：为何不作自动切vip sect ?

这是一个future work，目前有了一些初步方案，还须要去验证切换过程带来影响，进一步细化策略，也欢迎你们提出宝贵建议。

1四、自动柔性下的流量把控

在longpolling（长轮询）的机制下（见本文第6节），直播间一直有消息的话，100w的在线每分钟至少会产生6kw/min的请求，而1500w更是高达9亿/min。logicsvr是cpu密集型的服务，按30w/min的性能来算，至少须要3000台。

因此这个地方必需要有一些柔性措施把控请求量，寻找一个体验和成本的平衡点。

而这个措施必定不能经过logicsvr拒绝请求来实现，缘由是longpolling机制下，客户端接收到回包之后是会立刻发起一次新请求的。logicsvr拒绝越快，请求量就会越大，越容易形成滚雪球。

图片回到longpolling机制，咱们能够发现，正常运行下，recvsvr没有新消息时，是可让请求挂在proxy层hold住，等待链接超时或者longpolling notify的。

因此，咱们能够利用这个特性，柔性让请求或者回包在proxy hold一段时间，来下降请求频率。

如上图所示：

① 根据不一样的在线数设定收取间隔；
② 客户端上下文里增长字段，记录上一次成功收取的时间；
③ 成功收取后的一个时间间隔内，请求hold在proxy层；
④ 根据不一样的在线数丢弃longpolling notify。

根据400w在线的压测效果：开启自适应大招时触发8～10s档位，请求量比没有大招的预期值下降58%，有效地控制了大直播间对logicsvr的压力。

1五、成果展现

1）支撑多个业务稳定运行：

2）压测1500w同时在线：

1六、参考文献

[1] https://zhuanlan.zhihu.com/p/77289303
[2] https://www.jianshu.com/p/4748af30d194

1七、小结与展望

咱们经过抽象问题、精准分析、合理设计完成了liveroom2.0的迭代，从性能、可靠性、可扩展性、容灾等方面达到支撑单房间1500w同时在线甚至更高在线的标准。

在将来咱们将继续优化，好比实现大房间自动从普通sect切换到vip sect，好比针对房间内我的的重要消息通道，使聊天室的功能和架构更增强大。

附录：微信、QQ团队分享的其它技术资料

《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《微信团队分享：微信移动端的全文检索多音字问题解决方案》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队分享：iOS版微信是如何防止特殊字符致使的炸群、APP崩溃的？》
《微信团队原创分享：iOS版微信的内存监控系统技术实践》
《iOS后台唤醒实战：微信收款到帐语音提醒技术总结》
《微信团队分享：视频图像的超分辨率技术原理和应用场景》
《微信团队分享：微信每日亿次实时音视频聊天背后的技术解密》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《微信手机端的本地数据全文检索优化之路》
《企业微信客户端中组织架构数据的同步更新方案优化实战》
《微信团队披露：微信界面卡死超级bug“15。。。。”的前因后果》
《QQ 18年：解密8亿月活的QQ后台服务接口隔离技术》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《一篇文章get微信开源移动端数据库组件WCDB的一切！》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信后台团队：微信后台异步消息队列的优化升级实践分享》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《微信Mars：微信内部正在使用的网络层封装库，即将开源》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万链接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通讯安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万链接背后的后台解决方案》
《微信朋友圈海量技术之道PPT [附件下载]》
《微信对网络影响的技术试验及分析（论文全文）》
《一份微信后台技术架构的总结性笔记》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《全面总结iOS版微信升级iOS9遇到的各类“坑”》
《微信团队原创资源混淆工具：让你的APK立减1M》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《Android版微信安装包“减肥”实战记录》
《iOS版微信安装包“减肥”实战记录》
《移动端IM实践：iOS版微信界面卡顿监测方案》
《微信“红包照片”背后的技术难题》
《移动端IM实践：iOS版微信小视频功能技术方案实录》
《移动端IM实践：Android版微信如何大幅提高交互性能（一）》
《移动端IM实践：Android版微信如何大幅提高交互性能（二）》
《移动端IM实践：实现Android版微信的智能心跳机制》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《移动端IM实践：iOS版微信的多设备字体适配方案探讨》
《IPv6技术详解：基本概念、应用现状、技术实践（上篇）》
《IPv6技术详解：基本概念、应用现状、技术实践（下篇）》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
《腾讯技术分享：微信小程序音视频技术背后的故事》
《微信多媒体团队梁俊斌访谈：聊一聊我所了解的音视频技术》
《腾讯技术分享：微信小程序音视频与WebRTC互通的技术思路和实践》
《手把手教你读取Android版微信和手Q的聊天记录(仅做技术研究学习)》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《微信团队分享：Kotlin渐被承认，Android版微信的技术尝鲜之旅》
《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》
《微信团队分享：极致优化，iOS版微信编译速度3倍提高的实践总结》
《IM“扫一扫”功能很好作？看看微信“扫一扫识物”的完整技术实现》
《微信团队分享：微信支付代码重构带来的移动端软件架构上的思考》
《IM开发宝典：史上最全，微信各类功能参数和逻辑规则资料汇总》
《微信团队分享：微信直播聊天室单房间1500万在线的消息架构演进之路》
>> 更多同类文章 ……

本文已同步发布于“即时通信技术圈”公众号。

▲ 本文在公众号上的连接是：点此进入。同步发布连接是：http://www.52im.net/thread-3376-1-1.html