阿里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：可能很多人对移动网络的复杂性没有个系统的认知，以下文章有必要系统阅读：
那么，在如此复杂的网络环境下，是如何稳定可靠的进行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) {
[messageMaps setObject:message forKey:message.messageId];
}
// 2. 消息合并后排序
NSMutableArray *tempMsgs = [NSMutableArray array];
[tempMsgs addObjectsFromArray:messageMaps.allValues];
[tempMsgs sortUsingComparator:^NSComparisonResult(PMessage * _Nonnull obj1, PMessage * _Nonnull obj2) {
// 根据消息的timestamp进行排序
return obj1.timestamp > obj2.timestamp;
}];
...
}
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王者——钉钉在后端架构上的过人之处》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
《钉钉——基于IM技术的新一代企业OA平台的技术挑战(视频+PPT) [附件下载]》
《阿里技术结晶：《阿里巴巴Java开发手册(规约)-华山版》[附件下载]》
《重磅发布：《阿里巴巴Android开发手册(规约)》[附件下载]》
《阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践》
《阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践》
《阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路》
《阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践》
[2] 有关IM架构设计的文章：
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》
《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》
《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》
《从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践》
《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》
《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》
《阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践》
《一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等》
《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》
《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》
《IM开发技术学习：揭秘微信朋友圈这种信息推流背后的系统设计》
《阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路》
>> 更多同类文章 ……
本文已同步发布于“即时通讯技术圈”公众号。
作者：Jack Jiang (点击作者姓名进入Github)
出处：http://www.52im.net/space-uid-1.html
交流：欢迎加入即时通讯开发交流群 215477170
讨论：http://www.52im.net/
Jack Jiang同时是【原创Java
Swing外观工程BeautyEye】和【轻量级开源移动端即时通讯框架MobileIMSDK】的作者，可前往下载交流。
本博文
欢迎转载，转载请注明出处（也可前往 我的52im.net 找到我）。
