繼續(xù)答球友提問(wèn)：

• 群離線(xiàn)消息是推還是拉?
• 幾萬(wàn)條群離線(xiàn)消息，怎么保證不丟失?

群離線(xiàn)消息，是推還是拉?

關(guān)于寫(xiě)擴(kuò)散、讀擴(kuò)散的問(wèn)題，之前專(zhuān)門(mén)撰文寫(xiě)過(guò)，今天不直接同步結(jié)論，重點(diǎn)說(shuō)說(shuō)設(shè)計(jì)的思考過(guò)程。

畫(huà)外音：結(jié)論不如思路重要。

假如群離線(xiàn)是推，流程應(yīng)該如何?會(huì)遇到什么問(wèn)題?

先看看群離線(xiàn)消息的核心數(shù)據(jù)結(jié)構(gòu)。

群成員表：

t_group_users(group_id, user_id) 

畫(huà)外音：用來(lái)描述一個(gè)群里有多少成員。

群離線(xiàn)消息表：

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

畫(huà)外音：用來(lái)描述一個(gè)群成員的離線(xiàn)消息。

推，寫(xiě)擴(kuò)散，存儲(chǔ)群離線(xiàn)消息的過(guò)程如何?

• 先從群成員表中，獲取群里有多少個(gè)用戶(hù);
• 從某個(gè)服務(wù)中，獲取這些用戶(hù)有多少個(gè)不在線(xiàn);
• 將群消息，插入到這些用戶(hù)的群離線(xiàn)消息表;

畫(huà)外音：如果要支持消息漫游，則可以省略步驟二。

此時(shí)，用戶(hù)拉取離線(xiàn)消息的過(guò)程如何?

• 用戶(hù)登錄，向server拉取離線(xiàn)消息;
• server返回并刪除離線(xiàn)消息;

離線(xiàn)消息推，存在什么問(wèn)題?

對(duì)于同一份群消息的內(nèi)容，多個(gè)離線(xiàn)用戶(hù)要存儲(chǔ)很多份。假設(shè)群中有200個(gè)用戶(hù)離線(xiàn)，離線(xiàn)消息則冗余了200份，這極大的增加了數(shù)據(jù)庫(kù)的存儲(chǔ)壓力。

如何優(yōu)化，減少消息冗余量?

為了減少離線(xiàn)消息的冗余度，增加一個(gè)群消息表，用來(lái)存儲(chǔ)所有群消息的內(nèi)容，離線(xiàn)消息表只存儲(chǔ)用戶(hù)的群離線(xiàn)消息msg_id，就能大大的降低數(shù)據(jù)庫(kù)的冗余存儲(chǔ)量。

群消息表：

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

畫(huà)外音：用來(lái)存儲(chǔ)一個(gè)群中所有的消息內(nèi)容。

群離線(xiàn)消息表，需要進(jìn)行優(yōu)化：

t_offine_msgs(user_id, group_id, msg_id) 

畫(huà)外音：優(yōu)化后只存儲(chǔ)msg_id。

這樣優(yōu)化后，群消息的發(fā)送和存儲(chǔ)要做一些升級(jí)：

• 每次發(fā)送群消息之前，先存儲(chǔ)群消息的內(nèi)容;
• 每次存儲(chǔ)離線(xiàn)消息時(shí)，只存儲(chǔ)msg_id，而不用為每個(gè)用戶(hù)存儲(chǔ)msg_detail;

相應(yīng)的，拉取離線(xiàn)消息也要做對(duì)應(yīng)的升級(jí)：

• 先拉取所有的離線(xiàn)消息msg_id;
• 再根據(jù)msg_id拉取msg_detail;
• 刪除時(shí)，只刪除自己的離線(xiàn)msg_id，而不刪除msg_detail;

畫(huà)外音：畢竟msg_detail只存儲(chǔ)了一份，不能隨便刪。

上述過(guò)程，能保證離線(xiàn)消息的可達(dá)性么?

不能。

例如：server返回客戶(hù)端離線(xiàn)消息之后，刪除了離線(xiàn)消息，但客戶(hù)端沒(méi)有展現(xiàn)就奔潰了，離線(xiàn)消息就會(huì)丟失。

如何解決離線(xiàn)消息可達(dá)性呢?

很容易想到，通過(guò)ACK機(jī)制，server返回離線(xiàn)消息之后，不能立刻刪除離線(xiàn)消息，而必須等客戶(hù)端ACK，才能刪除。

此時(shí)，離線(xiàn)消息拉取升級(jí)為：

• 用戶(hù)登錄，向server拉取離線(xiàn)消息;
• server返回離線(xiàn)消息;
• 客戶(hù)端確認(rèn)收到了離線(xiàn)消息;
• server再刪除離線(xiàn)消息;

畫(huà)外音：增加了3和4兩個(gè)步驟。

還有一個(gè)問(wèn)題，一次有幾十個(gè)群，每個(gè)群有幾千條離線(xiàn)消息，共計(jì)幾萬(wàn)條群離線(xiàn)消息，消息量過(guò)大怎么辦?

當(dāng)然不能一次性拉取，可以：

• 分群拉取;
• 每個(gè)群分頁(yè)拉取;
• 拉取一頁(yè)，刪除一頁(yè)，拉取下一頁(yè)，刪除下一頁(yè)...

如果拉取了消息，卻沒(méi)來(lái)得及應(yīng)用層ACK，會(huì)收到重復(fù)的消息么?

可以在客戶(hù)端去重，對(duì)于重復(fù)的msg_id，對(duì)用戶(hù)不展現(xiàn)，從而不影響用戶(hù)體驗(yàn)。

如上所示，簡(jiǎn)單總結(jié)就是：

• 群消息表存儲(chǔ)消息實(shí)體msg_detail;
• 群離線(xiàn)消息表，存每個(gè)用戶(hù)的msg_id;
• 分頁(yè)拉取+應(yīng)用層ACK，即保證性能，又保證消息可達(dá)性;
• 客戶(hù)端msg_id去重，保證用戶(hù)體驗(yàn);

上面講的都是“推”模式，群離線(xiàn)消息的設(shè)計(jì)，真正線(xiàn)上應(yīng)用較多的，是“拉”模式。

推模式，存在什么問(wèn)題?

對(duì)于離線(xiàn)的每一條消息，雖然只存儲(chǔ)了msg_id，但是每個(gè)用戶(hù)的每一條離線(xiàn)消息都將在數(shù)據(jù)庫(kù)中保存一條記錄，有沒(méi)有辦法減少離線(xiàn)消息的記錄數(shù)呢?

對(duì)于一個(gè)群用戶(hù)，在ta登出后的離線(xiàn)期間內(nèi)，肯定是所有的群消息都沒(méi)有收到的，完全不用對(duì)所有的每一條離線(xiàn)消息存儲(chǔ)一個(gè)離線(xiàn)msg_id，而只需要存儲(chǔ)最近一條拉取到的離線(xiàn)消息的time(或者msg_id)，下次登錄時(shí)拉取在那之后的所有群消息即可，而完全沒(méi)有必要存儲(chǔ)每個(gè)人未拉取到的全部離線(xiàn)消息msg_id。

拉模式，需要對(duì)數(shù)據(jù)結(jié)構(gòu)進(jìn)行怎樣的升級(jí)?

群成員表，增加一個(gè)屬性：

t_group_users(group_id, user_id, last_ack_msg_id) 

畫(huà)外音：用來(lái)描述一個(gè)群里有多少成員，以及每個(gè)成員最后一條ack的群消息的msg_id(或者time)。

群消息表，不變：

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

畫(huà)外音：還是用來(lái)存儲(chǔ)一個(gè)群中所有的消息內(nèi)容。

群離線(xiàn)消息表：不再需要。

使用拉模式后，群消息的發(fā)送和存儲(chǔ)也要升級(jí)：

• 在消息msg_detail存儲(chǔ)到群消息表后，不再需要操作離線(xiàn)消息表(之前需要將msg_id插入離線(xiàn)消息表);
• 用戶(hù)收到消息，應(yīng)用層ACK后，將last_ack_msg_id更新(之前需要將msg_id從離線(xiàn)消息表刪除);

群離線(xiàn)消息的拉取流程也類(lèi)似：

• 分頁(yè)拉取離線(xiàn)消息;
• ACK離線(xiàn)消息;
• 更新last_ack_msg_id;

總結(jié)

群消息還是非常有意思的，做個(gè)簡(jiǎn)單總結(jié)：

• 群離線(xiàn)消息一般采用拉取模式，只存一份，不需要為每個(gè)用戶(hù)存儲(chǔ)離線(xiàn)群msg_id，只需存儲(chǔ)一個(gè)最近ack的群消息id/time;
• 為了保證消息可達(dá)性，在線(xiàn)消息和離線(xiàn)消息都需要ACK;
• 離線(xiàn)消息過(guò)多，可以分群拉取、分頁(yè)拉取等優(yōu)化;

畫(huà)外音：還可按需拉取，登錄不拉取，點(diǎn)進(jìn)群再拉取。

• 如果收到重復(fù)消息，需要msg_id去重，讓用戶(hù)無(wú)感知;

【本文為51CTO專(zhuān)欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文