阿里 IM 技术分享 (四)：闲鱼亿级 IM 消息系统的可靠投递优化实践
本文由阿里闲鱼技术团队景松分享，原题“到达率 99.9%：闲鱼消息在高速上换引擎（集大成）”，有修订和改动，感谢作者的分享。
1、引言
在 2020 年年初的时候接手了闲鱼的 IM 即时消息系统，当时的消息存在各种问题，网上的用户舆情也是接连不断。
典型的问题，比如：
1）“聊天消息经常丢失”；
2）“消息用户头像乱了”；
3）“订单状态不对”（相信现在看文章的你还在吐槽闲鱼的消息）。
所以闲鱼的即时消息系统稳定性、可靠性是一个亟待解决的问题。
我们调研了集团内的一些解决方案，例如钉钉的 IMPass。如果贸然直接迁移，技术成本和风险都是比较大，包括服务端数据需要双写、新老版本兼容等。
那么基于闲鱼现有的即时消息系统架构和技术体系，如何来优化它的消息稳定性、可靠性？应该从哪里开始治理？当前系统现状到底是什么样？如何客观进行衡量？希望本文能让大家看到一个不一样的闲鱼即时消息系统。
PS：如果您对 IM 消息可靠性还没有概念，建议先阅读这篇入门文章《零基础 IM 开发入门(三)：什么是 IM 系统的可靠性？》。
学习交流：
即时通讯/推送技术开发交流 5 群：215477170 [推荐]
移动端 IM 开发入门文章：《新手入门一篇就够：从零开发移动端 IM》
开源 IM 框架源码：https://github.com/JackJiang2011/MobileIMSDK
（本文同步发布于：http://www.52im.net/thread-3706-1-1.html）
2、系列文章
本文是系列文章的第 4 篇，总目录如下：
《阿里 IM 技术分享(一)：企业级 IM 王者——钉钉在后端架构上的过人之处》
《阿里 IM 技术分享(二)：闲鱼 IM 基于 Flutter 的移动端跨端改造实践》
《阿里 IM 技术分享(三)：闲鱼亿级 IM 消息系统的架构演进之路》
《阿里 IM 技术分享(四)：闲鱼亿级 IM 消息系统的可靠投递优化实践》（* 本文）
3、行业方案
经过查阅网上分享的主流消息可靠投递技术方案，我进行了简单总结。
通常 IM 消息的投递链路大致分为三步：
1）发送者发送；
2）服务端接收然后落库；
3）服务端通知接收端。
特别是移动端的网络环境比较复杂：
1）可能你发着消息，网络突然断掉了；
2）可能消息正在发送中，网络突然好了，需要重发。
技术原理图大如下：
PS：可能很多人对移动网络的复杂性没有个系统的认知，以下文章有必要系统阅读：
《通俗易懂，理解移动网络的“弱”和“慢”》
《史上最全移动弱网络优化方法总结》
《为什么 WiFi 信号差？一文即懂！》
《为什么手机信号差？一文即懂！》
《高铁上无线上网有多难？一文即懂！》
那么，在如此复杂的网络环境下，是如何稳定可靠的进行 IM 消息投递的？
对于发送者来说，它不知道消息是否有送达，要想做到确定送达，就需要加一个响应机制。
这个机制类似于下面的响应逻辑：
1）发送者发送了一条消息“Hello”，进入等待状态；
2）接收者收到这条消息“Hello”，然后告诉发送者说我已经收到这条消息了的确认信息；
3）发送者接收到确认信息后，这个流程就算完成了，否则会重试。
上面流程看似简单，关键是中间有个服务端转发过程，问题就在于谁来回这个确认信息，以及什么时候回这个确认信息。
网上查到比较多的是如下一个消息必达模型：
各报文类型解释如下：
如上面两图所示，发送流程是：
1）A 向 IM-server 发送一个消息请求包，即 msg:R1；
2）IM-server 在成功处理后，回复 A 一个消息响应包，即 msg:A1；
3）如果此时 B 在线，则 IM-server 主动向 B 发送一个消息通知包，即 msg:N1（当然，如果 B 不在线，则消息会存储离线）。
如上面两图所示，接收流程是：
1）B 向 IM-server 发送一个 ack 请求包，即 ack:R2；
2）IM-server 在成功处理后，回复 B 一个 ack 响应包，即 ack:A2；
3）IM-server 主动向 A 发送一个 ack 通知包，即 ack:N2。
正如上述模型所示：一个可靠的消息投递机制就是靠的 6 条报文来保证的，中间任何一个环节出错，都可以基于这个 request-ack 机制来判定是否出错并重试。
我们最终采用的方案也正是参考了上面这个模型，客户端发送的逻辑是直接基于 http 的所以暂时不用做重试，主要是在服务端往客户端推送的时候，会加上重试的逻辑。
限于篇幅，本文就不详细展开，有兴趣可以系统学习以下几篇：
《从客户端的角度来谈谈移动端 IM 的消息可靠性和送达机制》
《IM 消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
《IM 消息送达保证机制实现(二)：保证离线消息的可靠投递》
《完全自已开发的 IM 该如何设计“失败重试”机制？》
《一套亿级用户的 IM 架构技术干货(下篇)：可靠性、有序性、弱网优化等》
《理解 IM 消息“可靠性”和“一致性”问题，以及解决方案探讨》
《融云技术分享：全面揭秘亿级 IM 消息的可靠投递机制》
4、当前面临的具体问题
4.1 概述在解决消息可靠投递这个问题之前，我们肯定首先应该搞清楚当前面临的具体问题到底有哪些。
然而在接手这套即时消息系统时，并没有相关的准确数据可供参考，所以当前第一步还是要对这套消息系统做一个完整的排查，于是我们对消息做了全链路埋点。
具体的埋点环节如下：
基于消息的整个链路，我们梳理出来了几个关键的指标：
1）发送成功率；
2）消息到达率；
3）客户端落库率。
这次整个数据的统计都是基于埋点来做的，但在埋点的过程中发现了一个很大的问题：当前这套即时消息系统没有一个全局唯一的消息 ID。这导致在全链路埋点的过程中，无法唯一确定这条消息的生命周期。
4.2 消息唯一性问题
如上图所示，当前的消息是通过 3 个变量来确定唯一性的：
1）SessionID: 当前会话的 ID；
2）SeqID：用户当前本地发送的消息序号，服务端是不关心此数据，完全是透传；
3）Version：这个比较重要，是消息在当前会话中的序号，已服务端为准，但是客户端也会生成一个假的 version。
以上图为例：当 A 和 B 同时发送消息的时候，都会在本地生成如上几个关键信息，当 A 发送的消息（黄色）首先到达服务端，因为前面没有其他 version 的消息，所以会将原数据返回给 A，客户端 A 接收到消息的时候，再跟本地的消息做合并，只会保留一条消息。同时服务端也会将此消息发送给 B，因为 B 本地也有一个 version=1 的消息，所以服务端过来的消息就会被过滤掉，这就出现消息丢失的问题。
当 B 发送消息到达服务端后，因为已经有 version=1 的消息，所以服务端会将 B 的消息 version 递增，此时消息的 version=2。这条消息发送给 A，和本地消息可以正常合并。但是当此消息返回给 B 的时候，和本地的消息合并，会出现 2 条一样的消息，出现消息重复，这也是为什么闲鱼之前总是出现消息丢失和消息重复最主要的原因。
4.3 消息推送逻辑问题
当前消息的推送逻辑也存在很大的问题，发送端因为使用 http 请求，发送的消息内容基本不会出问题，问题是出现在服务端给另外一端推送的时候。
如下图所示：
如上图所示：服务端在给客户端推送的时候，会先判断此时客户端是否在线，如果在线才会推送，如果不在线就会推离线消息。
这个做法就非常的简单粗暴：长连接的状态如果不稳定，导致客户端真实状态和服务端的存储状态不一致，就导致消息不会推送到端上。
4.4 客户端逻辑问题
除了以上跟服务端有关系外，还有一类问题是客户端本身设计的问题。
可以归结为以下几种情况：
1）多线程问题：反馈消息列表页面会出现布局错乱，本地数据还没有完全初始化好，就开始渲染界面；2）未读数和小红点的计数不准：本地的显示数据和数据库存储的不一致；
3）消息合并问题：本地在合并消息的时候，是分段合并的，不能保证消息的连续性和唯一性。
诸如以上的几种情况，我们首先是对客户端的代码做了梳理与重构。
架构如下图所示：
5、我们的优化工作 1：升级通心核心
解决问题第一步就是解决当前消息系统唯一性的问题。
我们也调研了钉钉的方案，钉钉是服务端全局维护消息的唯一 ID，考虑到闲鱼即时消息系统的历史包袱，我们这边采用 UUID 作为消息的唯一 ID，这样就可以在消息链路埋点以及去重上得到很大的改善。
5.1 解决消息唯一性
在新版本的 APP 上面，客户端会生成一个 uuid，对于老版本无法生成的情况，服务端也会补充上相关信息。
消息的 ID 类似于 a1a3ffa118834033ac7a8b8353b7c6d9，客户端在接收到消息后，会先根据 MessageID 来去重，然后基于 Timestamp 排序就可以了，虽然客户端的时间可能不一样，但是重复的概率还是比较小。
以 iOS 端为例，代码大致如下：
(void)combileMessages:(NSArray<PMessage*>*)messages {
...
// 1. 根据消息 MessageId 进行去重
NSMutableDictionary *messageMaps = [self containerMessageMap];
for (PMessage *message in msgs) {
}
// 2. 消息合并后排序
NSMutableArray *tempMsgs = [NSMutableArray array];
[tempMsgs addObjectsFromArray:messageMaps.allValues];
[tempMsgs sortUsingComparator:^NSComparisonResult(PMessage * _Nonnull obj1, PMessage * _Nonnull obj2) {
}];
...
}
5.2 实现消息重发、断线重连机制
基于本文“3、行业方案”一节中的重发重连模型，我们完善了服务端的消息重发的逻辑、客户端完善了断线重连的逻辑。
具体措施是：
1）客户端会定时检测 ACCS 长连接是否联通；
2）服务端会检测设备是否在线，如果在线会推送消息，并会有超时等待；
3）客户端接收到消息之后，会返回一个 Ack。
5.3 优化数据同步逻辑
重发重连解决的基础网络层的问题，接下来就要看下业务层的问题。
现有消息系统中，很多复杂情况是通过在业务层增加兼容代码来解决的，消息的数据同步就是一个很典型的场景。
在完善数据同步的逻辑之前，我们也调研过钉钉的一整套数据同步方案，他们主要是由服务端来保证的，背后有一个稳定的长连接保证。
钉钉的数据同步方案大致流程如下：
我们的服务端暂时还没有这种能力，所以闲鱼这边只能从客户端来控制数据同步的逻辑。
数据同步的方式包括：
1）拉取会话；
2）拉取消息；
3）推送消息等。
因为涉及到的场景比较复杂，之前有个场景就是推送会触发增量同步，如果推送过多的话，会同时触发多次网络请求，为了解决这个问题，我们也做了相关的推拉队列隔离。
客户端控制的策略就是如果在拉取的话，会先将 push 过来的消息加到缓存队列里面，等拉取的结果回来，会再跟本地缓存的逻辑做合并，这样就可以避免多次网络请求的问题。
5.4 客户端数据模型优化
客户端在数据组织形式上，主要分 2 中：会话和消息，会话又分为：虚拟节点、会话节点和文件夹节点。
在客户端会构建上图一样的树，这棵树主要保存的是会话显示的相关信息，比如未读数、红点以及最新消息摘要，子节点更新，会顺带更新到父节点，构建树的过程也是已读和未读数更新的过程。
其中比较复杂的场景是闲鱼情报社，这个其实是一个文件夹节点，它包含了很多个子的会话，这就决定了他的消息排序、红点计数以及消息摘要的更新逻辑会更复杂，服务端告知客户端子会话的列表，然后客户端再去拼接这些数据模型。
5.5 服务端存储模型优化
在前述内容中，我大概讲了客户端的请求逻辑，即历史消息会分为增量和全量域同步。
这个域其实是服务端的一层概念，本质上就是用户消息的一层缓存，消息过来之后会暂存在缓存中，加速消息读取。
但是这个设计也存在一个缺陷：就是域环是有长度的，最多保存 256 条，当用户的消息数多于 256 条，只能从数据库中读取。
关于服务端的存储方式，我们也调研过钉钉的方案——是写扩散，优点就是可以很好地对每位用户的消息做定制化，缺点就是存储量很很大。
我们的这套解决方案，应该是介于读扩散和写扩散之间的一种解决方案。这个设计方式不仅使客户端逻辑复杂，服务端的数据读取速度也会比较慢，后续这块也可以做优化。
6、我们的优化工作 2：增加质量监控体系
在做客户端和服务端的全链路改造的同时，我们也对消息线上的行为做了监控和排查的逻辑。
6.1 全链路排查
全链路排查是基于用户的实时行为日志，客户端的埋点通过集团实时处理引擎 Flink，将数据清洗到 SLS 里面。
用户的行为包括：
1）消息引擎对消息的处理；
2）用户的点击/访问页面的行为；
3）用户的网络请求。服务端侧会有一些长连接推送以及重试的日志，也会清洗到 SLS，这样就组成了从服务端到客户端全链路的排查的方案。
6.2 对账系统
当然为了验证消息的准确性，我们还做了对账系统：
在用户离开会话的时候，我们会统计当前会话一定数量的消息，生成一个 md5 的校验码，上报到服务端。服务端拿到这个校验码之后再判定是否消息是正确的。
经过抽样数据验证，消息的准确性基本都在 99.99%。
7、数据指标统计方法优化
我们在统计消息的关键指标时，遇到点问题：之前我们是用用户埋点来统计的，发现会有 3%~5%的数据差。
后来我们采用抽样实时上报的数据来计算数据指标：
消息到达率 = 客户端实际收到的消息量 / 客户端应该收到的消息量
客户端实际收到的消息的定义为“消息落库才算是”。
该指标不区分离线在线，取用户当日最后一次更新设备时间，理论上当天且在此时间之前下发的消息都应该收到。
经过前述优化工作，我们最新版本的消息到达率已经基本达到 99.9%，从舆情上来看，反馈丢消息的也确实少了很多。
8、未来规划
整体看来，经过一年的优化治理，我们的即时消息系统各项指标在慢慢变好。
但还是存在一些待优化的方面：
1）消息的安全性不足：容易被黑产利用，借助消息发送一些违规的内容；
2）消息的扩展性较弱：增加一些卡片或者能力就要发版，缺少了动态化和扩展的能力。
3）底层的伸缩性不足：现在底层协议比较难扩展，后续还是要规范一下协议。
从业务角度看，消息应该是一个横向支撑的工具性或者平台型的产品，且可以快速对接二方和三方的快速对接。
接下来，我们会持续关注消息相关的用户舆情，希望闲鱼即时消息系统能帮助用户更好的完成业务交易。
附录：更多相关文章
[1] 更多阿里巴巴的技术资源：
《阿里钉钉技术分享：企业级 IM 王者——钉钉在后端架构上的过人之处》
《现代 IM 系统中聊天消息的同步和存储方案探讨》
《阿里技术分享：深度揭秘阿里数据库技术方案的 10 年变迁史》
《阿里技术分享：阿里自研金融级数据库 OceanBase 的艰辛成长之路》
《来自阿里 OpenIM：打造安全可靠即时通讯服务的技术实践分享》
《钉钉——基于 IM 技术的新一代企业 OA 平台的技术挑战(视频+PPT) [附件下载]》
《阿里技术结晶：《阿里巴巴 Java 开发手册(规约)-华山版》[附件下载]》
《重磅发布：《阿里巴巴 Android 开发手册(规约)》[附件下载]》
《作者谈《阿里巴巴 Java 开发手册(规约)》背后的故事》
《《阿里巴巴 Android 开发手册(规约)》背后的故事》
《干了这碗鸡汤：从理发店小弟到阿里 P10 技术大牛》
《揭秘阿里、腾讯、华为、百度的职级和薪酬体系》
《淘宝技术分享：手淘亿级移动端接入层网关的技术演进之路》
《难得干货，揭秘支付宝的 2 维码扫码技术优化实践之路》
《淘宝直播技术干货：高清、低延时的实时视频直播技术解密》
《阿里技术分享：电商 IM 消息平台，在群聊、直播场景下的技术实践》
《阿里技术分享：闲鱼 IM 基于 Flutter 的移动端跨端改造实践》
《阿里 IM 技术分享(三)：闲鱼亿级 IM 消息系统的架构演进之路》
《阿里 IM 技术分享(四)：闲鱼亿级 IM 消息系统的可靠投递优化实践》
[2] 有关 IM 架构设计的文章：
《浅谈 IM 系统的架构设计》
《简述移动端 IM 开发的那些坑：架构设计、通信协议和客户端》
《一套海量在线用户的移动端 IM 架构设计实践分享(含详细图文)》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM 服务器开发之架构选择》
《腾讯 QQ1.4 亿在线用户的技术挑战和架构演进之路 PPT》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从 0 到 1 的演进历程（一）》
《移动端 IM 中大规模群消息的推送如何保证效率、实时性？》
《现代 IM 系统中聊天消息的同步和存储方案探讨》
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级 IM 平台的技术实践》
《微信技术分享：微信的海量 IM 聊天消息序列号生成实践（算法原理篇）》
《一套高可用、易伸缩、高并发的 IM 群聊、单聊架构方案设计实践》
《社交软件红包技术解密(一)：全面解密 QQ 红包技术方案——架构、技术实现等》
《从游击队到正规军(一)：马蜂窝旅游网的 IM 系统架构演进之路》
《从游击队到正规军(二)：马蜂窝旅游网的 IM 客户端架构演进和实践总结》
《从游击队到正规军(三)：基于 Go 的马蜂窝旅游网分布式 IM 系统技术实践》
《瓜子 IM 智能客服系统的数据架构设计（整理自现场演讲，有配套 PPT）》
《IM 开发基础知识补课(九)：想开发 IM 集群？先搞懂什么是 RPC！》
《阿里技术分享：电商 IM 消息平台，在群聊、直播场景下的技术实践》
《一套亿级用户的 IM 架构技术干货(上篇)：整体架构、服务拆分等》
《一套亿级用户的 IM 架构技术干货(下篇)：可靠性、有序性、弱网优化等》
《从新手到专家：如何设计一套亿级消息量的分布式 IM 系统》
《企业微信的 IM 架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》
《融云技术分享：全面揭秘亿级 IM 消息的可靠投递机制》
《IM 开发技术学习：揭秘微信朋友圈这种信息推流背后的系统设计》
《阿里 IM 技术分享(三)：闲鱼亿级 IM 消息系统的架构演进之路》
本文已同步发布于“即时通讯技术圈”公众号。
还未添加个人签名 2019.08.26 加入
开源IM框架MobileIMSDK、BeautyEye的作者。
评论