IM消息送达保证机制实现(二):保证离线消息的可靠投递

1、前言

本文的上篇《IM消息送达保证机制实现(一):保证在线实时消息的可靠投递》中,我们讨论了在线实时消息的投递可以通过应用层的确认、发送方的超时重传、接收方的去重等手段来保证业务层面消息的不丢不重。

但实时在线投递针对的是消息收发双方都在线的情况(如当发送方用户A发送消息给接收方用户B时,用户B是在线的),那如果消息的接收方用户B不在线,系统是如何保证消息的可达性的呢?这就是本文要讨论的问题。(本文同步发布于:http://www.52im.net/thread-59...

2、学习交流

3、IM消息送达保证系列文章

本文是讨论IM消息送达保证系列文章中的第2篇,总目录如下:

IM消息送达保证机制实现(一):保证在线实时消息的可靠投递
IM消息送达保证机制实现(二):保证离线消息的可靠投递》(本文)

另外,如果您正在查阅移动端IM开发资料,推荐阅读《新手入门一篇就够:从零开发移动端IM》。

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

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

Step 1:用户A发送一条消息给用户B;

Step 2:服务器查看用户B的状态,发现B的状态为“offline”(即B当前不在线);

Step 3:服务器将此条消息以离线消息的形式持久化存储到DB中(当然,具体的持久化方案可由您IM的具体技术实现为准);

Step 4:服务器返回用户A“发送成功”ACK确认包(注:对于消息发送方而言,消息一旦落地存储至DB就认为是发送成功了)。

关于 “Step 4” 的补充说明:

请一定要理解“Step 4”,因为现在无论是传统的PC端IM(类似QQ这样的——可以在UI上看到好友的在线、离线状态)还是目前主流的移动端IM(强调的是用户全时在线——即你看不到好友到底在线还是离线,反正给你的假像就是这个好友“应该”是在线的),消息发送出去后,无论是对方实时在线收到还是对方不在线而被服务端离线存储了,对于发送方而言只要消息没有因为网络等原因莫名消失,就应该认为是“被收到了”。

从技术的角度讲,消息接收方收到的消息应答ACK包的真正发起者,实际上有两种可能性:一种是由接收方发出、而另一种是由服务端代为发送(这在MobileIMSDK开源工程里被称作“伪应答”)。

5、典型离线消息表的设计以及拉取离线消息的过程

① 存储离线消看书的表主要字段大致如下:

-- 消息接收者ID

receiver_uidvarchar(50),

-- 消息的唯一指纹码(即消息ID),用于去重等场景

msg_idvarchar(70),

-- 消息发出时的时间戳(如果是个跨国IM,则此时间戳可能是GMT-0标准时间)

send_timetime,

-- 消息发送者ID

sender_uidvarchar(50),

-- 消息类型(标识此条消息是:文本、图片还是语音留言等)

msg_typeint,

-- 消息内容(如果是图片或语音留言等类型,由此字段存放的可能是对应文件的存储地址或CDN的访问URL)

msg_contentvarchar(1024),

…

② 离线消息拉取模式:

接收方B要拉取发送方A给ta发送的离线消息,只需在receiver_uid(即接收方B的用户ID), sender_uid(即发送方A的用户ID)上查询,然后把离线消息删除,再把消息返回B即可。

③ 离线消息的拉取,如果用SQL语句来描述的话,它可以是:

SELECT msg_id, send_time, msg_type, msg_content FROM offline_msgs WHERE receiver_uid = ? and sender_uid = ?

④ 离线拉取的整体流程如下图所示:

Step 1:用户B开始拉取用户A发送给ta的离线消息;

Step 2:服务器从DB(或对应的持久化容器)中拉取离线消息;

Step 3:服务器从DB(或对应的持久化容器)中把离线消息删除;

Step 4:服务器返回给用户B想要的离线消息。

6、上述流程存在的问题以及优化方案

如果用户B有很多好友,登陆时客户端需要对所有好友进行离线消息拉取,客户端与服务器交互次数就会比较多。

① 拉取好友离线消息的客户端伪代码:

// 登陆时所有好友都要拉取

for(all uid in B’s friend-list){

      // 与服务器交互

     get_offline_msg(B,uid);

}

② 优化方案1:

先拉取各个好友的离线消息数量,真正用户B进去看离线消息时,才往服务器发送拉取请求(手机端为了节省流量,经常会使用这个按需拉取的优化)。

③ 优化方案2:

如下图所示,一次性拉取所有好友发送给用户B的离线消息,到客户端本地再根据sender_uid进行计算,这样的话,离校消息表的访问模式就变为->只需要按照receiver_uid来查询了。登录时与服务器的交互次数降低为了1次。

④ 方案小结:

通常情况下,主流的的移动端IM(比如微信、手Q等)通常都是以“优化方案2”为主,因为移动网络的不可靠性加上电量、流量等资源的昂贵性,能尽量一次性干完的事,就尽可能一次搞定,从而提供整个APP的用户体验(对于移动端应用而言,省电、省流量同样是用户体验的一部分)。这方面的文章,可以进一步参阅《谈谈移动端 IM 开发中登录请求的优化》、《移动端IM实践:iOS版微信界面卡顿监测方案》、《移动端IM实践:Android版微信如何大幅提升交互性能(二)》。

7、消息接收方一次拉取大量离线消息导致速度慢、卡顿的解决方法

用户B一次性拉取所有好友发给ta的离线消息,消息量很大时,一个请求包很大、速度慢,容易卡顿怎么办?

正如上图所示,我们可以分页拉取:根据业务需求,先拉取最新(或者最旧)的一页消息,再按需一页页拉取,这样便能很好地解决用户体验问题。

8、优化离线消息的拉取过程,保证离线消息不会丢失

如何保证可达性,上述步骤第三步执行完毕之后,第四个步骤离线消息返回给客户端过程中,服务器挂点,路由器丢消息,或者客户端crash了,那离线消息岂不是丢了么(数据库已删除,用户还没收到)?

确实,如果按照上述的1、2、3、4步流程,的确是的,那如何保证离线消息的绝对可靠性、可达性?

如同在线消息的应用层ACK机制一样,离线消息拉时,不能够直接删除数据库中的离线消息,而必须等应用层的离线消息ACK(说明用户B真的收到离线消息了),才能删除数据库中的离线消息。这个应用层的ACK可以通过实时消息通道告之服务端,也可以通过服务端提供的REST接口,以更通用、简单的方式通知服务端。

9、进一步优化,解决重复拉取离线消息的问题

如果用户B拉取了一页离线消息,却在ACK之前crash了,下次登录时会拉取到重复的离线消息么?

确实,拉取了离线消息却没有ACK,服务器不会删除之前的离线消息,故下次登录时系统层面还会拉取到。但在业务层面,可以根据msg_id去重。SMC理论:系统层面无法做到消息不丢不重,业务层面可以做到,对用户无感知。

优化后的拉取过程,如下图所示:

10、进一步优化,降低离线拉取ACK带来的额外与服务器的交互次数

假设有N页离线消息,现在每个离线消息需要一个ACK,那么岂不是客户端与服务器的交互次数又加倍了?有没有优化空间?

如上图所示,不用每一页消息都ACK,在拉取第二页消息时相当于第一页消息的ACK,此时服务器再删除第一页的离线消息即可,最后一页消息再ACK一次(实际上:最后一页拉取的肯定是空返回,这样可以极大地简化这个分页过程,否则客户端得知道当前离线消息的总页数,而由于消息读取延迟的存在,这个总页数理论上并非绝对不变,从而加大了数据读取不一致的可能性)。这样的效果是,不管拉取多少页离线消息,只会多一个ACK请求,与服务器多一次交互。

11、本文小结

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

1)对于同一个用户B,一次性拉取所有用户发给ta的离线消息,再在客户端本地进行发送方分析,相比按照发送方一个个进行消息拉取,能大大减少服务器交互次数;

2)分页拉取,先拉取计数再按需拉取,是无线端的常见优化;

3)应用层的ACK,应用层的去重,才能保证离线消息的不丢不重;

4)下一页的拉取,同时作为上一页的ACK,能够极大减少与服务器的交互次数。

(本文同步发布于:http://www.52im.net/thread-59...,本文内容参考了:微信为啥不丢“离线消息”)


即时通讯开发
实时推送、IM等即时通讯相关技术的研究、分享的专栏。让即时通讯技术能更好地学习、交流与传播,不再零...

专注即时通讯(IM/推送)技术学习和研究。

1.4k 声望
746 粉丝
0 条评论
推荐阅读
IM开发者的零基础通信技术入门(十):零基础,史上最强5G技术扫盲
➊ 5G技术的关注度越来越高:在此之前,5G技术对于普通老百姓来说,似乎还很遥远,关注度并不高。但从去年开始,美帝赤裸裸打压中兴和华为的国际事件,让5G技术在国内有了很高的关注度。美帝打压中兴、华为固然是...

JackJiang

封面图
化虹为桥 - Nginx 如何代理 UDP “连接”
众所周知,UDP 并不像 TCP 那样是基于连接的。但有些时候,我们需要往一个固定的地址发送多个 UDP 来完成一个 UDP 请求。为了保证服务端能够知道这几个 UDP 包构成同一个会话,我们需要在发送 UDP 包时绑定某个端...

spacewander4阅读 952

IM通讯协议专题学习(七):手把手教你如何在NodeJS中从零使用Protobuf
Protobuf最大的特点是数据格式拥有极高的压缩比,这在移动互联时代是极具价值的(因为移动网络流量到目前为止仍然昂贵的),如果你的APP能比竞品更省流量,无疑这也将成为您产品的亮点之一。

JackJiang1阅读 439

封面图
社交场景下iOS消息流交互层实践
一款社交产品的诞生,离不开即时通讯(IM)场景。随着团队业务版图在社交领域的布局,诞生了多个社交场景APP,涉及的IM场景,包含私聊、群聊、聊天室等。

云音乐技术团队1阅读 434

封面图
IM通讯协议专题学习(八):金蝶随手记团队的Protobuf应用实践(原理篇)
跟移动端IM中追求数据传输效率、网络流量消耗等需求一样,随手记客户端与服务端交互的过程中,对部分数据的传输大小和效率也有较高的要求,普通的数据格式如 JSON 或者 XML 已经不能满足,因此决定采用 Google 推...

JackJiang阅读 710

封面图
IM通讯协议专题学习(五):Protobuf到底比JSON快几倍?全方位实测!
本系列的前几篇主要是从各个角度讲解Protobuf的基本概念、技术原理这些内容,但回过头来看,对比JSON这种事实上的数据协议工业标准,Protobuf到底性能到底高多少?本篇将以Protobuf为基准,对比市面上的一些主流...

JackJiang阅读 680

封面图
Qt中使用TCP接收报文
假设有一个TCP服务端,会向连接到它的TCP客户端周期(或随机)发送一个报文。报文由定长的报文头和不定长的报文体(数据部分)组成,报文体是一张图片,每个字节表示图片中一个像素的灰度值。我们的任务就是读取...

manxisuo阅读 646

专注即时通讯(IM/推送)技术学习和研究。

1.4k 声望
746 粉丝
宣传栏