消息的可靠性，即消息的不丟失和不重復(fù)，是im系統(tǒng)中的一個(gè)難點(diǎn)。當(dāng)初qq在技術(shù)上（當(dāng)時(shí)叫oicq）因?yàn)橐韵聝牲c(diǎn)原因才打敗了icq：
1）qq的消息投遞可靠（消息不丟失，不重復(fù)）
2）qq的垃圾消息少（它antispam做得好，這也是一個(gè)難點(diǎn)，但不是本文重點(diǎn)討論的內(nèi)容）
今天，本文將用十分通俗的語言，來講述webim系統(tǒng)中消息可靠性的問題。

一、報(bào)文類型
im的客戶端與服務(wù)器通過發(fā)送報(bào)文（也就是請(qǐng)求包）來完成消息的傳遞，報(bào)文分為三種，請(qǐng)求報(bào)文（request，后簡(jiǎn)稱為為R），應(yīng)答報(bào)文（acknowledge，后簡(jiǎn)稱為A），通知報(bào)文（notify，后簡(jiǎn)稱為N），這三種報(bào)文的解釋如下：

R：客戶端主動(dòng)發(fā)送給服務(wù)器的報(bào)文
A：服務(wù)器被動(dòng)應(yīng)答客戶端的報(bào)文，一個(gè)A一定對(duì)應(yīng)一個(gè)R
N：服務(wù)器主動(dòng)發(fā)送給客戶端的報(bào)文

二、普通消息投遞流程
用戶A給用戶B發(fā)送一個(gè)“你好”，很容易想到，流程如下：

1）client-A向im-server發(fā)送一個(gè)消息請(qǐng)求包，即msg:R
2）im-server在成功處理后，回復(fù)client-A一個(gè)消息響應(yīng)包，即msg:A
3）如果此時(shí)client-B在線，則im-server主動(dòng)向client-B發(fā)送一個(gè)消息通知包，即msg:N（當(dāng)然，如果client-B不在線，則消息會(huì)存儲(chǔ)離線）

三、上述消息投遞流程出現(xiàn)的問題
從流程圖中容易看到，發(fā)送方client-A收到msg:A后，只能說明im-server成功接收到了消息，并不能說明client-B接收到了消息。在若干場(chǎng)景下，可能出現(xiàn)msg:N包丟失，且發(fā)送方client-A完全不知道，例如：
1）服務(wù)器崩潰，msg:N包未發(fā)出
2）網(wǎng)絡(luò)抖動(dòng)，msg:N包被網(wǎng)絡(luò)設(shè)備丟棄
3）client-B崩潰，msg:N包未接收
結(jié)論是悲觀的：接收方client-B是否有收到msg:N，發(fā)送方client-A完全不可控，那怎么辦呢？

四、應(yīng)用層確認(rèn)+im消息可靠投遞的六個(gè)報(bào)文
upd是一種不可靠的傳輸層協(xié)議，tcp是一種可靠的傳輸層協(xié)議，tcp是如何做到可靠的？答案是：超時(shí)、重傳、確認(rèn)。
要想實(shí)現(xiàn)應(yīng)用層的消息可靠投遞，必須加入應(yīng)用層的確認(rèn)機(jī)制，即：要想讓發(fā)送方client-A確保接收方client-B收到了消息，必須讓接收方client-B給一個(gè)消息的確認(rèn)，這個(gè)應(yīng)用層的確認(rèn)的流程，與消息的發(fā)送流程類似：

4）client-B向im-server發(fā)送一個(gè)ack請(qǐng)求包，即ack:R
5）im-server在成功處理后，回復(fù)client-B一個(gè)ack響應(yīng)包，即ack:A
6）則im-server主動(dòng)向client-A發(fā)送一個(gè)ack通知包，即ack:N
至此，發(fā)送“你好”的client-A，在收到了ack:N報(bào)文后，才能確認(rèn)client-B真正接收到了“你好”。
會(huì)發(fā)現(xiàn)，一條消息的發(fā)送，分別包含（上）（下）兩個(gè)半場(chǎng)，即msg的R/A/N三個(gè)報(bào)文，ack的R/A/N三個(gè)報(bào)文，一個(gè)應(yīng)用層即時(shí)通訊消息的可靠投遞，共涉及6個(gè)報(bào)文，這就是im系統(tǒng)中消息投遞的最核心技術(shù)（如果某個(gè)im系統(tǒng)不包含這6個(gè)報(bào)文，不要談什么消息的可靠性）。

五、可靠消息投遞存在什么問題
期望六個(gè)報(bào)文完成消息的可靠投遞，但實(shí)際情況下：
1）msg:R，msg:A報(bào)文可能丟失，此時(shí)直接提示“發(fā)送失敗”即可，問題不大
2）msg:N，ack:R，ack:A，ack:N這四個(gè)報(bào)文都可能丟失（原因如第二章所述，可能是服務(wù)器奔潰、網(wǎng)絡(luò)抖動(dòng)、或者客戶端奔潰），此時(shí)client-A都收不到期待的ack:N報(bào)文，即client-A不能確認(rèn)client-B是否收到“你好”，那怎么辦呢？

六、消息的超時(shí)與重傳
client-A發(fā)出了msg:R，收到了msg:A之后，在一個(gè)期待的時(shí)間內(nèi)，如果沒有收到ack:N，client-A會(huì)嘗試將msg:R重發(fā)。可能client-A同時(shí)發(fā)出了很多消息，故client-A需要在本地維護(hù)一個(gè)等待ack隊(duì)列，并配合timer超時(shí)機(jī)制，來記錄哪些消息沒有收到ack:N，以定時(shí)重發(fā)。

一旦收到了ack:N，說明client-B收到了“你好”消息，對(duì)應(yīng)的消息將從“等待ack隊(duì)列”中移除。

七、消息的重傳存在什么問題
第五章提到過，msg:N報(bào)文，ack:N報(bào)文都有可能丟失：
1）msg:N報(bào)文丟失，說明client-B之前壓根沒有收到“你好”報(bào)文，超時(shí)與重傳機(jī)制十分有效
2）ack:N報(bào)文丟失，說明client-B之前已經(jīng)收到了“你好”報(bào)文（只是client-A不知道而已），超時(shí)與重傳機(jī)制將導(dǎo)致client-B收到重復(fù)的消息，那怎么辦呢？
啟示：
平時(shí)使用qq，或許大伙都有類似的體驗(yàn)，彈出一個(gè)對(duì)話框“因?yàn)榫W(wǎng)絡(luò)原因，消息發(fā)送失敗，是否要重發(fā)”，此時(shí)，有可能是對(duì)方?jīng)]有收到消息（發(fā)送方網(wǎng)絡(luò)不好，msg:N丟失），也可能已經(jīng)收到了消息（接收方網(wǎng)絡(luò)不好，反復(fù)重傳后，ack:N依然丟失），出現(xiàn)這個(gè)提示時(shí)，大伙不妨和對(duì)端確認(rèn)一下，看是哪種情況。

八、消息的去重
解決方法也很簡(jiǎn)單，由發(fā)送方client-A生成一個(gè)消息去重的msgid，保存在“等待ack隊(duì)列”里，同一條消息使用相同的msgid來重傳，供client-B去重，而不影響用戶體驗(yàn)。

九、其他
1）上述設(shè)計(jì)理念，由客戶端重傳，可以保證服務(wù)端無狀態(tài)性（架構(gòu)設(shè)計(jì)基本準(zhǔn)則）
2）如果client-B不在線，im-server保存了離線消息后，要偽造ack:N發(fā)送給client-A
3）離線消息的拉取，為了保證消息的可靠性，也需要有ack機(jī)制，但由于拉取離線消息不存在N報(bào)文，故實(shí)際情況要簡(jiǎn)單的多，即先發(fā)送offline:R報(bào)文拉取消息，收到offline:A后，再發(fā)送offlineack:R刪除離線消息

十、總結(jié)
1）im系統(tǒng)是通過超時(shí)、重傳、確認(rèn)、去重的機(jī)制來保證消息的可靠投遞，不丟不重
2）切記，一個(gè)“你好”的發(fā)送，包含上半場(chǎng)msg:R/A/N與下半場(chǎng)ack:R/A/N的6個(gè)報(bào)文

個(gè)人消息是一個(gè)1對(duì)1的ack，群消息就沒有這么簡(jiǎn)單了，群消息存在一個(gè)擴(kuò)散系數(shù)，如果大家感興趣，下一次將和大家討論im群消息的可靠投遞。

轉(zhuǎn)載于:https://www.cnblogs.com/djrLog/p/5603755.html

總結(jié)

以上是生活随笔為你收集整理的IM系统中如何保证消息的可靠投递（即QoS机制）（转）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。