微信為啥不丟“離線消息”?

2018-09-06 17:20 更新

需求緣起

當(dāng)發(fā)送方用戶A發(fā)送消息給接收方用戶B時,如果用戶B在線,之前的文章《微信為啥不丟“在線消息”?》聊過,可以通過應(yīng)用層的確認(rèn),發(fā)送方的超時重傳,接收方的去重保證業(yè)務(wù)層面消息的不丟不重。

那如果接收方用戶B不在線,系統(tǒng)是如何保證消息的可達(dá)性的呢?這是本文要討論的問題。


問題:接收方不在線時,消息發(fā)送的流程是怎么樣的?

離線消息存儲過程

回答:如上圖所述,

(1)用戶A發(fā)送消息給用戶B

(2)服務(wù)器查看用戶B的狀態(tài)為offline

(3)服務(wù)器將消息存儲到DB中

(4)服務(wù)器返回用戶A發(fā)送成功(對于發(fā)送方而言,消息落地DB就認(rèn)為發(fā)送成功)


問題:離線消息表的設(shè)計,拉取離線的過程?

receiver_uid, msg_id, time, sender_uid,msg_type, msg_content …

訪問模式:接收方B要拉取發(fā)送方A給ta發(fā)送的離線消息,只需在receiver_uid(B), sender_uid(A)上查詢,然后把離線消息刪除,再把消息返回B即可。

離線消息拉取過程

整體流程如上圖所述,

(1)用戶B拉取用戶A發(fā)送給ta的離線消息

(2)服務(wù)器從DB中拉取離線消息

(3)服務(wù)器從DB中把離線消息刪除

(4)服務(wù)器返回給用戶B想要的離線消息


問題:上述流程存在的問題?

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

客戶端偽代碼:

for(all uid in B’s friend-list){      // 登陸時所有好友都要拉取
         get_offline_msg(B,uid);   // 與服務(wù)器交互

}

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

離線消息拉取過程優(yōu)化1

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


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

離線消息拉取過程優(yōu)化2

回答:分頁拉取,根據(jù)業(yè)務(wù)需求,先拉取最新(或者最舊)的一頁消息,再按需一頁頁拉取。


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

回答:嗯,如果按照上述的1,2,3,4步流程,的確是的,那如何保證離線消息的可達(dá)性?

離線消息拉取過程優(yōu)化3

如同在線消息的應(yīng)用層ACK機(jī)制一樣,離線消息拉時,不能夠直接刪除數(shù)據(jù)庫中的離線消息,而必須等應(yīng)用層的離線消息ACK(說明用戶B真的收到離線消息了),才能刪除數(shù)據(jù)庫中的離線消息。


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

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

服務(wù)端交互加倍

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

離線消息拉取過程優(yōu)化4

回答:不用每一頁消息都ACK,在拉取第二頁消息時相當(dāng)于第一頁消息的ACK,此時服務(wù)器再刪除第一頁的離線消息即可,最后一頁消息再ACK一次。這樣的效果是,不管拉取多少頁離線消息,只會多一個ACK請求,與服務(wù)器多一次交互。


總結(jié)

“離線消息”的可達(dá)性可能比大家想象的要復(fù)雜,常見的優(yōu)化有:

(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ù)


即時通訊系統(tǒng)中,消息的可達(dá)性,狀態(tài)的一致性都是很有意思的話題,關(guān)于“群消息”的在線投遞與離線拉取還沒有介紹過,如果大家感興趣,后續(xù)可以一起探討


以上內(nèi)容是否對您有幫助:
在線筆記
App下載
App下載

掃描二維碼

下載編程獅App

公眾號
微信公眾號

編程獅公眾號