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

JackJiang · 8 年前

1、前言

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

但实时在线投递针对的是消息收发双方都在线的情况（如当发送方用户A发送消息给接收方用户B时，用户B是在线的），那如果消息的接收方用户B不在线，系统是如何保证消息的可达性的呢？这就是本文要讨论的问题。

2、IM开发干货系列文章

本文是系列文章中的第2篇，总目录如下：

另外，如果您是IM开发初学者，强烈建议首先阅读《新手入门一篇就够：从零开发移动端IM》。

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

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

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开源工程里被称作“伪应答”）。

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

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

-- 消息接收者ID
receiver_uid varchar(50), 

-- 消息的唯一指纹码（即消息ID），用于去重等场景，单机情况下此id可能是个自增值、分布式场景下可能是类似于UUID这样的东西
msg_id varchar(70), 

-- 消息发出时的时间戳（如果是个跨国IM，则此时间戳可能是GMT-0标准时间）       
send_time time, 

-- 消息发送者ID
sender_uid varchar(50), 

-- 消息类型（标识此条消息是：文本、图片还是语音留言等）
msg_type int, 

-- 消息内容（如果是图片或语音留言等类型，由此字段存放的可能是对应文件的存储地址或CDN的访问URL）
msg_content varchar(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 = ?

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

Stelp 1：用户B开始拉取用户A发送给ta的离线消息；
Stelp 2：服务器从DB（或对应的持久化容器）中拉取离线消息；
Stelp 3：服务器从DB（或对应的持久化容器）中把离线消息删除；
Stelp 4：服务器返回给用户B想要的离线消息。

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

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

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

// 登陆时所有好友都要拉取
for(all uid in B’s friend-list){ 
     // 与服务器交互
     get_offline_msg(B,uid);   
}

② 优化方案1：

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

③ 优化方案2：

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

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

④ 方案小结：

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

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

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

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

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

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

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

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

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

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

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

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

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

优化后的拉取过程，如下图所示：

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

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

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

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

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

10、本文小结

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

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

（本文内容参考了：微信为啥不丢“离线消息”）

11、全站即时通讯技术资料分类

52 楼: 苏门答腊伟 · 1 年前

服务端居然不存储消息吗？如果客户端卸载了软件，以前的消息其实是丢了？按道理无论在线还是离线都应该存消息的吧

51 楼: JackJiang · 1 年前

引用：doublesouth 发表于 2023-06-09 12:42
如果每条消息在下发之前都存入离线消息库，是不是还得监听客户端ack，如果确认客户端收到消息了再从离线 ...

严谨来说，确实需要客户端ack的

50 楼: doublesouth · 1 年前

引用：JackJiang 发表于 2023-06-08 21:20
通常肯定是先持久化存库再下方，不然必定会有意外发生

如果每条消息在下发之前都存入离线消息库，是不是还得监听客户端ack，如果确认客户端收到消息了再从离线库删除消息？
没有这个机制的话，离线消息库感觉存储的并不是都是离线消息，退化成存储了全量的消息。

49 楼: 921124136 · 1 年前

我只是好奇，又查询又删除的，这数据库不会锁表吗？

48 楼: JackJiang · 1 年前

引用：doublesouth 发表于 2023-06-08 19:49
关于“Step 2：服务器查看用户B的状态，发现B的状态为“offline”（即B当前不在线）；”
当用户B在线，服 ...

通常肯定是先持久化存库再下方，不然必定会有意外发生

47 楼: doublesouth · 1 年前

关于“Step 2：服务器查看用户B的状态，发现B的状态为“offline”（即B当前不在线）；”
当用户B在线，服务端推送下行消息给B的时候失败了，导致B的客户端未收取到消息，消息也没有存入到离线消息库，这种情况会导致用户B的客户端丢失消息吧。

46 楼: JackJiang · 3 年前

引用：lmyJavaDE1 发表于 2018-08-07 17:02
"进一步优化，解决重复拉取离线消息的问题：拉取了离线消息却没有ACK，服务器不会删除之前的离线消息，故下 ...

客户端上次拉过后，本地有缓存，这次再拉到就根据缓存来去掉，缓存里有的就是表示上次已拉过

45 楼: 椎锋陷陈 · 3 年前

引用：某非著名程序发表于 2021-02-05 09:24
文中第5条优化2一般一次性拉取，主流的的移动端IM（比如微信、手Q等）通常都是以“优化方案2”为主。然后第 ...

作者前后的描述其实并不矛盾，因为关注的重点不同。

前者主要涉及的是读扩散和写扩散的问题，
所谓读扩散，假设用户有500个好友，那就要执行500个HTTP请求，除了作者说的那些问题，还有
无效请求的问题，即某些好友并没有新增的离线消息。
所谓写扩散，就是有一个额外的「收件箱」，用于存储所有好友的离线消息，每次都要额外写入
一次，用户拉取所有离线消息只需要从这个收件箱拉取即可，拉取之后再在本地进行分组，可以
大大减少请求次数。

后者是在前者的基础上，考虑了离线消息比较多的情况，造成数据量很大，请求速度慢，本地频繁
存储后刷新引起卡顿，因此改成了分页拉取，减少每次拉取和要处理的数据量，边拉取边处理。

44 楼: 庞衍楠 · 3 年前

学习了

43 楼: JackJiang · 3 年前

引用：江明发表于 2021-07-23 11:01
是否可以通过端上缓存最新的消息时间戳，拉取的时候带上时间戳向服务器请求，服务器返回>=时间戳的消息。
...

可行，这就是个比较优秀的方案

42 楼: JackJiang · 3 年前

引用：lmyJavaDE1 发表于 2018-08-07 17:02
"进一步优化，解决重复拉取离线消息的问题：拉取了离线消息却没有ACK，服务器不会删除之前的离线消息，故下 ...

这里的去重说的是客户端去重，因为你客户端没有ack，服务端就没法删除已拉取的，所以下次还能拉到，而你客户端本地有缓存，下次再拉的消息，用消息id跟本地的比，已经存在的就表示重复，不保存就行了

41 楼: 江明 · 3 年前

是否可以通过端上缓存最新的消息时间戳，拉取的时候带上时间戳向服务器请求，服务器返回>=时间戳的消息。

这样服务端只需一个表存储全量的消息即可。
而且对应多端的情况，也是同样的逻辑。

这样是否可行？

40 楼: JackJiang · 4 年前

引用：某非著名程序发表于 2021-02-05 09:24
文中第5条优化2一般一次性拉取，主流的的移动端IM（比如微信、手Q等）通常都是以“优化方案2”为主。然后第 ...

微信是这个逻辑，但qq貌似有点差异

39 楼: 某非著名程序 · 4 年前

文中第5条优化2一般一次性拉取，主流的的移动端IM（比如微信、手Q等）通常都是以“优化方案2”为主。然后第6条提到又分页拉取，这个分页也是拉取所有好友的分页消息，然后点进会话再拉取对应的离线消息吗？

38 楼: JackJiang · 4 年前

引用：某非著名程序发表于 2021-01-31 09:14
服务端不会存储消息,如果客户端切换设备,或者同时有多个端如PC端、手机端,是不是意味着没有历史记录

是的

37 楼: 某非著名程序 · 4 年前

服务端不会存储消息,如果客户端切换设备,或者同时有多个端如PC端、手机端,是不是意味着没有历史记录

36 楼: JackJiang · 5 年前

引用：ToFind1991 发表于 2020-04-01 18:00
你好，我有个疑问，就是最后说分页拉取的时候，后一次是前一次的ack,会不会出现拉20条消息，有一条丢了，这 ...

分布拉取一般都是通过http接口，要么全部成功，要么全部失败。

35 楼: poiupoiu · 5 年前

感谢分享

34 楼: ToFind1991 · 5 年前

你好，我有个疑问，就是最后说分页拉取的时候，后一次是前一次的ack,会不会出现拉20条消息，有一条丢了，这个时候处于一种半完成的状态，是要单独把丢失的那条拿到然后再下一页吗？

本文目录

1、前言

2、IM开发干货系列文章

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

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

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

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

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

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

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

10、本文小结

11、全站即时通讯技术资料分类

评分

本帖已收录至以下技术专辑

MobileIMSDK(v6.5精编版)

MobileIMSDK-Web(有偿开源)

RainbowAVnew(有偿开源)

RainbowChat(技术转让)

RainbowChat-Web(技术转让)

浏览过的版块

精华之王

白金版主

终身成就

7天大胜

小有积蓄

兔

牛

龙

羊

鼠

虎

蛇

猴

马

鸡

狗

活跃开发者

即时通讯网

友情链接[友链交换]

关于

微信公众号new

MobileIMSDK (v6.5精编版)

MobileIMSDK-Web (有偿开源)

RainbowAVnew (有偿开源)

RainbowChat (技术转让)

RainbowChat-Web (技术转让)

即时通讯网　