作者 | 百度音讯中台团队
导读
音讯中台为百度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的示例：
用户信箱中的每一条音讯记载都包含『音讯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揭露月活数据， baijiahao.baidu.com/s?id=175852… ）的音讯推送，有几种可选的计划。
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条『疫情解封专项』全量音讯下发。
主题 |
有效期 |
抵达 |
个人怎么做好防备 |
12.09-12.13 |
2亿+ |
阳了的应对办法 |
12.16-12.19 |
2亿+ |
新冠驳斥谣言&三年抗疫 |
12.23-12.26 |
2亿+ |
补白：三次全量音讯下发，抵达数据在2亿+，该值小于月活的6亿+，首要因为几个原因：
①本次全量音讯有效期仅3天左右，全量音讯有效期内登录IM SDK的用户才有时机拉到全量音讯；
②本次下发运用了新的音讯展现模板，所以约束了拉取全量音讯的百度App版本，只有高版本百度App能够拉到；
③本次全量音讯，约束了仅有百度App登录用户拉取。
06 展望
前文介绍了现有音讯体系，经过公有信箱低成本、高分发速度完结全量音讯下发的设计、完结与运用。在全量音讯运用方面，除了事务上的运用，后续也能够用于播送音讯、批量单播音讯的撤回。比方因为误操作发送了播送音讯，用户现已把播送音讯拉到了端，并耐久化到端，这是能够『以全量音讯的方法，下发删除指令』，删除现已缓存到端的垃圾音讯。
期望，经过音讯体系持续不断优化，为更多的事务供给低成本、高稳定性的即时通讯才能。
——END——
推荐阅览：
百度APP iOS端包体积50M优化实践(二) 图片优化
浅论分布式训练中的recompute机制
分析多利熊事务怎么依据分布式架构实践稳定性建造
百度工程师的软件质量与测验漫笔
百度APP iOS端包体积50M优化实践(一)总览
依据FFmpeg和Wasm的Web端视频截帧计划
