关于im:闲鱼消息发展回顾

简介：转自闲鱼技术 作者：今朝、有攸

OpenIMgithub 开源地址：

https://github.com/OpenIMSDK/…

OpenIM 官网：https://www.rentsoft.cn

OpenIM 官方论坛：https://forum.rentsoft.cn/

引言

闲鱼音讯零碎通过几代开发的建设，目前稳固的撑持亿级音讯体量。在音讯零碎建设过程中，咱们经验了从简略到简单，从困扰到破局，每一次的技术扭转都是为了更好的解决当下业务面临的问题。“忆昔午桥桥上饮，坐中多是豪英“，此文记录闲鱼音讯零碎技术变迁，以期在此基础上吸取更多教训。

闲鱼音讯 1.0: 业务初创期，最小化可用

背景：14 年启动闲置交易独立 APP“闲鱼”，一期构建实现 APP 主链路，蕴含商品公布→搜寻→商品详情→IM 会话→交易。作为初创 app，业务需尽快上线验证成果，技术建设上须要实现闲鱼音讯从无到有的零碎搭建。

作为即时通讯零碎，最小化能力蕴含

1. 音讯存储：会话、摘要、音讯
2. 音讯同步：推、拉
3. 音讯通道：长连贯、厂商推送

与个别 IM 会话模型不同的是，闲鱼会话以商品为主体，人+人 + 商品为因素构建会话，因会话模型的差别，淘系已有的音讯零碎，短期内无奈满足业务需要，而闲鱼齐全自建音讯零碎耗时微小。为了保障业务高效上线，技术选型上最大化复用已有零碎能力，防止反复造轮子。
所以，

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

总体架构如下图，以此模式实现疾速交付保障了业务最小化可用

闲鱼音讯 2.0：用户量高增速，重建闲鱼音讯零碎

背景： 闲鱼用户量疾速冲破 100W，音讯服务调用量暴涨。常态性的，用户反馈音讯数据获取卡顿、白屏，大量的 push 发送下，零碎告警频发。

造成这些问题的起因：音讯 1.0 模式下，获取音讯数据全量拉模式，客户端纯 UI 不做数据存储

1. 当用户须要查看音讯数据时，数据拉取胜利与否取决于网络、数据访问速度，偶发性的造成卡顿、白屏
2. 中心化的数据存储，读远大于写，高并发下，服务端负载过大
   比方 1W 个用户同时在线聊天，依照以后架构并发拉取全量音讯，估算 5Wqps. 无妨假如，同时在线聊天用户数 10W 时，对服务端压力可想而知

基于上述问题，咱们决定重建音讯零碎，以应答将来更大的用户增量。回归到 IM 零碎的外围性能

音讯存储模型：
会话模型：由 owner、itemid、user、sessionType 来标识惟一会话，减少扩大属性反对个性化
摘要模型：作为用户会话视图，同一会话的不同用户可个性化出现，由 userid、sid 标识惟一摘要
音讯模型：由 sender、音讯内容、音讯版本、sid 组成。sid+ 音讯版本惟一确定一条音讯
指令模型：是一种双端约定，由服务端下发，客户端执行的指令集。如免打搅指令、删除指令等
音讯通道：
在线通道：应用淘宝无线 ACCS 长连贯提供的全双工、低延时、高平安的通道服务。
离线通道：应用淘宝音讯推送平台 AGOO. 其屏蔽了各支流厂商对接的复杂度，间接对业务零碎提供服务
音讯同步模型：
1. 客户端建设数据库，存储音讯数据

     当音讯数据存储在本地设施上，音讯同步从全量拉取优化为全量 + 增量同步联合的模式。增量同步：客户端存储音讯位点信息，通过与服务端最新位点比拟，仅同步增量音讯；全量同步：当用户卸载重装或位点 gap 过大时，客户端全量拉取历史音讯数据，进行端上数据重建

2. 服务端建设集体音讯域环(收件箱模型)，以和客户端进行增量数据同步。同时，音讯 1.0 版本存在的读多写少的问题，通过集体域环的写扩散来均衡读写压力

下图为一条音讯从发送到接管的过程以及服务端和客户端的执行流程

如图所示，假如 Ua 给 Ub 发送一条音讯，音讯写扩散至 Ua 和 Ub 的各自的域环中。
1. 当客户端 online 时，接管到推送的音讯位点 = 以后端上域版本 +1，本地音讯数据库 merge 即可
2. 当客户端 offline 时，仅进行离线推送告诉，当用户从新上线时，进行数据同步，由服务端判断触发增量同步还是全量同步

     如果域环版本差值小于阀值，增量同步后，进行本地音讯数据库 merge
      当域环版本差值大于阀值，进行全量音讯拉取，做端上数据重建

整个同步逻辑基于闲鱼的音讯域环，域环能够看作是有着固定容量的用户音讯收件箱，给一个用户发送的所有音讯都会同步到他的域环中。
域环存储 ：域环须要反对高并发数据读写，应用阿里分布式 KV 存储系统 tair 来实现
域环容量 ：为缩小全量音讯同步，以用户下次进入闲鱼须要同步的均匀音讯量来布局集体域环容量。同时利用 FIFO 循环笼罩历史数据
域环版本：用户以后音讯位点，在音讯进入集体域环时通过 tair 的 counter 实现域环版本严格间断递增，用于全量、增量同步判断

上述建设实现后，闲鱼具备了本人独立的音讯零碎，当下遇到的问题失去了缓解，用户体验度有大幅晋升。

闲鱼音讯 3.0：业务疾速倒退下，零碎稳定性保障

背景： 随着闲鱼业务生态的丰盛，IM 会话与音讯内容类型一直扩大，同时在 DAU 的快速增长下，用户反馈音讯收不到、音讯提早等舆情问题日渐突出。

问题剖析:
1. 闲鱼 app 过程无无效保活机制，app 退到后盾后过程很快就会被零碎挂起，导致长连贯中断。此时音讯推送走厂商通道，而厂商通道的实时性较差，且对音讯推送的优先级设定有差别，从而造成用户感知音讯提早
2.accs 在线音讯推送时，均匀延时较短，但存在假连状况，而且目前的音讯推送链路无 ack 机制，造成服务端认为音讯收回去了但实际上客户端并没有收到，用户下次关上 app 后能力看到音讯，用户感知音讯提早。造成假连贯的起因：用户退到后盾，accs 长连中断，然而设施状态更新有延时。
3. 目前音讯同步的推模式(accs push)、拉模式(mtop)，客户端未做隔离，异步进行解决，导致在某些极其状况下音讯数据库解决异样，引发音讯失落。比方某用户上线后间断收到多条音讯，其中一条触发域黑洞，在进行音讯同步端上数据重建时，小概率解决出错。
4. 大部分线上音讯问题发现靠舆情反馈，如音讯错乱，出问题后零碎无感知、无补救措施且排查艰难，仅能追随版本做修复
5. 业务不断丰富，孵化出基于音讯零碎的服务号及小程序内容营销、音讯群组等，各类音讯发送链路共用域环与数据存储，造成稳定性问题。如集体域环的音讯包含 IM 聊天和营销音讯，IM 聊天由用户触发，须要保障强达到；而营销音讯个别是由零碎通过班车等形式批量发送，音讯量级大，tps 高，影响 IM 服务稳定性

基于上述剖析，咱们进行专项解决：
音讯重发与推拉隔离

ACK: 保障音讯及时达到。服务端上行 accs 音讯时，将音讯退出重试队列并提早重试，客户端在收到 accs 音讯并解决胜利后，给服务端回一个 ack，服务端收到 ack 后更新音讯达到状态，并终止重试，以此防止设施假连或网络不稳固的状况。
重发：依据提早重发策略决定何时重发消息，保障音讯确定性达到。自适应提早重发策略是指新音讯先通过 4 次固定 N 秒的短提早来探测设施的网络情况，而后依据网络情况来递增固定步长 M 的提早策略，这种策略能够保障在最短的工夫内，应用起码的重发次数将音讯投递胜利。
音讯队列：端上引入音讯队列，按程序解决音讯，保障音讯解决的准确性。同时进行推拉隔离，保障队列有序生产，解决了简单情况下并发解决音讯数据合并出错的问题。

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

1. IM 音讯须要极高的稳定性保障，其音讯及摘要持续应用 mysql 存储
2. 营销音讯存储周期短，稳定性要求低于 IM，采纳 Lindorm 存储。Lindorm 是一种多模型的云原生数据库服务，具备成本低、自定义 TTL、容量横向扩大等劣势
3. 域环做实例级别隔离，保障 IM 域环的容量不会被其余音讯占用，从而影响到音讯同步

线上问题发现与复原
保障稳定性的要害因素是做好各种外围指标的监控，而监控首先要有数据起源，对服务端 + 客户端的要害链路节点埋点，基于团体 UT、SLS，通过 blink 进行实时荡涤、计算，最终造成对立标准的日志数据落至 SLS，以供实时监控及链路排查。
音讯零碎的外围指标是保障用户音讯发的出、收失去且及时收到，所以咱们通过计算发送成功率、达到率、音讯提早来监控零碎的稳定性。此外，为了解决用户舆情排查艰难的问题

1. 咱们设计了一套指令集，通过约定指令协定，服务端向指定用户下发指令，客户端执行对应指令进行异样数据上报，进步排查效率
2. 扩大了强制全量同步、数据校对等指令，定向修复用户音讯数据问题，相较以往呈现重大 bug 只能让用户卸载重装解决，这种形式显然对用户是更敌对的

通过一系列专项治理，技术类舆情降落 50%，从 0 到 1 建设了音讯稳定性体系，用户体验进一步晋升。

最初：宏大的用户体量下，谋求极致的 NPS

闲鱼作为电商交易 APP，其中 IM 是交易的前置链路，IM 的产品体验极大影响用户交易效率
前段时间进行用户调研，从闲鱼 IM NPS 低于预期(NPS 是用户忠诚度掂量指标 = 推荐者 %- 贬损者 %)，从用户反馈来看：

1. 局部用户对产品性能有较强烈的诉求，诸如音讯搜寻、分组等
2. 大部分用户对发送音讯过程中的违规问题难以了解
3. 仍有较多舆情反馈音讯收不到或提早

映射到目前闲鱼的音讯零碎上，咱们的零碎架构仍然有很多须要继续改良的中央。典型的如同步协定冗余，在需要迭代过程中容易引发问题、无效保活机制的缺失对音讯即时送达的影响、小众机型离线音讯收不到、多年的数据积攒在线库臃肿等问题，影响着闲鱼业务迭代速度与 NPS。将晋升 NPS 作为外围指标，闲鱼音讯 4.0 进行时 ….

OpenIM 官网：https://www.rentsoft.cn

OpenIM 官方论坛：https://forum.rentsoft.cn/

更多原创技术文章：

开源 OpenIM：高性能、可伸缩、易扩大的即时通讯架构
https://forum.rentsoft.cn/thr…

【OpenIM 原创】简略轻松入门 一文解说 WebRTC 实现 1 对 1 音视频通信原理
https://forum.rentsoft.cn/thr…

【OpenIM 原创】开源 OpenIM：轻量、高效、实时、牢靠、低成本的音讯模型

https://forum.rentsoft.cn/thr…

OpenIM 服务发现和负载平衡 golang 插件：gRPC 接入 etcdv3

https://forum.rentsoft.cn/thr…

【OpenIM 原创】简略轻松入门 一文解说 WebRTC 实现 1 对 1 音视频通信原理

https://forum.rentsoft.cn/thr…

【OpenIM 原创】C/C++ 调用 golang 函数，golang 回调 C /C++ 函数

https://forum.rentsoft.cn/thr…