IM消息送达保证机制实现

一、保证在线实时消息的可靠投递

1.报文类型

报文分为三种:
这里写图片描述
请求报文(request,后简称为为R);
应答报文(acknowledge,后简称为A);
通知报文(notify,后简称为N)。
这三种报文的解释如下:

R:客户端主动发送给服务器的报文
A:服务器被动应答客户端的报文,一个A一定对应一个R
N:服务器主动发送给客户端的报文

2.普通消息投递流程
用户A给用户B发送一个“你好”,很容易想到,流程如下:
这里写图片描述
client-A向im-server发送一个消息请求包,即msg:R
im-server在成功处理后,回复client-A一个消息响应包,即msg:A
如果此时client-B在线,则im-server主动向client-B发送一个消息通知包,即msg:N(当然,如果client-B不在线,则消息会存储离线)

可能出现的问题:
从流程图中容易看到,发送方client-A收到msg:A后,只能说明im-server成功接收到了消息,并不能说明client-B接收到了消息。在若干场景下,可能出现msg:N包丢失,且发送方client-A完全不知道,例如:

服务器崩溃,msg:N包未发出
网络抖动,msg:N包被网络设备丢弃
client-B崩溃,msg:N包未接收

结论是悲观的:接收方client-B是否有收到msg:N,发送方client-A完全不可控,那怎么办呢?

3.应用层确认+im消息可靠投递的六个报文

要想实现应用层的消息可靠投递,必须加入应用层的确认机制,即:要想让发送方client-A确保接收方client-B收到了消息,必须让接收方client-B给一个消息的确认,这个应用层的确认的流程,与消息的发送流程类似:

client-B向im-server发送一个ack请求包,即ack:R
im-server在成功处理后,回复client-B一个ack响应包,即ack:A
则im-server主动向client-A发送一个ack通知包,即ack:N

至此,发送“你好”的client-A,在收到了ack:N报文后,才能确认client-B真正接收到了“你好”。

你会发现,一条消息的发送,分别包含(上)(下)两个半场,即msg的R/A/N三个报文,ack的R/A/N三个报文。一个应用层即时通讯消息的可靠投递,共涉及6个报文,这就是im系统中消息投递的最核心技术(如果某个im系统不包含这6个报文,不要谈什么消息的可靠性)。

存在什么问题:
期望六个报文完成消息的可靠投递,但实际情况下:

msg:R,msg:A 报文可能丢失:
此时直接提示“发送失败”即可,问题不大;
msg:N,ack:R,ack:A,ack:N这四个报文都可能丢失:
(原因如第二章所述,可能是服务器奔溃、网络抖动、或者客户端奔溃),此时client-A都收不到期待的ack:N报文,即client-A不能确认client-B是否收到“你好”。

那怎么办呢?

4.消息的超时与重传

client-A发出了msg:R,收到了msg:A之后,在一个期待的时间内,如果没有收到ack:N,client-A会尝试将msg:R重发。可能client-A同时发出了很多消息,故client-A需要在本地维护一个等待ack队列,并配合timer超时机制,来记录哪些消息没有收到ack:N,以定时重发。
这里写图片描述

重传存在什么问题:
msg:N报文,ack:N报文都有可能丢失:

msg:N 报文丢失:说明client-B之前压根没有收到“你好”报文,超时与重传机制十分有效
ack:N 报文丢失:说明client-B之前已经收到了“你好”报文(只是client-A不知道而已),超时与重传机制将导致client-B收到重复的消息。

5.消息的去重

解决方法也很简单,由发送方client-A生成一个消息去重的msgid,保存在“等待ack队列”里,同一条消息使用相同的msgid来重传,供client-B去重,而不影响用户体验。

6.小结

1)im系统是通过超时、重传、确认、去重的机制来保证消息的可靠投递,不丢不重;
2)切记,一个“你好”的发送,包含上半场msg:R/A/N与下半场ack:R/A/N的6个报文。

二、保证离线消息的可靠投递

1.消息接收方不在线时的典型消息发送流程

这里写图片描述
如上图所述,通常此类情况下消息的发送流程如下:

Step 1:用户A发送一条消息给用户B;
Step 2:服务器查看用户B的状态,发现B的状态为“offline”(即B当前不在线);
Step 3:服务器将此条消息以离线消息的形式持久化存储到DB中(当然,具体的持久化方案可由您IM的具体技术实现为准);
Step 4:服务器返回用户A“发送成功”ACK确认包(注:对于消息发送方而言,消息一旦落地存储至DB就认为是发送成功了)。

2.拉取离线消息的过程

a.如果用户B有很多好友,登陆时客户端需要对所有好友进行离线消息拉取
为了避免逐个拉取效率低下,可向服务器一次拉取所有好友发送给用户B的离线消息,到客户端本地再根据sender_uid进行计算,这样的话,离校消息表的访问模式就变为->只需要按照receiver_uid来查询了。登录时与服务器的交互次数降低为了1次。
为了避免一次拉取卡慢,可以分页拉取:根据业务需求,先拉取最新(或者最旧)的一页消息,再按需一页页拉取。

b.如同在线消息的应用层ACK机制一样,离线消息拉时,不能够直接删除数据库中的离线消息,而必须等应用层的离线消息ACK(说明用户B真的收到离线消息了),才能删除数据库中的离线消息。这个应用层的ACK可以通过实时消息通道告之服务端,也可以通过服务端提供的REST接口,以更通用、简单的方式通知服务端。
这里不用每一页消息都ACK,在拉取第二页消息时相当于第一页消息的ACK,此时服务器再删除第一页的离线消息即可,最后一页消息再ACK一次(实际上:最后一页拉取的肯定是空返回,这样可以极大地简化这个分页过程,否则客户端得知道当前离线消息的总页数,而由于消息读取延迟的存在,这个总页数理论上并非绝对不变,从而加大了数据读取不一致的可能性)。这样的效果是,不管拉取多少页离线消息,只会多一个ACK请求,与服务器多一次交互

3.小结

正如本文中所列举的问题所描述的那样,保证“离线消息”的可达性比大家想象的要复杂一些,常见优化总结如下:

1)对于同一个用户B,一次性拉取所有用户发给ta的离线消息,再在客户端本地进行发送方分析,相比按照发送方一个个进行消息拉取,能大大减少服务器交互次数;
2)分页拉取,先拉取计数再按需拉取,是无线端的常见优化;
3)应用层的ACK,应用层的去重,才能保证离线消息的不丢不重;
4)下一页的拉取,同时作为上一页的ACK,能够极大减少与服务器的交互次数。

三、IM群聊离线消息如何保证不丢不重

系统架构简介:
1)客户端:x,A,B,C,D共5个客户端用户;
2)服务端:
2.1)所有模块与服务抽象为server;
2.2)所有用户在线状态抽象存储在高可用cache里;
2.3)所有数据信息,例如群成员、群离线消息抽象存储在db里
这里写图片描述
典型群消息投递流程,如上图步骤1-4所述:

步骤1:群消息发送者x向server发出群消息;
步骤2:server去db中查询群中有多少用户(x,A,B,C,D);
步骤3:server去cache中查询这些用户的在线状态;
步骤4:对于群中在线的用户A与B,群消息server进行实时推送;
步骤5:对于群中离线的用户C与D,群消息server进行离线存储。

这里重点讲离线的处理
典型的群离线消息拉取流程:
步骤1:离线消息拉取者C向server拉取群离线消息;
步骤2:server从群消息表中根据拉取last_msgId之后的msg并返回群用户C;
步骤3:server根据ACK从db中更新群用户C的last_msgId

为什么不专门建一个离线消息表
其实,对于一个群用户,在ta登出后的离线期间内,肯定是所有的群消息都没有收到的,完全不用对所有的每一条离线消息存储一个离线msg_id,而只需要存储最近一条拉取到的离线消息的time(或者msg_id),下次登录时拉取在那之后的所有群消息即可,而完全没有必要存储每个人未拉取到的离线消息msg_id,db表结构如下:

群成员表:用来描述一个群里有多少成员,以及每个成员最后一条ack的群消息的msg_id(或者timet_group_users(group_id, user_id, last_ack_msg_id(last_ack_msg_time))
群消息表:用来存储一个群中所有的消息内容
t_group_msgs(group_id, sender_id, time,msg_id, msg_detail)

实现思路:
1.任何一个群用户发送的消息,都存储到群消息表msg_detail
2.在线的用户A和B在应用层ACK后,将群成员表的对应last_ack_msg_id更新即可
3.离线用户登录后,按last_ack_msg_id从msg_detail中拉取最新的消息

关于应用层ACK的优化:
由于“消息风暴扩散系数”的存在,假设1个群有500个用户,“每条”群消息都会变为500个应用层ACK,将对服务器造成巨大的冲击
这里,有两种方案:
1)每收到N条群消息ACK一次,这样请求量就降低为原来的1/N了;
2)每隔时间间隔T进行一次群消息ACK,也能达到类似的效果。
至于群离线消息过多,拉取过慢,同理使用分页读取就是了。

小结
1)不管是群在线消息,还是群离线消息,应用层的ACK是可达性的保障;
2)群消息只存一份,不用为每个用户存储离线群msg_id,只需存储一个最近ack的群消息id/time;
3)为了减少消息风暴,可以批量ACK;
4)如果收到重复消息,需要msg_id去重,让用户无感知;
5)离线消息过多,可以分页拉取(按需拉取)优化。

四、IM单聊和群聊中的在线状态同步

“用户在线状态的一致性”(单聊好友在线状态、群聊用户在线状态)是IM应用领域比较难解决的一个技术问题

1.用户uid-A登录时,如何获取自己全部好友的在线状态

1)服务器要存储所有用户的在线状态(往往存储在保证高可用的缓存集群里) -> 保证状态可查
2)用户状态实时变更,任何用户登录时,需要将服务端自己的在线状态置为online;任何用户登出时,需要将服务端自己的状态置为offline -> 保证服务端状态存储的一致性与实时性
3)uid-A登录时,先去数据库拉取自己的好友列表,再去缓存获取所有好友的在线状态 -> 保证登录时好友状态获取的一致性与实时性,如图:
这里写图片描述

2.用户uid-A的好友uid-B状态改变时(由登录、登出、隐身等动作触发),uid-A如何知道这一事件

uid-B状态改变时(由登录、登出、隐身等动作触发),服务器不仅在缓存中修改uid-B的状态,还要将这个状体改变的通知推送给uid-B的在线反向好友(反向好友是指:加了uid-B为好友的人,而不是uid-B的好友,这个细节要注意)

3.保持群聊友状态的一致性

群友状态一般都是采用拉取的方式获得,因为群友状态“消息风暴扩散系数”N实在太大,全部实时获取系统往往承受不了。
用户实际上并不会每次登录都进入每一个群。不采用轮询拉取,而采用按需拉取,延时拉取的方式,在真正进入一个群时才实时拉取群友的在线状态,是既能满足用户需求(用户感觉是状态是实时、一致的,但其实是进入群才拉取的),又能降低服务器压力。这是一种常见方法。

摘录:
http://www.52im.net/thread-294-1-1.html

展开阅读全文

没有更多推荐了,返回首页