00:00
全面揭秘以及即时通讯I'M消息的可靠投递机制作者融云技术团队剪辑即时通讯网即时通讯IM系统最基础、最重要的是消息的及时性与准确性,即时体现在延迟,准确则具体表现为不丢、不中、不乱续。综合考虑业务场景、系统复杂度、网络流量、终端能耗的我们立即分布式I'M消息系统精心设计了消息收发机制,并不断打磨优化,形成了现在的消息可靠投递机制等。根据融云一级I'M消息系统的技术实践总结分布式I'M消息的可靠投递机制,希望能为你的I'M开发和知识学习起到抛砖引玉的作用。一客户端与服务端消息交互原理上行,一个完整的I'M消息交互逻辑通常会为两段,消息上行段和消息下行段。消息上行段主要就是依赖I'M的实时通道将消息传递给服务端,这个阶段的消息可靠投递需要从协议层进行保证,协议层需要提供可靠有序的双向字节流传输。我们是通过自研的通信协议实现的,客户端与服务端之间使用长连接,基于私有协议传输数据。客户端与服务端消息交互原理下行,消息下行段主要有三种行为,客户端主动拉取消息,服务端主动发送消息,只发消息和服务端主动发送通知,通知拉取。客户端主动拉取消息有两个触发方式,拉取离线消息和定时拉取消息,服务端主动发送消息。直发消息是在线消息发送机制之一,简单理解为服务端将消息内容直接发。
01:44
发送给客户端适用于消息频率较低并且持续交互,比如二人或者群内的正常交流讨论。服务端主动发送通知。通知拉取也是在线消息发送机制之一,简单理解为服务端给客户端发送一个通知,通知包含时间抽等可作为排序索引的内容。客户端收到通知后,依据自身数据对比通知内时间戳发起拉取消息的流程。这种场景适用于较多消息传递,比如某人有很多大规模的群,每个群内都有很多成员正在激烈讨论。通过通知拉取机制,可以有效的减少客户端、服务端网络交互次数,并且对多条消息进行打包,提升有效数据在和,既能保证时效又能保证性能。3客户端与服务端消息交互上行,我们将消息的交互流程进行了拆分,及拆分出上下行,在上行过程保证发送消息的顺序。为了保证。
02:44
消息有序最好的方式是按照user ID区分,然后使用时间抽排序。那么分布式部署情况下,将用户归属到固定的业务服务器上指的是同一账号的不同端固定连接到相同的业务服务器上会使得上行排序变得更容易同时归属到同一个服务器,在多端维护时也更容易。小结一下就是客户端发出消息后,通过接入服务按照UCID投递到指定消息服务器,生成消息ID,依据最后一条消息时间确认更新当前消息的时间戳,如果存在相同时间戳则后延,然后将时间戳以及消息ID通过I返回给客户端,然后对上行消息使用UCID加时间戳进行缓存以及持久化存储,后续业务操作均使用此时间戳。以上业务流程我们称为上行流程,上行过程存储的消息为发件箱消息。
03:43
4客户端与服务端消息交互下行消息节点在处理完上行流程后,消息按照目标用户投递到所在消息节点进入下行流程。下行过程按照目标UID以及本消息在上行过程中生成的时间计算是否需要更新时间戳正向,如果需要更新,则对时间戳进行加法操作,直到当前用户时间戳不重复。如此处理后,目标用户的存储以及客户端接收到消息后的牌中可以做到一致,并且可以做到同一个会话内的时间戳是有序的,从而保证同一个接收用户的消息不会出现乱序。五、多端在线的消息同步发送方多端同步多端同步按照消息的上下行两个阶段同样区分为发送方多端同步以及接收方多端同步。在前面客户端连接应服务过程中,我们已经将同一个用户的多个客户端汇聚在了同一台服。
04:43
服务,那么维护一个UCIID的多端就会变得很简单。具体逻辑是,用户多个终端链接成功后,发送一条消息,这个消息到达CPIN'接入服务后,CP做基础检查,然后获此用户的其终端连接服务,把客户端上行的消息封装为服务端下行消息,直接投递给用户的其他客户端,这样完成了发送方的多端抄送,然后将这条消息投递到I'M服务,进入正常发送投递流程。发送方的多端同步没有经过I'm server, 这么做的好处是比较快速,且经过越少的服务节点,出问题的几率越小。六、多端在线的消息同步接收方多端同步接收方多端消息同步的具体逻辑是,应服务收到消息后,先判断接收方的投递范围,这个范围指的是接收方用户,但哪些的终端要接收消息,应服务将范围以及当前消息发送到CPCP依据。
05:43
范围匹配接收方的终端,然后投递消息。接收方多端消息同步范围的应用场景一般都是针对所有终端,带有一些特殊业务,比如我在A客户端上控制另外某个端的状态,可能需要一些命令消息,这时候需要这个作用范围针对性的投递消息。到此,我们分享完了有关I'M消息核心处理流程,通过层层拆解逻辑,提供了可靠的消息投递机制。
我来说两句