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

1、引言

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

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

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

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