IM消息送達(dá)保證機制實現(xiàn)(二)：保證離線消息的可靠投遞

Posted on 2016-11-18 14:39 Jack Jiang 閱讀(3085) 評論(0) 編輯收藏

1、前言

本文的上篇《IM消息送達(dá)保證機制實現(xiàn)(一)：保證在線實時消息的可靠投遞》中，我們討論了在線實時消息的投遞可以通過應(yīng)用層的確認(rèn)、發(fā)送方的超時重傳、接收方的去重等手段來保證業(yè)務(wù)層面消息的不丟不重。

但實時在線投遞針對的是消息收發(fā)雙方都在線的情況（如當(dāng)發(fā)送方用戶A發(fā)送消息給接收方用戶B時，用戶B是在線的），那如果消息的接收方用戶B不在線，系統(tǒng)是如何保證消息的可達(dá)性的呢？這就是本文要討論的問題。（本文同步發(fā)布于：http://www.52im.net/thread-594-1-1.html）

2、學(xué)習(xí)交流

- 即時通訊開發(fā)交流群： 215891622 [推薦]

- 移動端IM開發(fā)推薦文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

3、IM消息送達(dá)保證系列文章

本文是討論IM消息送達(dá)保證系列文章中的第2篇，總目錄如下：

《IM消息送達(dá)保證機制實現(xiàn)(一)：保證在線實時消息的可靠投遞》
《IM消息送達(dá)保證機制實現(xiàn)(二)：保證離線消息的可靠投遞》（本文）

另外，如果您正在查閱移動端IM開發(fā)資料，推薦閱讀《新手入門一篇就夠：從零開發(fā)移動端IM》。

4、消息接收方不在線時的典型消息發(fā)送流程

如上圖所述，通常此類情況下消息的發(fā)送流程如下：

Step 1：用戶A發(fā)送一條消息給用戶B；
Step 2：服務(wù)器查看用戶B的狀態(tài)，發(fā)現(xiàn)B的狀態(tài)為“offline”（即B當(dāng)前不在線）；
Step 3：服務(wù)器將此條消息以離線消息的形式持久化存儲到DB中（當(dāng)然，具體的持久化方案可由您IM的具體技術(shù)實現(xiàn)為準(zhǔn)）；
Step 4：服務(wù)器返回用戶A“發(fā)送成功”ACK確認(rèn)包（注：對于消息發(fā)送方而言，消息一旦落地存儲至DB就認(rèn)為是發(fā)送成功了）。

關(guān)于 “Step 4” 的補充說明：

請一定要理解“Step 4”，因為現(xiàn)在無論是傳統(tǒng)的PC端IM（類似QQ這樣的——可以在UI上看到好友的在線、離線狀態(tài)）還是目前主流的移動端IM（強調(diào)的是用戶全時在線——即你看不到好友到底在線還是離線，反正給你的假像就是這個好友“應(yīng)該”是在線的），消息發(fā)送出去后，無論是對方實時在線收到還是對方不在線而被服務(wù)端離線存儲了，對于發(fā)送方而言只要消息沒有因為網(wǎng)絡(luò)等原因莫名消失，就應(yīng)該認(rèn)為是“被收到了”。

從技術(shù)的角度講，消息接收方收到的消息應(yīng)答ACK包的真正發(fā)起者，實際上有兩種可能性：一種是由接收方發(fā)出、而另一種是由服務(wù)端代為發(fā)送（這在MobileIMSDK開源工程里被稱作“偽應(yīng)答”）。

5、典型離線消息表的設(shè)計以及拉取離線消息的過程

① 存儲離線消看書的表主要字段大致如下：

-- 消息接收者ID

receiver_uid varchar(50),

-- 消息的唯一指紋碼（即消息ID），用于去重等場景，單機情況下此id可能是個自增值、分布式場景下可能是類似于UUID這樣的東西

msg_id varchar(70),

-- 消息發(fā)出時的時間戳（如果是個跨國IM，則此時間戳可能是GMT-0標(biāo)準(zhǔn)時間）

send_time time,

-- 消息發(fā)送者ID

sender_uid varchar(50),

-- 消息類型（標(biāo)識此條消息是：文本、圖片還是語音留言等）

msg_type int,

-- 消息內(nèi)容（如果是圖片或語音留言等類型，由此字段存放的可能是對應(yīng)文件的存儲地址或CDN的訪問URL）

msg_content varchar(1024),

…

② 離線消息拉取模式：
接收方B要拉取發(fā)送方A給ta發(fā)送的離線消息，只需在receiver_uid（即接收方B的用戶ID), sender_uid（即發(fā)送方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發(fā)送給ta的離線消息；
Stelp 2：服務(wù)器從DB（或?qū)?yīng)的持久化容器）中拉取離線消息；
Stelp 3：服務(wù)器從DB（或?qū)?yīng)的持久化容器）中把離線消息刪除；
Stelp 4：服務(wù)器返回給用戶B想要的離線消息。

6、上述流程存在的問題以及優(yōu)化方案

如果用戶B有很多好友，登陸時客戶端需要對所有好友進(jìn)行離線消息拉取，客戶端與服務(wù)器交互次數(shù)就會比較多。

① 拉取好友離線消息的客戶端偽代碼：

// 登陸時所有好友都要拉取

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

// 與服務(wù)器交互

get_offline_msg(B,uid);

}

② 優(yōu)化方案1：
先拉取各個好友的離線消息數(shù)量，真正用戶B進(jìn)去看離線消息時，才往服務(wù)器發(fā)送拉取請求（手機端為了節(jié)省流量，經(jīng)常會使用這個按需拉取的優(yōu)化）。

③ 優(yōu)化方案2：
如下圖所示，一次性拉取所有好友發(fā)送給用戶B的離線消息，到客戶端本地再根據(jù)sender_uid進(jìn)行計算，這樣的話，離校消息表的訪問模式就變?yōu)?>只需要按照receiver_uid來查詢了。登錄時與服務(wù)器的交互次數(shù)降低為了1次。

④ 方案小結(jié)：
通常情況下，主流的的移動端IM（比如微信、手Q等）通常都是以“優(yōu)化方案2”為主，因為移動網(wǎng)絡(luò)的不可靠性加上電量、流量等資源的昂貴性，能盡量一次性干完的事，就盡可能一次搞定，從而提供整個APP的用戶體驗（對于移動端應(yīng)用而言，省電、省流量同樣是用戶體驗的一部分）。這方面的文章，可以進(jìn)一步參閱《談?wù)勔苿佣?IM 開發(fā)中登錄請求的優(yōu)化》、《移動端IM實踐：iOS版微信界面卡頓監(jiān)測方案》、《移動端IM實踐：Android版微信如何大幅提升交互性能（二）》。

7、消息接收方一次拉取大量離線消息導(dǎo)致速度慢、卡頓的解決方法

用戶B一次性拉取所有好友發(fā)給ta的離線消息，消息量很大時，一個請求包很大、速度慢，容易卡頓怎么辦？

正如上圖所示，我們可以分頁拉取：根據(jù)業(yè)務(wù)需求，先拉取最新（或者最舊）的一頁消息，再按需一頁頁拉取，這樣便能很好地解決用戶體驗問題。

8、優(yōu)化離線消息的拉取過程，保證離線消息不會丟失

如何保證可達(dá)性，上述步驟第三步執(zhí)行完畢之后，第四個步驟離線消息返回給客戶端過程中，服務(wù)器掛點，路由器丟消息，或者客戶端crash了，那離線消息豈不是丟了么（數(shù)據(jù)庫已刪除，用戶還沒收到）？

確實，如果按照上述的1、2、3、4步流程，的確是的，那如何保證離線消息的絕對可靠性、可達(dá)性？

如同在線消息的應(yīng)用層ACK機制一樣，離線消息拉時，不能夠直接刪除數(shù)據(jù)庫中的離線消息，而必須等應(yīng)用層的離線消息ACK（說明用戶B真的收到離線消息了），才能刪除數(shù)據(jù)庫中的離線消息。這個應(yīng)用層的ACK可以通過實時消息通道告之服務(wù)端，也可以通過服務(wù)端提供的REST接口，以更通用、簡單的方式通知服務(wù)端。

9、進(jìn)一步優(yōu)化，解決重復(fù)拉取離線消息的問題

如果用戶B拉取了一頁離線消息，卻在ACK之前crash了，下次登錄時會拉取到重復(fù)的離線消息么？

確實，拉取了離線消息卻沒有ACK，服務(wù)器不會刪除之前的離線消息，故下次登錄時系統(tǒng)層面還會拉取到。但在業(yè)務(wù)層面，可以根據(jù)msg_id去重。SMC理論：系統(tǒng)層面無法做到消息不丟不重，業(yè)務(wù)層面可以做到，對用戶無感知。

優(yōu)化后的拉取過程，如下圖所示：

10、進(jìn)一步優(yōu)化，降低離線拉取ACK帶來的額外與服務(wù)器的交互次數(shù)

假設(shè)有N頁離線消息，現(xiàn)在每個離線消息需要一個ACK，那么豈不是客戶端與服務(wù)器的交互次數(shù)又加倍了？有沒有優(yōu)化空間？

如上圖所示，不用每一頁消息都ACK，在拉取第二頁消息時相當(dāng)于第一頁消息的ACK，此時服務(wù)器再刪除第一頁的離線消息即可，最后一頁消息再ACK一次（實際上：最后一頁拉取的肯定是空返回，這樣可以極大地簡化這個分頁過程，否則客戶端得知道當(dāng)前離線消息的總頁數(shù)，而由于消息讀取延遲的存在，這個總頁數(shù)理論上并非絕對不變，從而加大了數(shù)據(jù)讀取不一致的可能性）。這樣的效果是，不管拉取多少頁離線消息，只會多一個ACK請求，與服務(wù)器多一次交互。

11、本文小結(jié)

正如本文中所列舉的問題所描述的那樣，保證“離線消息”的可達(dá)性比大家想象的要復(fù)雜一些，常見優(yōu)化總結(jié)如下：

1）對于同一個用戶B，一次性拉取所有用戶發(fā)給ta的離線消息，再在客戶端本地進(jìn)行發(fā)送方分析，相比按照發(fā)送方一個個進(jìn)行消息拉取，能大大減少服務(wù)器交互次數(shù)；
2）分頁拉取，先拉取計數(shù)再按需拉取，是無線端的常見優(yōu)化；
3）應(yīng)用層的ACK，應(yīng)用層的去重，才能保證離線消息的不丟不重；
4）下一頁的拉取，同時作為上一頁的ACK，能夠極大減少與服務(wù)器的交互次數(shù)。

（本文同步發(fā)布于：http://www.52im.net/thread-594-1-1.html，本文內(nèi)容參考了：微信為啥不丟“離線消息”）

12、IM技術(shù)資料分類

作者：Jack Jiang (點擊作者姓名進(jìn)入Github)
出處：http://www.52im.net/space-uid-1.html
交流：歡迎加入即時通訊開發(fā)交流群 215891622
討論：http://www.52im.net/
Jack Jiang同時是【原創(chuàng)Java Swing外觀工程BeautyEye】和【輕量級移動端即時通訊框架MobileIMSDK】的作者，可前往下載交流。
本博文歡迎轉(zhuǎn)載，轉(zhuǎn)載請注明出處（也可前往我的52im.net 找到我）。

新用戶注冊刷新評論列表


只有注冊用戶登錄后才能發(fā)表評論。




網(wǎng)站導(dǎo)航: 博客園 IT新聞 Chat2DB C++博客博問管理

Jack Jiang

導(dǎo)航

公告

常用鏈接

留言簿(285)

隨筆檔案

文章檔案

搜索

最新評論

閱讀排行榜

評論排行榜

60天內(nèi)閱讀排行