怎麼找活躍度高的本地群?繼續答球友提問：(1)群離線消息是推還是拉？，我來為大家科普一下關于怎麼找活躍度高的本地群?以下内容希望對你有幫助!

怎麼找活躍度高的本地群

繼續答球友提問：

(1)群離線消息是推還是拉？

(2)幾萬條群離線消息，怎麼保證不丢失？

群離線消息，是推還是拉？

關于寫擴散、讀擴散的問題，之前專門撰文寫過，今天不直接同步結論，重點說說設計的思考過程。

畫外音：結論不如思路重要。

假如群離線是推，流程應該如何？會遇到什麼問題？

先看看群離線消息的核心數據結構。

群成員表：

t_group_users(group_id, user_id)

畫外音：用來描述一個群裡有多少成員。

群離線消息表：

t_offine_msgs(user_id, group_id, sender_id,time, msg_id, msg_detail)

畫外音：用來描述一個群成員的離線消息。

推，寫擴散，存儲群離線消息的過程如何？

(1)先從群成員表中，獲取群裡有多少個用戶；

(2)從某個服務中，獲取這些用戶有多少個不在線；

(3)将群消息，插入到這些用戶的群離線消息表；

畫外音：如果要支持消息漫遊，則可以省略步驟二。

此時，用戶拉取離線消息的過程如何？

(1)用戶登錄，向server拉取離線消息；

(2)server返回并删除離線消息；

離線消息推，存在什麼問題？

對于同一份群消息的内容，多個離線用戶要存儲很多份。假設群中有200個用戶離線，離線消息則冗餘了200份，這極大的增加了數據庫的存儲壓力。

如何優化，減少消息冗餘量？

為了減少離線消息的冗餘度，增加一個群消息表，用來存儲所有群消息的内容，離線消息表隻存儲用戶的群離線消息msg_id，就能大大的降低數據庫的冗餘存儲量。

群消息表：

t_group_msgs(group_id, sender_id, time, msg_id, msg_detail)

畫外音：用來存儲一個群中所有的消息内容。

群離線消息表，需要進行優化：

t_offine_msgs(user_id, group_id, msg_id)

畫外音：優化後隻存儲msg_id。

這樣優化後，群消息的發送和存儲要做一些升級：

(1)每次發送群消息之前，先存儲群消息的内容；

(2)每次存儲離線消息時，隻存儲msg_id，而不用為每個用戶存儲msg_detail；

相應的，拉取離線消息也要做對應的升級：

(1)先拉取所有的離線消息msg_id；

(2)再根據msg_id拉取msg_detail；

(3)删除時，隻删除自己的離線msg_id，而不删除msg_detail；

畫外音：畢竟msg_detail隻存儲了一份，不能随便删。

上述過程，能保證離線消息的可達性麼？

不能。

例如：server返回客戶端離線消息之後，删除了離線消息，但客戶端沒有展現就奔潰了，離線消息就會丢失。

如何解決離線消息可達性呢？

很容易想到，通過ACK機制，server返回離線消息之後，不能立刻删除離線消息，而必須等客戶端ACK，才能删除。

此時，離線消息拉取升級為：

(1)用戶登錄，向server拉取離線消息；

(2)server返回離線消息；

(3)客戶端确認收到了離線消息；

(4)server再删除離線消息；

畫外音：增加了3和4兩個步驟。

還有一個問題，一次有幾十個群，每個群有幾千條離線消息，共計幾萬條群離線消息，消息量過大怎麼辦？

當然不能一次性拉取，可以：

(1)分群拉取；

(2)每個群分頁拉取；

(3)拉取一頁，删除一頁，拉取下一頁，删除下一頁...

如果拉取了消息，卻沒來得及應用層ACK，會收到重複的消息麼？

可以在客戶端去重，對于重複的msg_id，對用戶不展現，從而不影響用戶體驗。

如上所示，簡單總結就是：

(1)群消息表存儲消息實體msg_detail；

(2)群離線消息表，存每個用戶的msg_id；

(3)分頁拉取 應用層ACK，即保證性能，又保證消息可達性；

(4)客戶端msg_id去重，保證用戶體驗；

上面講的都是“推”模式，群離線消息的設計，真正線上應用較多的，是“拉”模式。

推模式，存在什麼問題？

對于離線的每一條消息，雖然隻存儲了msg_id，但是每個用戶的每一條離線消息都将在數據庫中保存一條記錄，有沒有辦法減少離線消息的記錄數呢？

對于一個群用戶，在ta登出後的離線期間内，肯定是所有的群消息都沒有收到的，完全不用對所有的每一條離線消息存儲一個離線msg_id，而隻需要存儲最近一條拉取到的離線消息的time（或者msg_id），下次登錄時拉取在那之後的所有群消息即可，而完全沒有必要存儲每個人未拉取到的全部離線消息msg_id。

拉模式，需要對數據結構進行怎樣的升級？

群成員表，增加一個屬性：

t_group_users(group_id, user_id, last_ack_msg_id)

畫外音：用來描述一個群裡有多少成員，以及每個成員最後一條ack的群消息的msg_id（或者time）。

群消息表，不變：

t_group_msgs(group_id, sender_id, time, msg_id, msg_detail)

畫外音：還是用來存儲一個群中所有的消息内容。

群離線消息表：不再需要。

使用拉模式後，群消息的發送和存儲也要升級：

(1)在消息msg_detail存儲到群消息表後，不再需要操作離線消息表（之前需要将msg_id插入離線消息表）；

(2)用戶收到消息，應用層ACK後，将last_ack_msg_id更新（之前需要将msg_id從離線消息表删除）；

群離線消息的拉取流程也類似：

(1)分頁拉取離線消息；

(2)ACK離線消息；

(3)更新last_ack_msg_id；

總結

群消息還是非常有意思的，做個簡單總結：

(1)群離線消息一般采用拉取模式，隻存一份，不需要為每個用戶存儲離線群msg_id，隻需存儲一個最近ack的群消息id/time；

(2)為了保證消息可達性，在線消息和離線消息都需要ACK；

(3)離線消息過多，可以分群拉取、分頁拉取等優化；

畫外音：還可按需拉取，登錄不拉取，點進群再拉取。

(4)如果收到重複消息，需要msg_id去重，讓用戶無感知；

來源： 58沈劍 架構師之路

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!