成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

微信為什么不丟消息?

開發 開發工具
本章來聊一聊即時通訊(Instant Messaging,后簡稱im)消息的可靠投遞。

上一章和大家分享了《http如何像tcp一樣實時的收消息?》, 本章來聊一聊即時通訊(Instant Messaging,后簡稱im)消息的可靠投遞。

一、報文類型

im的客戶端與服務器通過發送報文(也就是網絡包)來完成消息的傳遞,報文分為三種

請求報文(request,后簡稱為為R)

應答報文(acknowledge,后簡稱為A)

通知報文(notify,后簡稱為N),這三種報文的解釋如下:

R:客戶端主動發送給服務器的報文

A:服務器被動應答客戶端的報文,一個A對應一個R

N:服務器主動發送給客戶端的報文

二、普通消息投遞流程

用戶A給用戶B發送一個“你好”,流程如下:

 

 

1)client-A向im-server發送一個消息請求包,即msg:R

2)im-server在成功處理后,回復client-A一個消息響應包,即msg:A

3)如果此時client-B在線,則im-server主動向client-B發送一個消息通知包,即msg:N(當然,如果client-B不在線,則消息會存儲離線)

三、上述消息投遞流程出現的問題

從流程圖中容易看到,發送方client-A收到msg:A后,只能說明im-server成功接收到了消息,并不能說明client-B接收到了消息。在若干場景下,可能出現msg:N包丟失,且發送方client-A完全不知道,例如:

1)服務器崩潰,msg:N包未發出

2)網絡抖動,msg:N包被網絡設備丟棄

3)client-B崩潰,msg:N包未接收

結論是悲觀的:接收方client-B是否有收到msg:N,發送方client-A完全不可控,那怎么辦呢?

四、應用層確認+im消息可靠投遞的六個報文

upd是一種不可靠的傳輸層協議,tcp是一種可靠的傳輸層協議,tcp是如何做到可靠的?答案是:超時、重傳、確認。

要想實現應用層的消息可靠投遞,必須加入應用層的確認機制,即:要想讓發送方client-A確保接收方client-B收到了消息,必須讓接收方client-B給一個消息的確認,這個應用層的確認的流程,與消息的發送流程類似:

 

 

4)client-B向im-server發送一個ack請求包,即ack:R

5)im-server在成功處理后,回復client-B一個ack響應包,即ack:A

6)則im-server主動向client-A發送一個ack通知包,即ack:N

至此,發送“你好”的client-A,在收到了ack:N報文后,才能確認client-B真正接收到了“你好”。

會發現,一條消息的發送,分別包含(上)(下)兩個半場,即msg的R/A/N三個報文,ack的R/A/N三個報文,一個應用層即時通訊消息的可靠投遞,共涉及6個報文,這就是im系統中消息投遞的最核心技術。

五、可靠消息投遞存在什么問題

期望六個報文完成消息的可靠投遞,但實際情況,msg:N,ack:N這兩個報文都可能丟失(原因如第二章所述,可能是服務器奔潰、網絡抖動、或者客戶端奔潰),此時client-A都收不到期待的ack:N報文,即client-A不能確認client-B是否收到“你好”,但這兩個報文的丟失對應的業務影響又大有不同:

1)msg:N包丟失,業務結果是client-B沒有收到消息

2)ack:N包丟失,業務結果是client-B收到了消息,只是client-A不知道而已

那怎么辦呢?

六、消息的超時與重傳

client-A發出了msg:R,收到了msg:A之后,在一個期待的時間內,如果沒有收到ack:N,client-A會嘗試將msg:R重發??赡躢lient-A同時發出了很多消息,故client-A需要在本地維護一個等待ack隊列,并配合timer超時機制,來記錄哪些消息沒有收到ack:N,以定時重發。

 

 

一旦收到了ack:N,說明client-B收到了“你好”消息,對應的消息將從“等待ack隊列”中移除。

七、消息的重傳存在什么問題

第五章提到過,msg:N,ack:N都有可能丟失:

1)msg:N報文丟失,說明client-B之前壓根沒有收到“你好”報文,超時與重傳機制十分有效

2)ack:N報文丟失,說明client-B之前已經收到了“你好”報文(只是client-A不知道而已),超時與重傳機制將導致client-B收到重復的消息,那怎么辦呢?

八、消息的去重

解決方法也很簡單,由發送方client-A生成一個消息去重的msgid,保存在“等待ack隊列”里,同一條消息使用相同的msgid來重傳,供client-B去重,而不影響用戶體驗。

九、其他

1)上述設計理念,由客戶端重傳,可以保證服務端無狀態性(架構設計基本準則)

2)如果client-B不在線,im-server保存了離線消息后,要偽造ack:N發送給client-A

十、總結

1)im系統是通過超時、重傳、確認、去重的機制來保證消息的可靠投遞,不丟不重

2)一個“你好”的發送,包含上半場msg:R/A/N與下半場ack:R/A/N的6個報文

3)im系統難以做到系統層面的不丟不重,只能做到業務層面的不丟不重

文章轉載自微信公眾號“架構師之路”

責任編輯:趙寧寧 來源: 架構師之路
相關推薦

2016-11-02 13:12:31

微信離線消息

2021-03-08 10:19:59

MQ消息磁盤

2025-03-31 10:49:16

2025-04-15 09:00:00

2025-04-17 09:00:00

架構聊消息微信

2020-10-26 09:19:11

線程池消息

2016-11-01 15:16:52

QQ狀態即時通訊

2023-08-02 07:35:03

微信用戶隱私內容安全

2025-06-12 09:46:15

2022-07-15 15:11:27

SQLite微信數據庫

2020-05-09 14:53:46

爬蟲數據微信

2020-12-14 13:18:20

微信空間清理文件

2016-11-10 21:00:49

消息存儲數據

2024-04-09 09:08:09

Kafka消息架構

2021-07-04 14:19:03

RabbitMQ消息轉換

2020-08-05 15:04:13

微信支付寶移動應用

2013-04-08 16:19:40

微信微信公眾平臺圖文消息

2023-09-05 09:49:03

2018-07-10 15:41:37

2020-03-27 12:15:36

微信朋友圏騰訊
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 91精品国产综合久久国产大片 | 国产一区二区免费 | 亚洲精品大全 | 黄色网一级片 | 久久久网| 成人免费观看男女羞羞视频 | 精品av| 亚洲一区国产精品 | av在线播放不卡 | 欧美黑人狂野猛交老妇 | 国产精品久久久一区二区三区 | 欧美精品免费观看二区 | 国产精品久久久久久久久久久免费看 | 成人av播放 | 午夜在线免费观看视频 | 久久伊人精品一区二区三区 | 97久久精品午夜一区二区 | 欧州一区二区三区 | 亚洲电影一区二区三区 | 国产精品久久久久久二区 | 日韩精品一区二区三区中文在线 | 国产1区2区 | 久久亚洲综合 | 久久尤物免费一区二区三区 | 一区二区在线免费观看 | 日韩成人精品在线观看 | 91久色| 国产一区二区高清在线 | 精品国产18久久久久久二百 | 一本岛道一二三不卡区 | 性高湖久久久久久久久aaaaa | 色屁屁在线观看 | 国产精彩视频一区 | 日本免费在线观看视频 | 玖玖综合网 | 日日欧美 | 国产网站在线播放 | 日韩国产免费 | 欧美一区视频 | 欧美极品在线视频 | 国产福利在线免费观看 |