直播聊天室单房间1500万在线的消息架构

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

1500万在线的挑战

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

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

直播聊天室1.0架构

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

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

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

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

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

longpolling（长轮询）机制

为了让用户需要实时同步到新消息，我们采用的是longpolling模式。即时通讯开发可以找蔚可云开发。

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

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

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

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

无状态cache的设计

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

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

直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路_6.png

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

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

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

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

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

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

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

通过对整个架构和逻辑进一步的分析，我们发现4个阻碍我们前进的痛点：

1）大直播间里，消息信道不保证所有消息都下发，连麦成功信令丢失会使得连麦功能不可用，大礼物打赏动画信令丢失会带来客诉；

2）一个房间的在线列表，是由recvsvr把最近有收取该房间的消息的user聚合到同一台statsvr得到的，有单点瓶颈，单机失败会导致部分房间在线数跳变、在线列表和打赏排行榜不可用等；

3）没有提供历史在线人数统计功能；

4）裸的longpolling机制在消息一直有更新的情况下，无法控制请求量。

我们得出了聊天室2.0需要解决的问题：

1）解决丢重要信令问题，保证热点访问下功能的可靠性；

2）解决在线统计的单点瓶颈，保证热点访问下在线统计模块的可扩展性；

3）实现一个高效准确的历史在线统计，保证大数据量下统计的高性能和准确性；

4）灵活把控流量，进一步提升隔离和容灾能力，保证热点访问下系统的可用性。

参考微信设备在线模块，我们可以有这个一个方案：

① 分sect，一个直播间选一个sect；

② 按roomid选一台机作为master， 读写该机器的共享内存；

③ master把这个roomid的数据同步到sect内其它机器，master挂了的情况可以选其它机器进行读写。

上述方案的优缺点：

1）优点：解决了换机跳变问题。

2）缺点：主备同步方案复杂；读写master，大直播间下依然有单机热点问题。