Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 438, comments - 13, trackbacks - 0, articles - 0

本文内容由百度技术团队分享,原题“基于公共信箱的全量消息实现”,为了帮助理解,有较多修订、内容重组和重新排版。

1、引言

百度的IM消息中台为百度APP以及厂内百度系产品提供即时通讯的能力,提供包括私聊、群聊、聊天室、直播弹幕等用户沟通场景,并帮助业务通过消息推送触达用户。

如今,百度APP新增了一种需要以“低用户打扰”的形式触达全量用户的场景需求,而现有的IM消息中台主要是基于用户“私有信箱”通知拆分的机制(通俗了说也就是IM里的“扩散写”),所以如果不进行改造,是很难低成本、高时效的满足该场景诉求。

基于上述问题,本文介绍了百度现有IM消息中台系统的主要组成,并对比多种实现方案的优劣,以“公有信箱”通知读扩散的技术方案对现有IM消息中台系统进行改造,从而达成了低成本、高时效地实现全量用户通知推送需求。

技术交流:

本文已同步发布于: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



作者:Jack Jiang (点击作者姓名进入Github)
出处:http://www.52im.net/space-uid-1.html
交流:欢迎加入即时通讯开发交流群 215891622
讨论:http://www.52im.net/
Jack Jiang同时是【原创Java Swing外观工程BeautyEye】【轻量级移动端即时通讯框架MobileIMSDK】的作者,可前往下载交流。
本博文 欢迎转载,转载请注明出处(也可前往 我的52im.net 找到我)。


只有注册用户登录后才能发表评论。


网站导航:
 
Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang