揭秘百度 IM 消息中台的全量用户消息推送技术改造实践
本文内容由百度技术团队分享,原题“基于公共信箱的全量消息实现”,为了帮助理解,有较多修订、内容重组和重新排版。
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 请求动态修改白名单的配置。
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、相关资料
[2] 百度APP移动端网络深度优化实践分享(一):DNS优化篇
[3] 百度APP移动端网络深度优化实践分享(二):网络连接优化篇
[4] 百度APP移动端网络深度优化实践分享(三):移动端弱网优化篇
[6] 深入了解百度开源的分布式RPC框架brpc的方方面面
[9] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)
[11] 一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等
[12] 基于实践:一套百万消息量小规模IM系统技术要点总结
[13] 一套十万级TPS的IM综合消息系统的架构实践与思考
[14] 从新手到专家:如何设计一套亿级消息量的分布式IM系统
[15] 闲鱼亿级IM消息系统的架构演进之路
[17] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践
[18] 企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等
技术交流:
- 移动端 IM 开发入门文章:《新手入门一篇就够:从零开发移动端IM》
- 开源 IM 框架源码:https://github.com/JackJiang2011/MobileIMSDK(备用地址点此)
(本文已同步发布于:http://www.52im.net/thread-4235-1-1.html)
评论