本文由阿里闲鱼技术团队今朝、有攸分享，本次有订正。
1、引言
闲鱼即时消息零碎历经数代迭代，目前已能稳固的撑持亿级音讯体量。
在此音讯零碎的建设过程中，咱们经验了从简略到简单、从困扰到破局，每一次的技术扭转都是为了更好的解决当下业务所面临的问题。
本文分享的是闲鱼即时消息零碎架构从零开始的技术变迁之路，以期更多的同行们在此基础上吸取教训，失去有价值的启发。
学习交换：
- 即时通讯 / 推送技术开发交换 5 群：215477170 [举荐]
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2…
（本文同步公布于：http://www.52im.net/thread-36…）
2、系列文章
本文是系列文章的第 3 篇，总目录如下：
《阿里 IM 技术分享(一)：企业级 IM 王者——钉钉在后端架构上的过人之处》
《阿里 IM 技术分享(二)：闲鱼 IM 基于 Flutter 的挪动端跨端革新实际》
《阿里 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 音讯零碎的架构演进之路》
更多同类文章 ……
本文已同步公布于“即时通讯技术圈”公众号。
同步公布链接是：http://www.52im.net/thread-36…