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

Posted on 2023-05-26 10:57 Jack Jiang 阅读(170) 评论(0) 编辑收藏

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

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