共计 5442 个字符，预计需要花费 14 分钟才能阅读完成。
作者 | 百度音讯中台团队
导读
音讯中台为百度 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=spid…）的音讯推送，有几种可选的计划。
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 机制
分析多利熊业务如何基于分布式架构实际稳定性建设
百度工程师的软件品质与测试随笔[](http://mp.weixin.qq.com/s?__biz=Mzg5MjU0NTI5OQ==&mid=22475598…)
百度 APP iOS 端包体积 50M 优化实际 (一) 总览
基于 FFmpeg 和 Wasm 的 Web 端视频截帧计划
