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（或者time）
t_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