IM即时通讯开发可靠的亿级IM消息投递机制

Posted 2022-07-12 wecloud1314

即时通讯（IM）系统最基础、最重要的是消息的及时性与准确性，及时体现在延迟，准确则具体表现为不丢、不重、不乱序。

综合考虑业务场景、系统复杂度、网络流量、终端能耗等，我们的亿级分布式IM消息系统精心设计了消息收发机制，并不断打磨优化，形成了现在的消息可靠投递机制。

整体思路就是：

    1）客户端、服务端共同配合，互相补充；

    2）采用多重机制，从不同层面保障；

    3）拆分上下行，分别处理。

一个完整的IM消息交互逻辑，通常会为两段：

    1）消息上行段：即由消息发送者通过IM实时通道发送给服务端；

    2）消息下行段：由服务端按照一定的策略送达给最终的消息接收人。

消息上行段主要就是依赖IM的实时通道将消息传递给服务端。

这个阶段的消息可靠投递，需要从协议层进行保证，协议层需要提供可靠、有序的双向字节流传输，我们是通过自研的通信协议 RMTP（即 RongCloud Message Transfer Protocol）实现的。

客户端与服务端之间使用长连接，基于 RMTP 协议传输数据。

经过总结，消息下行段主要有三种行为。

1）客户端主动拉取消息，主动拉取有两个触发方式：

    ① 拉取离线消息：与 IM 服务新建立连接成功，用于获取不在线的这段时间未收到的消息；

    ② 定时拉取消息：在客户端最后收到消息后启动定时器，比如 3-5 分钟执行一次。主要有两个目的，一个是用于防止因网络、中间设备等不确定因素引起的通知送达失败，服务端客户端状态不一致，一个是可通过本次请求，对业务层做状态机保活。

2）服务端主动-发送消息（直发消息）：

这是在线消息发送机制之一，简单理解为服务端将消息内容直接发送给客户端，适用于消息频率较低，并且持续交互，比如二人或者群内的正常交流讨论。

3）服务端主动-发送通知（通知拉取）：

这是在线消息发送机制之一，简单理解为服务端给客户端发送一个通知，通知包含时间戳等可作为排序索引的内容，客户端收到通知后，依据自身数据，对比通知内时间戳，发起拉取消息的流程。

这种场景适用于较多消息传递：比如某人有很多大规模的群，每个群内都有很多成员正在激烈讨论。通过通知拉取机制，可以有效的减少客户端服务端网络交互次数，并且对多条消息进行打包，提升有效数据载荷。既能保证时效，又能保证性能。

在上行过程保证发送消息顺序，为了保证消息有序， 最好的方式是按照 userId 区分，然后使用时间戳排序。那么分布式部署情况下，将用户归属到固定的业务服务器上（PS：指的是同一账号的不同端固定连接到相同的业务服务器上），会使得上行排序变得更容易。同时归属到同一个服务器，在多端维护时也更容易。

客户端连接过程：

    1）客户端通过 APP server ，获取到连接使用的 token；

    2）客户端使用 token 通过导航服务，获取具体连接的 IM 接入服务器(CMP)，导航服务通过 userId 计算接入服务器，然后下发，使得某一客户端可以连接在同一台接入服务器(CMP)。

小结一下就是：客户端发出消息后，通过接入服务，按照 userId 投递到指定消息服务器，生成消息 Id， 依据最后一条消息时间，确认更新当前消息的时间戳（如果存在相同时间戳则后延）。然后将时间戳，以及消息 Id，通过 Ack 返回给客户端 ; 然后对上行消息使用 userId + 时间戳进行缓存以及持久化存储，后续业务操作均使用此时间戳。

消息节点在处理完上行流程后，消息按照目标用户投递到所在消息节点，进入下行流程。

下行过程，按照目标 userId 以及本消息在上行过程中生成的时间戳，计算是否需要更新时间戳（正向）。

如果需要更新则对时间戳进行加法操作，直到当前用户时间戳不重复。

如此处理后，目标用户的存储以及客户端接收到消息后的排重可以做到一致，并且可以做到同一个会话内的时间戳是有序的。从而保证同一个接收用户的消息不会出现乱序。

至此：我们已经介绍完了消息的下行交互过程，消息下行过程中的具体实现方式并不简单，以下将详细展开。

1）直发消息：

即服务端主动发送（给目标客户端）的消息：

    1）客户端 SDK 依据本地存储的最新消息时间戳判断，用来做排序等逻辑；

    2）对同一个用户直发消息1条，其他转通知。通知拉取时候客户端选择本地最新一条消息时间戳作为开始拉取时间；

    3）在消息发送过程中，如果上一条消息发送流程未结束，下一条消息则不用直发(s_msg)，而是用通知(s_ntf)。

即服务端主动发送通知（给目标客户端）：

    1）服务端在通知体中携带当前消息时间戳。投递给客户端；

    2）客户端收到通知后，比对本地消息时间戳，选择是否发拉取消息信令；

    3）服务端收到拉取消息信令后，以信令携带的时间戳为开始，查询出消息列表(200 条或者 5M)，并给客户端应答；

    4）客户端收到后，给服务端 ack，服务端维护状态；

    5）客户端拉取消息时使用的时间戳，是客户端本地最新一条消息的时间戳。

具体逻辑是：

    1）用户多个终端链接成功后，发送一条消息，这个消息到达 CMP(IM 接入服务) 后，CMP 做基础检查，然后获此用户的其他终端连接；

    2）服务把客户端上行的消息，封装为服务端下行消息，直接投递给用户的其他客户端。这样完成了发送方的多端抄送，然后将这条消息投递到 IM 服务。进入正常发送投递流程。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

针对上面的第2）点，发送方的多端同步没有经过 IM Server，这么做的好处是：

    1）比较快速；

    2）经过越少的服务节点，出问题的几率越小。

接收方多端同步

具体逻辑是：

    1）IM 服务收到消息后，先判断接收方的投递范围，这个范围指的是接收方用户的哪些的终端要接收消息；

    2）IM 服务将范围以及当前消息，发送到 CMP，CMP 依据范围，匹配接收方的终端，然后投递消息。

接收方多端消息同步范围的应用场景，一般都是针对所有终端。

但有一些特殊业务：比如我在 A 客户端上，控制另外某个端的状态，可能需要一些命令消息， 这时候需要这个作用范围，针对性的投递消息。