微信直播聊天室单房间1500万在线的消息架构演进之路

1、引言

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

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

​

3、1500万在线的挑战

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

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

4、直播聊天室1.0架构

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

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

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

​

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

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

6、longpolling（长轮询）机制

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

很多人会疑惑为什么不用websocket，原因有3个：

• 1）websocket主要考虑推模式，而推模式则有可能丢，做到不丢还是有需要拉模式来兜底；

• 2）推模式下，需要精准维护每个时刻的在线列表，难度很大；

• 3） longpolling本质是一个短连，客户端实现更简单。

 

7、无状态cache的设计

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

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

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

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

③ 兜底轮询：当recvsvr机器上接