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

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

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

学习交流：

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

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

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

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

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

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

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

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

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

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

具体就是：

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

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

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

4.2.1）消息存储模型：

4.2.2）消息通道：

1）在线通道：使用淘宝无线ACCS长连接提供的全双工、低延时、高安全的通道服务；

2）离线通道：使用淘宝消息推送平台AGOO.其屏蔽了各主流厂商对接的复杂度，直接对业务系统提供服务。

4.2.3）消息同步模型：

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

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

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

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

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

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

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

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

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

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

问题2：accs在线消息推送时，平均延时较短，但存在假连情况。而且目前的消息推送链路无ack机制，造成服务端以为消息发出去了但实际上客户端并没有收到，用户下次打开app后才能看到消息，用户感知消息延迟。

PS：造成假连接的原因主要是用户退到后台，accs长连中断，但是设备状态更新有延时。

问题3：目前消息同步的推模式(accspush)、拉模式(mtop)，客户端未做隔离，异步进行处理，导致在某些极端情况下消息数据库处理异常，引发消息丢失。

如：某用户上线后连续收到多条消息，其中一条触发域黑洞，在进行消息同步端上数据重建时，小概率处理出错。

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

问题5：业务不断丰富，孵化出基于消息系统的服务号及小程序内容营销、消息群组等，各类消息发送链路共用域环与数据存储，造成稳定性问题。

如：个人域环的消息包括IM聊天和营销消息，IM聊天由用户触发，需要保证强到达；而营销消息一般是由系统通过班车等方式批量发送，消息量级大，tps高，影响IM服务稳定性。

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

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

如上图所示：

2）数据存储拆分：

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

具体做法是：

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

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

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

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

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

从用户反馈来看：

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

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

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