共计 6278 个字符，预计需要花费 16 分钟才能阅读完成。
本文内容由百度技术团队分享，原题“基于公共信箱的全量音讯实现”，为了帮忙了解，有较多订正、内容重组和从新排版。
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 申请动静批改白名单的配置。
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、相干材料
[1] 古代 IM 零碎中聊天音讯的同步和存储计划探讨
[2] 百度 APP 挪动端网络深度优化实际分享(一)：DNS 优化篇
[3] 百度 APP 挪动端网络深度优化实际分享(二)：网络连接优化篇
[4] 百度 APP 挪动端网络深度优化实际分享(三)：挪动端弱网优化篇
[5] 百度直播的海量用户实时音讯零碎架构演进实际
[6] 深刻理解百度开源的分布式 RPC 框架 brpc 的方方面面
[7] 百度网盘千万节点的 P2P 架构设计(PPT)
[8] 零根底 IM 开发入门(一)：什么是 IM 零碎？
[9] 一套海量在线用户的挪动端 IM 架构设计实际分享(含具体图文)
[10] 一套原创分布式即时通讯(IM) 零碎实践架构计划
[11] 一套亿级用户的 IM 架构技术干货(上篇)：整体架构、服务拆分等
[12] 基于实际：一套百万音讯量小规模 IM 零碎技术要点总结
[13] 一套十万级 TPS 的 IM 综合音讯零碎的架构实际与思考
[14] 从老手到专家：如何设计一套亿级音讯量的分布式 IM 零碎
[15] 闲鱼亿级 IM 音讯零碎的架构演进之路
[16] 深度解密钉钉即时消息服务 DTIM 的技术设计
[17] 一套高可用、易伸缩、高并发的 IM 群聊、单聊架构方案设计实际
[18] 企业微信的 IM 架构设计揭秘：音讯模型、万人群、已读回执、音讯撤回等
（本文已同步公布于：http://www.52im.net/thread-4235-1-1.html）
