每當發出一條微信消息,都希望對方儘快看到,並儘快回覆,但始終不知道對方是否閱讀。
每當收到一條不能立馬回覆的微信消息,都默默返回,假裝沒看見。
畫外音:不想回復的人,唉,你只是個好人。
微信用於個人社交,產品設計上,在線狀態,強制已讀回執都有可能暴露個人隱私,故微信並無相關功能。
釘釘用於商務交流,其“強制已讀回執”功能,讓職場人無法再“假裝不在線”,“假裝沒收到”。
有甚者,釘釘的群有“強制已讀回執”功能,你在群裡發出的消息,能夠知道誰讀了消息,誰沒有讀消息。
群消息的流程如何,接收方如何確保收到群消息,發送方如何收已讀回執,究竟是拉取,還是推送,是今天要討論的問題。
一、群消息投遞流程,以及可達性保證
大家一起跟著樓主的節奏,一步一步來看群消息怎麼設計。
核心問題1:群消息,只存一份?還是,每個成員存一份?
答:存一份,為每個成員設置一個群消息隊列,會有大量數據冗餘,並不合適。
核心問題2:如果群消息只存一份,怎麼知道每個成員讀了哪些消息?
答:可以利用群消息的偏序關係,記錄每個成員的last_ack_msgid(last_ack_time),這條消息之前的消息已讀,這條消息之後的消息未讀。該方案意味著,對於群內的每一個用戶,只需要記錄一個值即可。
解答上述兩個核心問題後,很容易得到群消息的核心數據結構。
群消息表:記錄群消息。
group_msgs(msgid, gid, sender_uid, time, content);
各字段的含義為:消息ID,群ID,發送方UID,發送時間,發送內容。
群成員表:記錄群裡的成員,以及每個成員收到的最後一條群消息。
group_users(gid, uid, last_ack_msgid);
各字段的含義為:群ID,群成員UID,群成員最後收到的一條群消息ID。
在核心數據結構設計完之後,一起來看看群消息發送的流程。
業務場景:
(1)一個群中有A, uid1, uid2, uid3四名成員
(2)A, uid1, uid2在線,期望實時收到在線消息
(3)uid3離線,期望未來拉取到離線消息
其整個消息發送的流程1-4如上圖:
(1)A發出群消息
(2)server收到消息後,一來要將群消息落地,二來要查詢群裡有哪些群成員,以便實施推送
(3)對於群成員,查詢在線狀態
(4)對於在線的群成員,實施推送
這個流程裡,只要第二步消息落地完成,就能保證群消息不會丟失。
核心問題3:如何保證接收方一定收到群消息?
答:各個收到消息後,要修改各群成員的last_ack_msgid,以告訴系統,這一條消息確認收到了。
在線消息,離線消息的last_ack_msgid的修改,又各有不同。
對於在線的群友,收到群消息後,第一時間會ack,修改last_ack_msgid。
對於離線的群友,會在下一次登錄時,拉取未讀的所有群離線消息,並將last_ack_msgid修改為最新的一條消息。
核心問題4:如果ack丟失,群友會不會拉取重複的群消息?
答:會,可以根據msgid在客戶端本地做去重,即使系統層面收到了重複的消息,仍然可以保證良好的用戶體驗。
上述流程,只能確保接收方收到消息,發送方仍然不知道哪些人在線閱讀了消息,哪些人離線未閱讀消息,並沒有實現已讀回執,那已讀回執會對系統設計產生什麼樣的影響呢?
二、已讀回執流程
對於發送方發送的任何一條群消息,都需要知道,這條消息有多少人已讀多少人未讀,就需要一個基礎表來記錄這個關係。
消息回執表:用來記錄消息的已讀回執。
msg_acks(sender_uid, msgid, recv_uid, gid,if_ack);
各字段的含義為:發送方UID,消息ID,回執方UID,群ID,回執標記。
增加了已讀回執邏輯後,群消息的流程會有細微的改變。
步驟二,server收到消息後,除了要:
- 將群消息落地
- 查詢群裡有哪些群成員,以便實施推送
之外,還需要:
- 插入每條消息的初始回執狀態
接收方修改last_ack_msgid的流程,會變為:
(1)發送ack請求
(2)修改last_ack_msgid,並且,修改已讀回執if_ack狀態
(3)查詢發送方在線狀態
(4)向發送方實時推送已讀回執(如果發送方在線)
如果發送方不在線,ta會在下次登錄的時候:
(5)從關聯表裡拉取每條消息的已讀回執
這裡的初步結論是:
- 如果發送方在線,會實時被推送已讀回執
- 如果發送方不在線,會在下次在線時拉取已讀回執
三、流程優化方案
再次詳細的分析下,群消息已讀回執的“消息風暴擴散係數”,假設每個群有200個用戶,其中20%的用戶在線,即40各用戶在線。群用戶每發送一條群消息,會有:
- 40個消息,通知給群友
- 40個ack修改last_ack_msgid,發給服務端
- 40個已讀回執,通知給發送方
可見,其消息風暴擴散係數非常之大。
同時:
- 需要存儲40條ack記錄
群數量,群友數量,群消息數量越來越多之後,存儲也會成為問題。
是否有優化方案呢?
群消息的推送,能否改為接收方輪詢拉取?
答:不能,消息接收,實時性是核心指標。
對於last_ack_msgid的修改,真的需要每個群消息都進行ack麼?
答:其實不需要,可以批量ack,累計收到N條群消息(例如10條),再向服務器發送一次last_ack_msgid的修改請求,同時修改這個請求之前所有請求的已讀回執,這樣就能將40個發送給服務端的ack請求量,降為原來的1/10。
會帶來什麼副作用?
答:last_ack_msgid的作用是,記錄接收方最近新取的一條群消息,如果不實時更新,可能導致,異常退出時,有一些群消息沒來得及更新last_ack_msgid,使得下次登陸時,拉取到重複的群消息。但這不是問題,客戶端可以根據msgid去重,用戶體驗不會受影響。
發送方在線時,對於已讀回執的發送,真的需要實時推送麼?
答:其實不需要,發送方每發一條消息,會收到40個已讀回執,採用輪詢拉取(例如1分鐘一次,一個小時也就60個請求),可以大大降低請求量。
畫外音:或者直接放到應用層keepalive請求裡,做到0額外請求增加。
會帶來什麼副作用?
答:已讀回執更新不實時,最壞的情況下,1分鐘才更新回執。當然,可以根據性能與產品體驗來折衷配置這個輪詢時間。
如何降低數據量?
答:回執數據不是核心數據
- 已讀的消息,可以進行物理刪除,而不是標記刪除
- 超過N長時間的回執,歸檔或者刪除掉
四、總結
對於群消息已讀回執,一般來說:
- 如果發送方在線,會實時被推送已讀回執
- 如果發送方不在線,會在下次在線時拉取已讀回執
如果要對進行優化,可以:
- 接收方累計收到N條群消息再批量ack
- 發送方輪詢拉取已讀回執
- 物理刪除已讀回執數據,定時刪除或歸檔非核心歷史數據
推送還是拉取?
任何脫離業務的架構設計都是耍流氓。
相關推薦:
《 》
閱讀更多 互聯網架構師之路 的文章