偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

群消息,究竟存一份還是多份?

開發(fā) 架構(gòu)
昨天的文章發(fā)布后,有朋友反問:你憑什么默認(rèn)群消息只存儲(chǔ)了一份?今天來聊聊這個(gè)問題。

昨天《群消息已讀回執(zhí),為什么這么難?》,有朋友反問:你憑什么默認(rèn)群消息只存儲(chǔ)了一份?今天來聊聊這個(gè)問題。

群消息,究竟存一份還是多份?

任何技術(shù)方案,都不是天才般靈感乍現(xiàn)想到的,一定是一個(gè)演進(jìn)迭代,逐步優(yōu)化的過程。

群信息,用戶信息,群成員關(guān)系都是基礎(chǔ)數(shù)據(jù):

group_info(gid, group_info);
user_info(uid, user_info);
group_members(gid, uid);

假設(shè)一個(gè)群(gid)里有4個(gè)成員,其中:

  • 三個(gè)在線(A, uid1, uid2);
  • 一個(gè)不在線(uid3);

A發(fā)送了一條消息,很容易想到,對(duì)于不同的群友消息存多份,每個(gè)群友一個(gè)隊(duì)列來存儲(chǔ)。但由于在線的用戶會(huì)實(shí)時(shí)的收到消息,所以暫定只為離線的用戶存儲(chǔ)。

用戶收到的群消息,也是基礎(chǔ)數(shù)據(jù):

user_msgs(uid,msgid,gid,sender_uid,time,content);

很容易想到,整個(gè)群消息的發(fā)送流程如上圖1-4:

  • 發(fā)送消息;
  • 查詢狀態(tài);
  • 不在線的存儲(chǔ)離線;
  • 在線的實(shí)時(shí)推送;

“在線的群友不存儲(chǔ),離線的群友才存儲(chǔ)”會(huì)帶來的問題是,如果第四步發(fā)生異常,群友會(huì)丟失消息。

消息的可達(dá)性是聊天系統(tǒng)中最重要的要素(沒有之一),故這個(gè)方案是不行的,需要優(yōu)化為“不管是否在線,都要先存儲(chǔ)”。

發(fā)送群消息的流程優(yōu)化為,如上圖1-4:

  • 發(fā)送消息;
  • 所有人都存一份;
  • 查詢狀態(tài);
  • 在線的實(shí)時(shí)推送;

先將消息落地,能夠保證消息可達(dá)性,那何時(shí)才能刪除已經(jīng)落地的群消息呢?

對(duì)于在線的群友,收到群消息后,給個(gè)ack確認(rèn),才能刪除。

畫外音:邏輯刪除,還是物理刪除,根據(jù)業(yè)務(wù)是否有消息漫游決定。

對(duì)于離線的群友,在下次登陸后,拉取完離線消息,再給ack確認(rèn),才能刪除。

總之,為了保證消息的可達(dá)性,不管是在線消息,還是離線消息,必須接收方給ack確認(rèn),才能刪除消息。

“不管是否在線,都冗余一份群消息”帶來的問題是,同一條消息存儲(chǔ)了很多次,對(duì)磁盤和帶寬造成了很大的浪費(fèi)。很容易想到的優(yōu)化是:群消息實(shí)體存儲(chǔ)一份,用戶只冗余消息ID。

故基礎(chǔ)數(shù)據(jù)可以由:

user_msgs(uid,msgid,gid,sender_uid,time,content);

優(yōu)化為:

group_msgs(msgid,gid,sender_uid,time,content);
user_msgs(uid, msgid, gid);

這個(gè)優(yōu)化,對(duì)于消息投遞,以及消息刪除的核心流程沒有影響,幾個(gè)實(shí)踐為:

  • 在線用戶投遞消息實(shí)體,ack消息ID;
  • 離線用戶先拉取消息ID,再拉取消息實(shí)體,再ack消息ID;

如此這般,假如在某個(gè)群友A期間,群里陸續(xù)發(fā)送了N條消息,則user_msgs(uid, msgid, gid)里,會(huì)有 uidA -> mid1,mid2, mid3, … midN 等N條離線記錄,拉取離線消息時(shí),可以把這N條消息一次性拉取出來,然后再刪除:

delete from user_msgs 
    where msgid in($mid1,$mid2…, $midN) and gid=$gid

然而,群消息具備“偏序”特性,上面的一次性刪除完全可以優(yōu)化為:

delete from user_msgs 
    where msgid >= $mid1 and gid=$gid

這就意味著,每個(gè)用戶只需要記錄“最近一次收到的消息ID”,而不用記錄“所有未收到的消息ID集合”,每當(dāng)收在線消息ack,以及拉離線消息ack時(shí),只需要更新這個(gè)“最近一次收到的消息ID”即可。

于是乎,基礎(chǔ)數(shù)據(jù)可以由:

group_members(gid, uid);
group_msgs(msgid,gid,sender_uid,time,content);
user_msgs(uid, msgid, gid);

優(yōu)化為:

group_members(gid, uid, last_ack_msgid);
group_msgs(msgid,gid,sender_uid,time,content);
user_msgs(uid, msgid, gid); // 不再需要

即,群消息只存儲(chǔ)一份,群友無需冗余任何消息實(shí)體,或者消息ID了。

對(duì)于在線的群友,收到群消息后,修改這個(gè)last_ack_msgid。

對(duì)于離線的群友,拉取群消息后,也修改這個(gè)last_ack_msgid。

畫外音:這里的討論,僅限于接收方收到了哪些消息,和發(fā)送方的已讀回執(zhí)沒有關(guān)系。

總結(jié)

任何架構(gòu)方案都不是靈光一現(xiàn),而是逐步迭代優(yōu)化產(chǎn)生的。

  • 最開始:存多份,只存在線,消息容易丟;
  • 進(jìn)化:存多份,所有群友都存儲(chǔ),消息冗余多;
  • 進(jìn)化:存多份,只存ID,未利用偏序;
  • 最終:存一份,只存last_ack_msgid;

任何脫離業(yè)務(wù)的架構(gòu)設(shè)計(jì)都是耍流氓。

知其然,知其所以然。

思路比結(jié)論更重要。

責(zé)任編輯:趙寧寧 來源: 架構(gòu)師之路
相關(guān)推薦

2021-01-12 07:44:13

群消息在線

2021-06-24 08:30:08

架構(gòu)億級(jí)消息中心數(shù)據(jù)

2019-03-24 14:14:40

代碼閱讀源代碼

2021-04-03 12:44:16

編程語言數(shù)據(jù)Python

2022-04-29 08:48:25

開源

2018-03-09 10:28:30

生態(tài)報(bào)告簽收

2020-07-15 15:38:15

人臉識(shí)別照片活化手機(jī)

2019-03-15 15:15:12

硬盤SSD閃存

2009-03-11 13:32:12

簡(jiǎn)歷求職應(yīng)聘

2015-03-19 15:17:11

2018-07-29 15:33:04

2016-08-24 16:55:18

DevOps結(jié)構(gòu)清單

2023-09-29 22:41:26

Kubernetes云原生

2019-12-03 10:28:53

編程語言PythonJava

2018-05-03 07:06:21

開發(fā)規(guī)范iOS

2024-11-07 08:50:56

用戶分析分類維度標(biāo)簽

2023-09-01 14:02:25

用戶分析攻略

2017-05-05 11:25:43

2013-03-04 17:51:59

華為CIE職業(yè)生涯

2024-10-24 20:56:36

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)