揭秘百度IM消息中台的全量用户消息推送技术改造实践

本文内容由百度技术团队分享，原题“基于公共信箱的全量消息实现”，为了帮助理解，有较多修订、内容重组和重新排版。

1、引言

百度的IM消息中台为百度APP以及厂内百度系产品提供即时通讯的能力，提供包括私聊、群聊、聊天室、直播弹幕等用户沟通场景，并帮助业务通过消息推送触达用户。

如今，百度APP新增了一种需要以“低用户打扰”的形式触达全量用户的场景需求，而现有的IM消息中台主要是基于用户“私有信箱”通知拆分的机制（通俗了说也就是IM里的“扩散写”），所以如果不进行改造，是很难低成本、高时效的满足该场景诉求。

基于上述问题，本文介绍了百度现有IM消息中台系统的主要组成，并对比多种实现方案的优劣，以“公有信箱”通知读扩散的技术方案对现有IM消息中台系统进行改造，从而达成了低成本、高时效地实现全量用户通知推送需求。

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》 - 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4235-1-1.html）

2、全量用户消息推送需求背景

百度APP新增了需要通过IM实时通知触达全量用户的诉求，比如2022年12月7日解除疫情管控结束后，将经过筛选的官方政策解读、专题汇总、知识科普、实用工具类介绍等信息，通过官方号“x度小助手”下发触达到百度APP用户，从而来有效体现人文关怀，提高用户粘性。

在以IM消息服务进行全量用户消息触达时，需要满足以下诉求：

具体就是：

• 1）在触达范围上：希望尽量扩大用户触达范围，包括百度APP月活用户、以及非月活用户但是近期新注册或登录的用户；
• 2）在时效上：一次全量触达，希望短时间内完成（比如小时级、甚至分钟级），抢占时效性；
• 3）在用户打扰方面：消息触达不能给用户带来较大的打扰，每次消息下发，只触达一次，不能重复打扰用户（但是需要保留回访入口，满足用户二次查看的诉求）。

3、现有IM消息中台的技术痛点

我们现有的IM（即时通讯）服务中，每个IM用户对应一个用户信箱。

基于现有的IM技术实现方案，如果想完成全量用户的消息触达，需要把消息推送到每个用户的信箱（也就是IM中的扩散写）。

这样的话，要完成6亿以上的消息写入（假定每条占用存储4KB，每秒写入2W条消息），在消息写入时效性以及存储资源消耗上，都是很难接受的。

且现有的基于用户私有信箱的方案，在同时支持多条全量用户通知消息的场景下，扩展性也较差。

基于上述需求背景和技术痛点，我们本次的改造目的，就是要找到一种技术方案，从而在特定业务场景下通过改造后的消息服务，低成本、高时效的给全量用户推送内容一致的消息通知。

4、现有IM消息中台的主要技术实现

在讨论改造方案前，我们有必要介绍一下目前IM消息系统的现状，包括消息系统的组成、通知拉取模式、用户信箱等。

4.1 消息系统组成

从普通用户的直观体验上看，一个IM系统可以包括如下元素：

• 1）用户主体；
• 2）用户账号；
• 3）账号关系；
• 4）聊天会话；
• 5）聊天消息。

用自然语言串一下以上元素就是：

• 1）“用户主体”具有“用户账号”；
• 2）“用户主体”具有头像、昵称等用户属性；
• 3）“用户主体”通过“用户账号”登录IM系统，进行聊天；
• 4）“用户账号”之间的关注、屏蔽、免打扰等构成“用户关系”；
• 5）通过用户之间的互动环节可以产生“聊天消息”；
• 6）聊天记录构成了一个“聊天会话”。

下面这张图可能更直观一些：

从集成消息服务的业务方角度看：

• 1）一个IM系统可以包括消息客户端（消息客户端UI组件、消息SDK）和消息服务端；
• 2）IM消息可以作为一种服务，嵌入到各业务系统中，为业务系统提供“实时交互”能力；
• 3）业务通过集成IM服务，提升其用户体验；
• 4）业务APP集成IM SDK，通过IM SDK与IM Server交互，完成用户上行通讯能力；
• 5）业务APP Server通过与IM Server交互，完成通知下行触达用户。

下图为一个集成了IM SDK的业务架构图：

从使用场景来看，消息包括：

• 1）“私信消息”（包括用户上下行消息）；
• 2）“通知消息”（业务方给用户推送的下行消息）；
• 3）“群聊”、“聊天室”；
• 4）“直播间弹幕”等。

4.2 消息的通知拉取模式

百度的IM消息系统，采用通知拉取（notify-pull）模式来感知新消息、拉取新消息。

IM SDK登录时，与IM 服务端建立长连接（LCS, Long Connect Service），用户有新的消息时，通过长连接下发notify，实时通知用户的IM SDK。

实时notify不写用户信箱，因为noitfy不是消息（可以理解为提醒在线用户有新消息的信号），IM SDK根据这个信号，来服务端拉取消息。

业务方server或者其他用户给该用户发送消息后，经过IM业务处理模块，把消息写入接收者信箱，IM Server会根据用户的登录和路由信息，给消息接收者（私信场景下也包括“消息发送者”，用于消息的多端同步）发送新消息notify，接收到notify的IM设备，通过IM SDK来IM Server端拉取（pull）消息。

4.3 用户信箱介绍

为了暂存尚未拉取到IM SDK本地的离线消息，需要对消息进行服务端存储，而消息的离线存储是通过消息信箱服务完成的。

目前百度的IM用户消息信箱主要包括：

• 1）用户私有信箱；
• 2）群公共信箱（非下文提到的用户公共信箱）；
• 3）直播间弹幕mcast等。

用户信箱通过“消息所属应用”+“IM标识用户的唯一ID”来标识。

就一条消息而言：消息参与者有“消息发送者”和“消息接收者”，消息收发双方的信箱都是相互独立的（假设发送方删除了自己信箱的某一条消息，不会影响消息接受者信箱的消息）。

对于有查看历史消息诉求的一方来说：消息需要入该方的信箱，比如用户之间的私信（也就是一对一单聊）消息需要入发送者和接收者的信箱。

而对于全量用户消息通知的场景：消息不需要存储发送者信箱，而只需要存接收者的信箱。而用户的信箱排序，是基于信箱Timeline（详见《现代IM系统中聊天消息的同步和存储方案探讨》）。即消息在信箱内部基于时间线存储，每条消息对应一个unix 微秒时间戳（如第一条消息1679757323320865），用户进行信箱拉取时，基于时间范围正序或者逆序拉取。

如下为信箱Timeline的示例：

用户信箱中的每一条消息记录都包含四个主要部分：

• 1）“消息ID”；
• 2）“消息用户标识”；
• 3）“消息通用属性”；
• 4）“消息业务属性”。

下面详细介绍以上四个部分：

• 1）消息ID：为unix微秒时间戳，不需要全局唯一，只需要特定用户信箱范围内唯一即可；
• 2）消息用户标识：包括from_uid、to_uid、contacter；
• 3）消息通用属性：包括create_time、expire、is_read；
• 4）消息业务属性：包括category、type、priority、business_type、APP_id、msgkey、content等。

如下为一条消息记录示例：

5、全量用户消息推送技术方案选型

5.1 需求分析

目前百度的IM消息推送机制中，主要支持：

• 1）单播：消息推送方式，每次给一个用户推送一条消息;
• 2）批量单播：每次给小范围用户推送消息，比如30个;
• 3）广播：基于关注关系的推送，如给全量粉丝推送。

上述三种消息推送机制推送的消息，均需要存储服务端的用户私有信箱。为了完成百度APP 6亿以上全量月活用户的消息推送，目前有三种可选的方案，接下来我们逐一分析。

5.2 方案1：全流程从通知入口推送

该种方式下：需要获取全量的月活用户列表，经过IM Server推送入口，给每一个用户推送疫情相关通知。

该通知写入到用户信箱时：

• 1）若用户在线，在实时拉取该通知；
• 2）若用户离线，再下次登录IM服务时，拉取离线通知。

该种方案下：推送行为会覆盖IM的全流程，推送的通知会进入每个月活用户的私有信箱，服务压力大。其中增量用户不会收到通知推送（这里增量用户指的是不在月活用户列表的用户）。

5.3 方案2：跳过通知入口直接写信箱

该种方式跳过IM消息推送流程中的中间环节，直接把通知消息写入用户信箱。

由于跳过了中间流程直接写入信箱，通知写入速度主要取决于信箱底层存储的压力承受情况。

该种方案下，同方案1一样，无法给用户发送实时通知，依赖用户IM SDK的主动消息拉取（断链后重新登录/新消息提醒拉取），无法给增量用户发送通知。

该方案由于跳过中间环节直接写信箱，风险较大，无法直接提供给业务方使用，不建议如此操作。

5.4 方案3：公有信箱实现机制

该种公有信箱机制的逻辑是把通知消息写入“公共信箱”。在用户消息拉取时，合并“用户私信信箱”+“公共信箱”的消息。

5.5 三种方案比较

方案1和2都是写扩散方式，基于现有“用户私有信箱”的机制，把通知消息写入每个接收通知的用户私有信箱。

方案2与方案1的差别主要是跳过了消息中间流程，可以避免因为中间环节负载瓶颈导致整体消息写入速度过低。

方案3是读扩散方式，消息不用再写入接收通知的用户私有信箱，而只需要在公共信箱存储一份。在用户拉取消息时，实时拉取公共信箱的消息。方案③中可以采用内存缓存方案，解决对公共信箱的读压力。

本质上来说：方案3与方案前两种相比，是用读成本（CPU）换写成本（存储）。

6、基于公有信箱技术方案的全量用户消息推送实现

6.1 概述

基于上述方案3的思路，我们进行基于公有信箱的全量消息设计与实现。

该种方案中包含两个主要流程：

• 1）全量消息的管理；
• 2）用户私有+公有信箱的拉取。

6.2 全量消息的管理

全量消息管理主要分为：

• 1）运营O端操作平台：复用运营消息平台；
• 2）全量消息处理服务：复用IM服务的连接层、逻辑处理层、信箱代理、信箱处理。

运营O端平台为运营同学提供可视化界面，可以对全量消息进行编辑、预发布、发布、修改、停止、撤回等操作。

具体就是：

• 1）接入层：对接运营O端，进行参数校验、转发IM后端逻辑处理模块；
• 2）逻辑处理层：进行全量消息的创建、修改、停止、删除、撤回等逻辑操作；
• 3）信箱代理层：复用IM服务的信箱CRUD操作；信箱存储层公共信箱的底层存储。

全量消息管理流程：

6.3 用户信箱拉取

用户通过IM SDK，以长连接的方式，在逻辑处理层进行消息拉拉取。

在用户拉取信箱消息时，需要对“用户个人信箱”和“公有信箱”进行合并。于是每次用户信箱拉取，都需要进行信箱的合并拉取。

6.3.1）公共信箱内存缓存机制：

百度APP的IM用户，在IM SDK登录时需要拉取信箱中的消息。每次消息拉取时，需要检查公共信箱中是否有消息。

因此，公共信箱需要能抗住日常和峰值流量（拉取峰值为4.7Wqps）。为了防止流量击穿，流量打到底层的持久化公共信箱MYSQL存储，我们设计了基于内存的公共信箱缓存机制。同时公共信箱内容变化时，也要实时（或者在能容忍的范围内做到准实时）变更内存缓存信箱中的消息，我们采用Bthread定期轮询持久化公共信箱，更新内存公共信箱，轮询间隔可配置（比如设置1秒）。

6.3.2）分级发布机制：

同时，在逻辑层实现白名单机制，支持全量消息在“预发布”状态下，仅对白名单用户可见，从而达到分级验证的效果。

白名单的用户列表通过逻辑处理成的配置加载，也支持通过CURL请求动态修改白名单的配置。

7、基于公有信箱技术方案的技术挑战

公有信箱的技术方案，需要解决如下问题：

8、基于公有信箱技术方案的优缺点总结

8.1 优点

以公共信箱的方式，实现全量用户消息分发，具有：“分发速度快”、“资源成本低”的特点。

8.2 缺点

但公共信箱的方式也存在一定的局限性。

8.2.1）不适用于个性化要求高的场景：

由于消息在公共信箱只存储一份，下发消息内容固定，无法很大程度下，下发个性化消息（当然也不是一定无法下发个性化的消息，可以通过在公共信箱存储消息模板，根据拉取消息的用户ID获取个性化信息，在消息拉取时，临时拼装消息，这样就增大了消息拉取时的代价）。

8.2.2）不适用于实时消息提醒场景：

1）从业务场景上看：全量消息优先级低，不需要在全量生效的瞬间让用户感知。

2）从实现上看：全量消息实时消息提醒成本高。因为实时消息提醒Notify，需要以类似单播的形式实时通知用户。和单播的区别是，Notify不用触达离线用户，也就是不用写用户信箱，只需实时触达在线用户。

3）从系统压力看：全量在线用户均收到实时新消息提醒，会带来信箱拉取请求的瞬时流量（手机百度IM SDK长连接峰值在线1550W，假定新消息提醒在瞬间下发，同时在线用户信箱拉取请求，会把db打挂的）。

9、基于公有信箱技术方案的落地实施效果

全量消息目前已经在百度APP得到应用，包括：重大通知的下发；百度APP功能更新介绍通知；消息的撤回，后续还将推广到其他的矩阵APP的全量通知推送场景。

举个具体的例子：22年Q4宣布疫情解封时，利用全量消息推送，低成本、高时效的完成3条“疫情解封专项”全量消息下发。

在这个例子中，三次全量消息下发，到达数据在2亿+（该值小于月活的6亿+），主要因为几个原因：

• 1）本次全量消息有效期仅3天左右，全量消息有效期内登录IM SDK的用户才有机会拉到全量消息；
• 2）本次下发使用了新的消息展示模板，所以限制了拉取全量消息的百度APP版本，只有高版本百度APP可以拉到；
• 3）本次全量消息，限制了仅有百度APP登录用户拉取。

10、未来展望

本文介绍了现有IM消息中台系统，并通过公有信箱技术方案的改造，达成了低成本、高分发速度完成全量用户消息下发的设计、实现与应用。

在全量用户消息应用方面，除了业务上的使用，后续也可以用于广播消息、批量单播消息的撤回。比如由于误操作发送了广播消息，用户已经把广播消息拉到了端，并持久化到端，这是可以“以全量消息的方式，下发删除指令”，删除已经缓存到端的垃圾消息。

我们希望，通过消息系统持续不断优化，为更多的业务提供低成本、高稳定性的即时通讯能力。

11、相关资料

[1] 现代IM系统中聊天消息的同步和存储方案探讨

[2] 百度APP移动端网络深度优化实践分享(一)：DNS优化篇

[3] 百度APP移动端网络深度优化实践分享(二)：网络连接优化篇

[4] 百度APP移动端网络深度优化实践分享(三)：移动端弱网优化篇

[5] 百度直播的海量用户实时消息系统架构演进实践

[6] 深入了解百度开源的分布式RPC框架brpc的方方面面

[7] 百度网盘千万节点的P2P架构设计(PPT)

[8] 零基础IM开发入门(一)：什么是IM系统？

[9] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[10] 一套原创分布式即时通讯(IM)系统理论架构方案

[11] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等

[12] 基于实践：一套百万消息量小规模IM系统技术要点总结

[13] 一套十万级TPS的IM综合消息系统的架构实践与思考

[14] 从新手到专家：如何设计一套亿级消息量的分布式IM系统

[15] 闲鱼亿级IM消息系统的架构演进之路

[16] 深度解密钉钉即时消息服务DTIM的技术设计

[17] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[18] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等

（本文已同步发布于：http://www.52im.net/thread-4235-1-1.html）