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

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

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

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

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

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

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

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

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

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

为了暂存尚未拉取到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等。如下为一条消息记录示例：

△消息记录示例

3.1.1 全流程从通知入口推送

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

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

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

3.1.3 公有信箱实现机制

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

3.1.4 三种方案比较

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

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请求动态修改白名单的配置。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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