向消息延迟说bybye：闲鱼消息及时到达筹划（具体）

面临哪些问题端内长连接中断

在IM场景中，用户与云端通信频繁，且为了实现用户的及时到达，每每采取云端下推的办法触达用户，以是用户在线时设备与云端会坚持一条TCP长连接通道，可以更轻量级的与做事端进行交互，当代IM即时通讯的下行都是通过长连下发的，闲鱼利用的是ACCS长连接，ACCS是淘宝无线供应的全双工、低延时、高安全的通道做事。

但是由于用户设备网络状态的不愿定性，可能会发生各种各样的网络非常情形导致长连接通道中断，长连接一旦意外中断，就会导致用户无法及时收到在线，以是我们须要尽可能及时的感知到长连中断并考试测验重连。

下推的未达

感知长连中断并重连只能在大多数韶光担保长连接的有效性，但是在长连接无效或不稳定期间下推的客户端可能根本收不到，大略说便是仅仅有重连机制无法担保下行必达，可能有以了局景导致下行失落败：

做事端发送下行时长连畅通，在传输路上通道断掉，客户端无法收到

设备的在线状态存在延迟，做事端下行时认为设备在线，实际上设备已经离线，无法收到

客户端收到了下行，但端上后续处理失落败，比如落库失落败，没有成功展示给用户

我们通过数据埋点统计得出，accs下行成功率在97%旁边

有心急的同学就要问了，丢了3%的吗？并没有，这3%的不会丢失，只是不担保及时触达给用户。
我们的同步模型是推拉结合模式，在用户拉取消息时会拉取到设备当前位点与做事端最新位点的所有，accs下行失落败的会通过主动拉模式获取到，但客户端主动拉取消息的触发机遇有限，紧张有以下几个：

用户冷启动app，主动同步

用户主动下拉刷新

app后台切换前台

收到一条推送，客户端创造新的位点跟本地最新的位点有gap，触发同步

可见上述主动同步的触发很大程度上依赖用户行为或者有没有收到新，难以担保及时到达。
如果是用户高频打开的IM软件，这样也不会有太大的问题，但是闲鱼app的生动度较低，有时候乃至依赖IM拉活，而且一条延迟的触达可能导致用户错过一笔交易，闲鱼不许可有这样的延迟发生。
基于上述剖析，我们先描述一个数据指标来反响现状，通过上面的描述可知，accs并不全都是推下来的，也可能是主动拉下来的，如果是推，必定可以及时到达，如果是拉，则受限于用户行为。
拉的这部分，我们定义为accs补偿到达，然后打算accs补偿到达耗时，范围限定为做事端accs成功下行但是客户端通过主动拉取同步到的，以往的版本这个数据在60分钟旁边。
须要把稳这个数据并不是触达到用户的耗时，由于如果在线转离线触达，拉取到的韶光取决于用户行为(用户何时打开了app)，但这个数据也能大致反响在线的到达延迟状况。

接下来本文将从长连接的重连和未达重发两个方面详细讲述我们是如何优化在线通道稳定性的。

长连接重连长连接为什么会中断？

百因必有果，我们先来剖析下有哪些缘故原由会导致连接中断，可能有以下缘故原由：

用户设备断网

设备发生了网络切换

设备处于弱网环境，网络不稳定

设备网络正常，TCP连接由于NAT超时导致连接被运营商中断

如果是用户操作导致网络状态变革的情形，会有网络状态变革事宜关照，这种情形可以监听事宜并主动考试测验重连，但现实中的大多数情形都是“猜想之外”。
那么如何有效感知到各种非常状况呢？

心跳检测

像大多数探活场景一样，最有效的检测手段便是心跳检测，客户端通过定时发送心跳包，可以感知到连接中断，从及时性效果来看，心跳间隔越短越好，而频繁的心跳检测势必会带来用户流量以及电量的损耗，以是我们的目标是如何尽可能少的心跳检测而又只管即便及时地感知到长连中断的意外情形。

状态机+心跳行列步队：

在心跳协议设计上，要把稳心跳包的核心目标是检测长连通道是否畅通，客户端主动上行心跳包且能收到做事端回包，就认为长连通道康健，以是上行以及回包的数据包应尽可能小，一样平常来说，通过协议头标识心跳包及相应即可

心跳策略

心跳策略是实现我们上述目标的核心机制，但关于心跳策略的详细设计乃至可以单独写一篇文章，本文仅大略列举几种心跳策略，有兴趣的同学可以阅读文末推举的文章连续深入研究。

短心跳检测 初始状态连续 ping 3次 收到 ack 后，可以认为进入稳定状态

常规固定时长心跳（根据app状态不同，频率可调Mid+,Mid-, Long)

自适应心跳 根据设备网络状态变革自动适应的心跳间隔

冗余心跳，app后台切前台，主动心跳一次

ack与重发

为理解决上面的问题，引入ack与重发机制，整体思路是客户端在收到accs并处理成功后，给做事端回一个ack，做事端下行accs时将加入重试行列步队，收到ack后更新到达状态，并终止重试。

整体设计流程图：

该方案的难点即重试处理器的实现设计，接下来我们将重点讲述这部分的详细设计

重试行列步队存储设计

我们采取阿里云表格存储TimeLine模型来存储下行的到达状态，阿里云表格存储是阿里云自研的多模型构造化数据存储，供应海量构造化数据存储以及快速的查询和剖析做事。
表格存储的分布式存储和强大的索引引擎能够支持PB级存储、千万TPS以及毫秒级延迟的做事能力。
而Timeline 模型是针对数据场景所设计的数据模型，它能知够数据场景对保序、海量存储、实时同步的分外需求，在IM、Feed流等场景运用广泛。

我们给每个用户设备定义一个TimeLine，timeline-id定义为userId_deviceId，sequenceId自定义为位点，存储构造如下：

每通过accs成功下行一条，则插入到吸收用户设备的TimeLine中，收到ack后根据id更新到达状态，同时由于重试动作只发生不才行后较短的一段韶光内，以是我们设置一个比较短的全局过期韶光即可，避免数据膨胀。

延迟重试设计

1）每通过accs下发一条，先插入到Timeline中，初始状态为未达，然后生产一条延迟N秒的延迟

2）每次消费到延迟后，读取tablestore中该的到达状态，如到达则终止延迟，否则连续

3）每次重试先判断设备是否在线，如果设备不在线，转发离线通道并终止重试，如果设备在线，则重推未到达的，并再次延迟N秒消费

4）每条的重试生命周期中用的同一条延迟，最多重试消费M次，超过次数不再重试并打日志埋点，后续可以监控这种情形并基于这个数据进行优化

延迟重发策略

延迟重发策略是指在重发流程中，如何选择得当的延迟韶光来使得重发的效率最高。
不同用户在不同韶光、地点所处的网络环境差别较大，网络规复到稳定态所须要的韶光也有差异，须要选用得当的延迟策略来担保重发效率，最优的延迟策略的目标是在最短的韶光内，利用最少的重发次数将投递成功。

固定延迟韶光

要想找到最优的延迟策略，必须从数据中通过剖析得到答案，天马行空的想象每每离实际相差甚远，我们先采取固定的延迟韶光(10s)最大重试6次来剖析一波数据

我们通过这组数据可以看到，有约85%的在40s内重发可以投递成功，还有12%的在达到最大重试次数后依旧没有收到ack，在4次重试之后，第5次成功只有2.03%，第6次只有0.92%，连续重发的收益已经变得很低，6次往后还有部分没有收到ack，这部分如果用固定延迟韶光策略，性价比很低，频繁重发摧残浪费蹂躏系统资源，我们连续改进策略。

固定延迟+固定步长递增

考虑到部分用户的网络短韶光无法规复，频繁的短间隔重发代价不大，我们采取4次固定短间隔延迟N秒后，之后每次延迟韶光都是上一次延迟韶光递增固定步长M秒的策略，直到收到ack、用户设备离线或者达到了最大延迟韶光MAX(N)。
这种策略一定程度上可以办理固定延迟韶光重发策略的问题，但如果用户短韶光网络无法规复，每次重发都要重新递增，也不是一种最优解。

自适应延迟

设计流程图：

如上图，我们终极衍生出了自适应延迟策略，自适应延迟是指根据用户的网络状况，采纳自动调度的延迟韶光，以期望达到最高的重发效率，新先通过4次固定N秒的短延迟来探测设备的网络状况，一旦网络规复，我们将设备的N值清空，设备N值是指根据上几次重发履历，当前设备网络能回答ack所须要的最短韶光，默认情形该值为空，代表用户设备网络正常。
4次重发后依旧收不到ack，我们考试测验读取设备N值，如果为空，则取初始值，往后每次延迟都递增固定步长M，并在重发后更新当前设备的N值，直到收到ack或者达到了最大延迟韶光MAX(N)。

新老版本兼容性

须要把稳的是老版本的app是不会回ack的，如果下发给老版本设备的也加入重试行列步队，那此类将一贯重试到最大次数才会终止，无端花费资源，以是我们设计在accs长连建立之后，客户端主动上行一条设备信息，个中包含app的版本号，做事端存储一定韶光，在将加入重试行列步队之前，先校验吸收者设备app的版本号，符合哀求再加入重试行列步队。

方案效果

重连重发方案上线后，我们上面定义的指标accs补偿到达韶光从60分钟大幅降落至15分钟，降幅达75%，从而印证了我们的技能剖析，同时用户有关延迟的舆情反馈每周不超过2个，可见重发机制对担保用户及时到达成效显著。

未来展望

在线通道稳定性优化至此已告一段落，未来我们将连续优化闲鱼的利用体验，包括根本功能的完善以及根本体验的提升。

根本功能方面，我们在近期的版本中已经支持了撤回、草稿功能，后续将逐步支持发送定位，会话分组、备注，搜索等功能；

根本体验方面，我们对闲鱼的UI样式做了优化升级，并优化了apptab页的cpu及内存利用，后续将连续从流量、电量、性能方面连续优化的利用体验。

References

[1]当代IM系统中的系统架构 - 架构篇:https://developer.aliyun.com/article/698301

[2]当代IM系统中的系统架构 - 模型篇:https://developer.aliyun.com/article/701593

[3]高并发IM系统架构优化实践:https://developer.aliyun.com/article/66461

闲不住？来闲鱼！

PICK ME

闲鱼技能团队通过创新追寻更多代价，不断驱动业务变革。

从闲置买卖的老本行，到打造“无忧购”“会玩社区““新线下”，

从出版书本、峰会发声，到开源专利、海外传播，

闲不住，上闲鱼——技能团队对极致的探索与深耕是我们的底气。

立即加入

1、招客户端/做事端/前端/架构/质量工程师

2、发简历给guicai.gxy@alibaba-inc.com

3、您还可以在头条、知乎、掘金、facebook、twitter找到我们