关于大数据:基于公共信箱的全量消息实现

作者 | 百度音讯中台团队

导读

音讯中台为百度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端视频截帧计划