即时通讯IM信息送达稳定(二)：稳定离线信息的可靠投递

1、序言

正文的上篇《IM音问送达作保单式编制奋斗以成(一)：保准在线实时消息的可靠投递》中，咱们谈论了在线实时信息的投递足以通过使役层的认同、殡葬方的脱班重传、收纳方的去重等手段来担保事情规模音息的不丢不重。

但实时在线递送本着的是信息收发两下里都在线的情形（如当殡葬方用户A发送音信给收下方用户B时，用户B是在线的），那假如消息的接纳方用户B不在线，体系是哪些包管音问的可达性的呢？这即使如此本文要谈谈的题材。

2、IM开发干货不可胜数成文

白文是多元成文中的第2篇，总目录正象：

《IM消息送达力保单式编制贯彻(一)：承保在线实时音问的可靠递送》

《IM音信送达担保建制奋斗以成(二)：承保离线信息的可靠投递》（正文）

《怎么样保管IM实时音尘的“时序性”与“一致性”？》

《IM单聊和群聊中的在线状态联机该当用“推”或者“拉”？》

《IM群聊音息这么样复杂，什么样担保不丢不重？》

《一种Android端IM智能心跳算法的计划性与落实探讨（含样例代码）》

《挪窝端IM报到时拉取额数哪边作到省流量？》

《通俗易懂：依据集群的举手投足端IM连缀层负荷均衡方案大快朵颐》

《浅谈移动端IM的多点登陆和信息观光规律》

《IM支付基础知识补课(一)：正确理解放权HTTP SSO单点登陆接口的常理》

《IM支出基础知识补课(二)：咋样擘画豁达图籍文牍的服务端仓储架构？》

《IM支出基础知识补课(三)：短平快清楚服务端数据库读写暌违规律及推行纳谏》

《IM开发基础知识补课(四)：正确理解HTTP短连年中的Cookie、Session和Token》

《IM群聊信息的已读回执职能该怎生兑现？》

《IM群聊音息到底是存1份(即扩散读)或者存多份(即扩散写)？》

《IM支出基础知识补课(五)：通俗易懂，正确理解并用好MQ信息队列》

《一个低成本管教IM信息时序的办法根究》

《IM开销基础知识补课(六)：数据库用NoSQL要么SQL？读这篇就够了！》

《IM里“邻县的人”成效奋斗以成常理是嗬哟？何许速成地贯彻它？》

《IM支付基础知识补课(七)：主流平移端账号记名措施的法则及规划文思》

《IM开支基础知识补课(八)：史上最通俗，一干二净搞懂字符乱码题材的本相》

《IM的扫码登效益哪样兑现？一文搞懂主流运用的扫码登陆招术规律》

《IM要做手机扫码登陆？先细瞧微信的扫码登录效能技艺公设》

《IM支付基础知识补课(九)：想支付IM集群？先搞懂什么是RPC！》

除此以外，假设您是IM开发初学者，强烈建议率先阅览《新手入门一篇就够：从零开销活动端IM》。

3、音信接下方不在线时的杰出消息出殡工艺流程

IM音问送达管保机制贯彻(二)：管保离线消息的可靠投递_1.png 

如上图所述，日常此类情况下音问的出殡流程如次：

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、天下无双离线音息表的规划以及拉取离线消息的过程

① 储存离线消看书的表重要性字段大略如下：

010203040506070809101112131415161718-- 音信收信人IDreceiver_uid varchar(50),  -- 音尘的绝无仅有指印码（即音息ID），用来去重等现象，单机情况下此id容许是个自增值、分布式形貌下也许是类似于UUID如斯的东西msg_id varchar(70),  -- 音息产生时的时间戳（倘然是个跨国IM，则此年月戳想必是GMT-0规范年月）       send_time time,  -- 音讯发送者IDsender_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语句来叙说的话，它何尝不可是：

123SELECT msg_id, send_time, msg_type, msg_content FROM offline_msgsWHERE receiver_uid = ? and sender_uid = ?

④ 离线拉取的总体工艺流程正象图所示：

Stelp 1：用户B开班拉取用户A发送给ta的离线音信；

Stelp 2：服务器从DB（或相应的持久化器皿）中拉取离线音尘；

Stelp 3：服务器从DB（或随声附和的持久化盛器）中把离线音信去除；

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

IM音尘送达确保单式编制落实(二)：保准离线音息的可靠投递_2.png 

5、上述流程设有的题材以及优化方案

倘然用户B有很多好友，登陆时客户端特需对抱有好友进行离线音讯拉取，客户端与服务器竞相次数就会正如多。

① 拉取执友离线音讯的客户端伪代码：

12345// 登陆时保有执友都要拉取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，亦可极大释减与服务器的相互次数。