阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路

本文由阿里闲鱼技术团队今朝、有攸分享，即时通讯网有修订，感谢作者的技术分享。

1、引言

闲鱼即时消息系统历经数代迭代，目前已能稳定的支撑亿级消息体量。

在此消息系统的建设过程中，我们经历了从简单到复杂、从困扰到破局，每一次的技术改变都是为了更好的解决当下业务所面临的问题。

本文分享的是闲鱼即时消息系统架构从零开始的技术变迁之路，以期更多的同行们在此基础上汲取经验，得到有价值的启发。



本文已同步发布于“即时通讯技术圈”公众号，欢迎关注。公众号上的链接是：点此进入。

2、系列文章

本文是系列文章的第3篇，总目录如下：

• 《阿里IM技术分享(一)：企业级IM王者——钉钉在后端架构上的过人之处》
• 《阿里IM技术分享(二)：闲鱼IM基于Flutter的移动端跨端改造实践》
• 《阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路》（* 本文）
• 《阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践》
• 《阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践》
• 《阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化》
• 《阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实践》
  

3、1.0版：业务初创期、最小化可用

3.1技术背景

2014年启动闲置交易独立APP “闲鱼”，一期构建完成APP主链路，包含商品：发布→搜索→商品详情→IM会话→交易。

作为初创app，业务需尽快上线验证效果，技术建设上需要完成闲鱼消息从无到有的系统搭建。

3.2技术方案

作为即时通讯系统，最小化能力包含：

• 1）消息存储：会话、摘要、消息；
• 2）消息同步：推、拉；
• 3）消息通道：长连接、厂商推送。
  

与一般IM会话模型不同的是，闲鱼会话以商品为主体，“人＋人+商品”为要素构建会话。

因会话模型的差异，淘系已有的消息系统，短期内无法满足业务需求，而闲鱼完全自建消息系统耗时巨大。

为了保障业务高效上线，技术选型上最大化复用已有系统能力，避免重复造轮子。

所以，我们的技术方案是：

• 1）数据模型与底层存储依赖淘系私信体系进行建设；
• 2）消息数据获取上，客户端全量从服务端拉取消息数据；
• 3）通讯协议使用来往SDK及mtop。
  

总体架构如下图，以此模式完成快速交付保障了业务最小化可用：

4、2.0版：用户量增速快、需要重建消息系统

4.1技术背景

闲鱼用户量正快速突破100万，即时消息服务的调用量暴涨。在这样的背景下，用户反馈消息数据获取的卡顿、白屏成为常态，大量的消息Push发送下，系统告警频发。

造成这些问题的原因：1.0版的架构模式下，获取消息数据全量拉模式，客户端纯UI不做数据存储。

具体就是：

• 1）当用户需要查看消息数据时，数据拉取成功与否取决于网络、数据访问速度，偶发性的造成卡顿、白屏；
• 2）中心化的数据存储，读远大于写，高并发下，服务端负载过大。
  

针对第2）点：比如1W个用户同时在线聊天，按照当前架构并发拉取全量消息，估算5万QPS。不妨假设，同时在线聊天用户数10万时，对服务端压力可想而知。

4.2技术方案

基于上述问题，我们决定重建消息系统架构，以应对未来更大的用户增量。

回归到IM系统的核心功能：


4.2.1）消息存储模型：

• 1）会话模型：由owner、itemid、user、sessionType 来标识唯一会话，增加扩展属性支持个性化；
• 2）摘要模型：作为用户会话视图，同一会话的不同用户可个性化呈现，由userid、sid标识唯一摘要；
• 3）消息模型：由sender、消息内容、消息版本、sid组成。sid+消息版本唯一确定一条消息；
• 4）指令模型：是一种双端约定，由服务端下发，客户端执行的指令集。如免打扰指令、删除指令等。
  

4.2.2）消息通道：

• 1）在线通道：使用淘宝无线ACCS长连接提供的全双工、低延时、高安全的通道服务；
• 2）离线通道：使用淘宝消息推送平台AGOO. 其屏蔽了各主流厂商对接的复杂度，直接对业务系统提供服务。
  

4.2.3）消息同步模型：

1）客户端建立数据库，存储消息数据：当消息数据存储在本地设备上，消息同步从全量拉取优化为全量+增量同步结合的模式。

增量和全量同步具体指的是：

• a. 增量同步：客户端存储消息位点信息，通过与服务端最新位点比较，仅同步增量消息；
• b. 全量同步：当用户卸载重装或位点gap过大时，客户端全量拉取历史消息数据，进行端上数据重建。
  

2）服务端建设个人消息域环(收件箱模型)：以和客户端进行增量数据同步。同时，1.0版本架构中存在的读多写少的问题，通过个人域环的写扩散来平衡读写压力。

下图为一条消息从发送到接收的过程以及服务端和客户端的执行流程：


如上图所示：假设Ua给Ub发送一条消息，消息写扩散至Ua和Ub的各自的域环中：

• 1）当客户端online时，接收到推送的消息位点=当前端上域版本+1，本地消息数据库merge即可；
• 2）当客户端offline时，仅进行离线推送通知，当用户重新上线时，进行数据同步，由服务端判断触发增量同步还是全量同步。
  

针对第2）点，具体逻辑是：

• 1）如果域环版本差值小于阀值，增量同步后，进行本地消息数据库merge；
• 2）当域环版本差值大于阀值，进行全量消息拉取，做端上数据重建。
  

整个同步逻辑基于闲鱼的即时消息域环，域环可以看作是有着固定容量的用户消息收件箱，给一个用户发送的所有消息都会同步到他的域环中。

具体就是：

• 1）域环存储：域环需要支持高并发数据读写，使用阿里分布式KV存储系统tair来实现；
• 2）域环容量：为减少全量消息同步，以用户下次进入闲鱼需要同步的平均消息量来规划个人域环容量。同时利用FIFO循环覆盖历史数据；
• 3）域环版本：用户当前消息位点，在消息进入个人域环时通过tair的counter实现域环版本严格连续递增，用于全量、增量同步判断。
  

上述建设完成后，闲鱼具备了自己独立的即时消息系统，当下遇到的问题得到了缓解，用户体验度有大幅提升。

5、3.0版：随着业务快速发展，系统稳定性需得到保障

5.1技术背景

随着闲鱼业务生态的丰富，IM会话与消息内容类型不断扩展，同时在用户量的快速增长下，用户反馈消息收不到、消息延迟等舆情问题日渐突出。

5.2问题分析

问题1：闲鱼app进程无有效保活机制，app退到后台后进程很快就会被系统挂起，导致长连接中断。此时消息推送走厂商通道，而厂商通道的实时性较差，且对消息推送的优先级设定有差异，从而造成用户感知消息延迟。

问题2：accs在线消息推送时，平均延时较短，但存在假连情况。而且目前的消息推送链路无ack机制，造成服务端以为消息发出去了但实际上客户端并没有收到，用户下次打开app后才能看到消息，用户感知消息延迟。
PS：造成假连接的原因主要是用户退到后台，accs长连中断，但是设备状态更新有延时。

问题3：目前消息同步的推模式(accs push)、拉模式(mtop)，客户端未做隔离，异步进行处理，导致在某些极端情况下消息数据库处理异常，引发消息丢失。
如：某用户上线后连续收到多条消息，其中一条触发域黑洞，在进行消息同步端上数据重建时，小概率处理出错。

问题4：大部分线上消息问题发现靠舆情反馈，如消息错乱，出问题后系统无感知、无补救措施且排查困难，仅能跟随版本做修复。

问题5：业务不断丰富，孵化出基于消息系统的服务号及小程序内容营销、消息群组等，各类消息发送链路共用域环与数据存储，造成稳定性问题。
如：个人域环的消息包括IM聊天和营销消息，IM聊天由用户触发，需要保证强到达；而营销消息一般是由系统通过班车等方式批量发送，消息量级大，tps高，影响IM服务稳定性。

5.3解案决方案

基于上述分析，我们逐个问题进行专项解决。

1）消息重发与推拉隔离：



如上图所示：

• a. ACK：保障消息及时到达。服务端下行accs消息时，将消息加入重试队列并延迟重试，客户端在收到accs消息并处理成功后，给服务端回一个ack，服务端收到ack后更新消息到达状态，并终止重试，以此避免设备假连或网络不稳定的情况；
• b. 重发：根据延迟重发策略决定何时重发消息，保障消息确定性到达。自适应延迟重发策略是指新消息先通过4次固定N秒的短延迟来探测设备的网络状况，然后根据网络状况来递增固定步长M的延迟策略，这种策略可以保障在最短的时间内，使用最少的重发次数将消息投递成功；
• c. 消息队列：端上引入消息队列，按顺序处理消息，保证消息处理的准确性。同时进行推拉隔离，保障队列有序消费，解决了复杂状况下并发处理消息数据合并出错的问题。
  

2）数据存储拆分：

闲鱼每天发送的即时消息中有一半以上是营销消息，营销消息的发送具有明显的波峰波谷流量，高峰期会导致消息数据库抖动，影响IM消息。我来对消息、摘要、域环存储做业务隔离，以适应不同业务场景对稳定性不同的要求。

具体做法是：

• 1）IM消息需要极高的稳定性保证，其消息及摘要继续使用mysql存储；
• 2）营销消息存储周期短，稳定性要求低于IM，采用Lindorm存储；
• 3）域环做实例级别隔离，保证IM域环的容量不会被其他消息占用，从而影响到消息同步。
  

PS：Lindorm是一种多模型的云原生数据库服务，具有成本低、自定义TTL、容量横向扩展等优势。



3）线上问题发现与恢复：

保障稳定性的关键要素是做好各种核心指标的监控，而监控首先要有数据来源，对服务端+客户端的关键链路节点埋点，基于集团UT、SLS，通过blink进行实时清洗、计算，最终形成统一规范的日志数据落至SLS，以供实时监控及链路排查。

消息系统的核心目标是保障用户消息发的出、收得到且及时收到，所以我们通过计算发送成功率、到达率、消息延迟来监控系统的稳定性。

此外，为了解决用户舆情排查困难的问题：

• 1）我们设计了一套指令集，通过约定指令协议，服务端向指定用户下发指令，客户端执行对应指令进行异常数据上报，提高排查效率；
• 2）扩展了强制全量同步、数据校正等指令，定向修复用户消息数据问题，相较以往出现严重bug只能让用户卸载重装解决，这种方式显然对用户是更友好的。
  

经过一系列专项治理，技术类舆情下降50%，从0到1建设了消息稳定性体系，用户体验进一步提升。

6、展望未来

闲鱼作为电商交易APP， 其中IM是交易的前置链路，IM的产品体验极大影响用户交易效率。

前段时间进行用户调研，从闲鱼IM的NPS低于预期（NPS是用户忠诚度衡量指标 = 推荐者%-贬损者%）。

从用户反馈来看：

• 1）部分用户对产品功能有较强烈的诉求，诸如消息搜索、分组等；
• 2）大部分用户对发送消息过程中的违规问题难以理解；
• 3）仍有较多舆情反馈消息收不到或延迟。
  

映射到目前闲鱼的即时消息系统上，我们的系统架构依然有很多需要持续改进的地方。

典型的如：同步协议冗余，在需求迭代过程中容易引发问题、有效保活机制的缺失对消息即时送达的影响、小众机型离线消息收不到、多年的数据积累在线库臃肿等问题，影响着闲鱼业务迭代速度与NPS。

作为技术团队，下一步将提升NPS作为核心技术目标，闲鱼的即时消息系统4.0版架构正在路上 ......

附录：更多相关文章

[1] 更多阿里巴巴的技术资源：

《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
《现代IM系统中聊天消息的同步和存储方案探讨》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》
《钉钉——基于IM技术的新一代企业OA平台的技术挑战(视频+PPT) [附件下载]》
《阿里技术结晶：《阿里巴巴Java开发手册(规约)-华山版》[附件下载]》
《重磅发布：《阿里巴巴Android开发手册(规约)》[附件下载]》
《作者谈《阿里巴巴Java开发手册(规约)》背后的故事》
《《阿里巴巴Android开发手册(规约)》背后的故事》
《干了这碗鸡汤：从理发店小弟到阿里P10技术大牛》
《揭秘阿里、腾讯、华为、百度的职级和薪酬体系》
《淘宝技术分享：手淘亿级移动端接入层网关的技术演进之路》
《难得干货，揭秘支付宝的2维码扫码技术优化实践之路》
《淘宝直播技术干货：高清、低延时的实时视频直播技术解密》
《阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践》
《阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践》
《阿里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消息系统的架构演进之路》
>> 更多同类文章 ……

通读完全文，最深的一个感受就是“架构不是一开始就设计完美的，而是不断演进出来的”，即使是大厂，也免不了一开始粗放的架构设计。

引用：闲鱼app进程无有效保活机制，app退到后台后进程很快就会被系统挂起，导致长连接中断。此时消息推送走厂商通道，而厂商通道的实时性较差，且对消息推送的优先级设定有差异，从而造成用户感知消息延迟。

对于这一点我深有体会，在接入厂商通道时，不同厂商的消息推送到达率和及时率表现不一，华为通道表现最好，小米次之，OPPO、VIVO、魅族等一言难尽。
当时就非常不明白，作为系统进程级别的厂商长连接通道，为什么表现还会这么差呢？所以推送这方面特别羡慕iOS的APNS推送机制，统一的方案，没有那么多适配问题。

引用：椎锋陷陈 发表于 2021-09-13 10:00
对于这一点我深有体会，在接入厂商通道时，不同厂商的消息推送到达率和及时率表现不一，华为通道表现最好 ...

对的，纸上谈兵肯定不行

引用：椎锋陷陈 发表于 2021-09-13 10:00
对于这一点我深有体会，在接入厂商通道时，不同厂商的消息推送到达率和及时率表现不一，华为通道表现最好 ...

后面这几个厂商，推送通道做的太晚了，这方面的技术积累和实践还是太少了

引用：JackJiang 发表于 2021-09-13 10:18
后面这几个厂商，推送通道做的太晚了，这方面的技术积累和实践还是太少了

嗯，确实可能是这个原因，导致厂商通道推送的到达率和及时率可能还不如第三方推送平台

引用：椎锋陷陈 发表于 2021-09-13 10:45
嗯，确实可能是这个原因，导致厂商通道推送的到达率和及时率可能还不如第三方推送平台

我记得Oppo两年前还联系过我，说正在做自有推送通道，那会儿华为和小米的通道都很成熟了

引用：JackJiang 发表于 2021-09-13 11:07
我记得Oppo两年前还联系过我，说正在做自有推送通道，那会儿华为和小米的通道都很成熟了

向您请教推送技术实现吗？果然是大佬

引用：椎锋陷陈 发表于 2021-09-13 11:19
向您请教推送技术实现吗？果然是大佬

请教倒谈不上，可能有合作的意思。或许也是头一次做这种东西