作者 | 百度消息中台团队

导读

消息中台为百度 App 以及厂内百度系产品提供即时通讯的能力，提供包括私聊、群聊、聊天室、直播弹幕等用户沟通场景，并帮助业务通过消息推送触达用户。百度 App 存在需要以『低用户打扰』的形式触达全量用户的场景，而现有基于用户『私有信箱』通知拆分的机制，很难低成本、高时效的满足该场景诉求。基于上述问题，本文介绍了现有消息系统的主要组成，对比多种实现方案的差异，提出以『公有信箱』通知读扩散的方式，低成本、高时效的实现全量用户通知推送。

全文 5515 字，预计阅读时间 14 分钟。

01 全量消息提出背景

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

1.1 全量消息诉求

在以消息服务进行全量触达（即全量消息）时，期望能够满足：

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

1.2 现有技术痛点

我们现有 IM（即时通讯）服务中，每个 IM 用户对应一个用户信箱。基于现有服务，如果想完成全量用户的消息触达，需要把消息推送到每个用户的信箱。完成 6 亿+的消息写入（假定每条占用存储 4KB，每秒写入 2W 条消息），在消息写入时效性，以及存储资源消耗上，都是很难接受的。且现有的基于用户私有信箱的方案，在同时支持多条全量消息的场景下，扩展性也较差。

基于上述背景和技术痛点，我们抽象基于公共信箱的全量消息实现：在特定业务场景下通过消息服务，低成本、高时效的给全量用户推送内容一致的通知消息。

02 现有消息系统介绍

在介绍基于公共信箱（信箱的实现方式，该信箱为 IM 用户公有）的全量消息实现之前，先介绍一下目前消息系统的现状，包括消息系统的组成、通知拉取模式、用户信箱等。

2.1 消息系统组成

从普通用户的直观体验上看，一个 IM 系统可以包括如下几个元素：用户主体、用户账号、账号关系、聊天会话、聊天消息。『用户主体』具有『用户账号』，『用户主体』具有头像、昵称等用户属性，『用户主体』通过『用户账号』登录 IM 系统，进行聊天；账号之间的关注、屏蔽、免打扰等构成『用户关系』；通过用户之间的互动环节可以产生『聊天消息』；聊天记录构成了一个『聊天会话』。

从集成消息服务的业务方角度看，一个 IM 系统可以包括消息客户端（消息客户端 UI 组件、消息 SDK）和消息服务端。IM 消息可以作为一种服务，嵌入到各业务系统中，为业务系统提供『实时交互』能力。业务通过集成 IM 服务，提升其用户体验。如下为一个集成了 IM SDK 的业务架构图。业务 App 集成 IM SDK，通过 IM SDK 与 IM Server 交互，完成用户上行通讯能力。业务 App Server 通过与 IM Server 交互，完成通知下行触达用户。

从使用场景来看，消息包括『私信消息』（包括用户上下行消息）、『通知消息』（业务方给用户推送的下行消息）、『群聊』、『聊天室』、『直播间弹幕』等。

2.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）**消息。

2.3 用户信箱介绍

为了暂存尚未拉取到 IM SDK 本地的离线消息，需要对消息进行服务端存储，而消息的离线存储通过消息信箱服务完成。目前 IM 用户消息信箱主要包括用户私有信箱、群公共信箱（非下文提到的用户公共信箱）、直播间弹幕 mcast 等。用户信箱通过『消息所属应用』+『IM 标识用户的唯一 ID』来标识。就一条消息而言，消息参与者有『消息发送者』和『消息接收者』，消息收发双方的信箱都是相互独立的（假设发送方删除了自己信箱的某一条消息，不会影响消息接受者信箱的消息）。对于有查看历史消息诉求的一方来说，消息需要入该方的信箱：比如用户之间的私信（点对点聊天）消息需要入发送者和接收者的信箱，而对于全量通知场景，消息不需要存储发送者信箱，而只需要存接收者的信箱。而用户的信箱排序，是基于信箱 Timeline，即消息在信箱内部基于时间线存储，每条消息对应一个 unix 微秒时间戳（如第一条消息 1679757323320865），用户进行信箱拉取时，基于时间范围正序或者逆序拉取，如下为信箱 timeline 的示例：

△信箱 timeline

用户信箱中的每一条消息记录都包含『消息 ID』、『消息用户标识』、『消息通用属性』、『消息业务属性』四个主要部分。消息 ID 为 unix 微秒时间戳，不需要全局唯一，只需要特定用户信箱范围内唯一即可。消息用户标识包括 from_uid、to_uid、contacter。消息通用属性包括 create_time、expire、is_read。消息业务属性包括 category、type、priority、business_type、app_id、msgkey、content 等。如下为一条消息记录示例：

△消息记录示例

03 全消息实现

3.1 全量消息推送方案分析

目前消息推送机制中，主要支持：单播（消息推送方式，每次给一个用户推送一条消息）、批量单播（每次给小范围用户推送消息，比如 30 个）、广播（基于关注关系的推送，如给全量粉丝推送），上述三种消息推送机制推送的消息，均需要存储服务端的用户私有信箱。为了完成百度 App 6 亿+月活用户（月活数据来源：2022 年 12 月百度 App 公开月活数据， https://baijiahao.baidu.com/s?id=1758522783976467912&wfr=spider&for=pc ）的消息推送，有几种可选的方案。

3.1.1 全流程从通知入口推送

①该种方式下，需要获取全量的月活用户列表，经过 IM Server 推送入口，给每一个用户推送疫情相关通知。该通知写入到用户信箱，若用户在线，在实时拉取该通知；若用户离线，再下次登录 IM 服务时，拉取离线通知。该种方案下，推送行为会覆盖 IM 的全流程，推送的通知会进入每个月活用户的私有信箱，服务压力大。其中增量用户不会收到通知推送（这里增量用户指的是不在月活用户列表的用户）。

3.1.2 跳过通知入口直接写信箱

②跳过 IM 消息推送流程中的中间环节，直接把通知消息写入用户信箱。由于跳过了中间流程，直接写入信箱，通知写入速度主要取决于信箱底层存储的压力承受情况。该种方案下，同①方案一样，无法给用户发送实时通知，依赖用户 IM SDK 的主动消息拉取（断链后重新登录/新消息提醒拉取），无法给增量用户发送通知。该方案由于跳过中间环节直接写信箱，风险较大，无法直接提供给业务方使用，不建议如此操作。

3.1.3 公有信箱实现机制

③公有信箱机制，把通知消息写入『公共信箱』，在用户消息拉取时，合并『用户私信信箱』+『公共信箱』的消息。

3.1.4 三种方案比较

方案①②都是写扩散方式，基于现有『用户私有信箱』的机制，把通知消息写入每个接收通知的用户私有信箱。方案②与方案①的差别主要是跳过了消息中间流程，可以避免因为中间环节负载瓶颈导致整体消息写入速度过低。方案③是读扩散方式，消息不用再写入接收通知的用户私有信箱，而只需要在公共信箱存储一份，在用户拉取消息时，实时拉取公共信箱的消息。方案③中可以采用内存缓存方案，解决对公共信箱的读压力。本质上来说，方案③与方案①②相比，是用读成本（CPU）换写成本（存储）。

3.2 基于公有信箱的全量消息实现

基于上述方案③的思路，我们进行基于公有信箱的全量消息设计与实现。该种方案中，包含两个主要流程：『全量消息的管理』和『用户私有+公有信箱的拉取』。

3.2.1 全量消息的管理

全量消息管理主要分为运营 O 端操作平台（复用运营消息平台），以及全量消息处理服务（复用 IM 服务的连接层、逻辑处理层、信箱代理、信箱处理）。运营 O 端平台为运营同学提供可视化界面，可以对全量消息进行编辑、预发布、发布、修改、停止、撤回等操作；接入层对接运营 O 端，进行参数校验、转发 IM 后端逻辑处理模块；逻辑处理层进行全量消息的创建、修改、停止、删除、撤回等逻辑操作；信箱代理层复用 IM 服务的信箱 CRUD 操作；信箱存储层公共信箱的底层存储。

△全量消息管理流程

3.2.1 用户信箱拉取

用户通过 IM SDK，以长连接的方式，在逻辑处理层进行消息拉拉取。在用户拉取信箱消息时，需要对『用户个人信箱』和『公有信箱』进行合并。由于每次用户信箱拉取，都需要进行信箱的合并拉取。

公共信箱内存缓存机制

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

分级发布机制

同时，在逻辑层实现白名单机制，支持全量消息在『预发布』状态下，仅对白名单用户可见，从而达到分级验证的效果。白名单的用户列表通过逻辑处理成的配置加载，也支持通过 CURL 请求动态修改白名单的配置。

3.3 基于公有信箱的全量消息实现需要解决的问题

以公有信箱的方案实现全量消息，需要解决如下问题：

04 全量消息公共信箱实现的优缺点

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

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

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

2、不适用于实时消息提醒场景：

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

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

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

05 全量消息的应用

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

22 年 Q4 宣布疫情解封时，利用全量消息推送，低成本、高时效的完成 3 条『疫情解封专项』全量消息下发。

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

①本次全量消息有效期仅 3 天左右，全量消息有效期内登录 IM SDK 的用户才有机会拉到全量消息；

②本次下发使用了新的消息展示模板，所以限制了拉取全量消息的百度 App 版本，只有高版本百度 App 可以拉到；

③本次全量消息，限制了仅有百度 App 登录用户拉取。

06 展望

前文介绍了现有消息系统，通过公有信箱低成本、高分发速度完成全量消息下发的设计、实现与应用。在全量消息应用方面，除了业务上的使用，后续也可以用于广播消息、批量单播消息的撤回。比如由于误操作发送了广播消息，用户已经把广播消息拉到了端，并持久化到端，这是可以『以全量消息的方式，下发删除指令』，删除已经缓存到端的垃圾消息。

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

——END——

推荐阅读：

百度APP iOS端包体积50M优化实践(二) 图片优化

浅论分布式训练中的recompute机制

剖析多利熊业务如何基于分布式架构实践稳定性建设

百度工程师的软件质量与测试随笔

百度APP iOS端包体积50M优化实践(一)总览

基于FFmpeg和Wasm的Web端视频截帧方案