群訊息，究竟存乙份還是多份？任何技術方案，都不是天才般靈感乍現想到的，一定是乙個演進迭代，逐步優化的過程。今天就聊一聊，
群訊息，為啥只需要存乙份
。
群資訊，使用者資訊，群成員關係都是基礎資料：
group_info(gid, group_info);
user_info(uid, user_info);
group_members(gid, uid);
假設乙個群(gid)裡有4個成員，其中：
使用者收到的群訊息，也是基礎資料：
(1)傳送訊息；
(2)查詢狀態；
(1)傳送訊息；
(2)所有人都存乙份；
(3)查詢狀態；
先將訊息落地，能夠保證訊息可達性，那何時才能刪除已經落地的群訊息呢？畫外音：邏輯刪除，還是物理刪除，根據業務是否有訊息漫遊決定。
離線的群友，在下次登陸後，拉取完離線訊息，再給ack確認，才能刪除。
user_msgs(uid,msgid,gid,sender_uid,time,content);
優化為：
group_msgs(msgid,gid,sender_uid,time,content);
user_msgs(uid, msgid, gid);
這個優化，對於訊息投遞，以及訊息刪除的核心流程沒有影響，幾個實踐為：
(2)離線使用者先拉取訊息id，再拉取訊息實體，再ack訊息id；
如此這般，假如在某個群友a期間，群裡陸續傳送了n條訊息，則user_msgs(uid, msgid, gid)裡，會有 uida -> mid1,mid2, mid3, … midn 等n條離線記錄，拉取離線訊息時，可以把這n條訊息一次性拉取出來，然後再刪除：
delete from user_msgs
where msgid in($mid1,$mid2…, $midn) and gid=$gid
然而，群訊息具備「偏序」特性，上面的一次性刪除完全可以優化為：
delete from user_msgs
where msgid >= $mid1 and gid=$gid
於是乎，基礎資料可以由：
group_members(gid, uid);
group_msgs(msgid,gid,sender_uid,time,content);
user_msgs(uid, msgid, gid);
優化為：
group_members(gid, uid, last_ack_msgid);
group_msgs(msgid,gid,sender_uid,time,content);
user_msgs(uid, msgid, gid); // 不再需要
離線的群友，拉取群訊息後，也修改這個last_ack_msgid。
畫外音：這裡的討論，僅限於接收方收到了哪些訊息，和傳送方的已讀回執沒有關係。總結任何架構方案都不是靈光一現，而是逐步迭代優化產生的：
(2)存多份，所有群友都儲存，訊息冗餘多；
(3)存多份，只存id，未利用偏序；
(4)存乙份，只存last_ack_msgid；
架構不只是設計出來的，更是演進出來的。任何脫離業務的架構設計都是耍流氓。
架構師之路-分享技術思路
若有收穫，隨手
轉 發。
超時待解決 PTA 群群群訊息
煩人奧，用樹做的仍然超時，暫時做個記錄。如果看到這篇的朋友有思路麻煩大力踢我！謝謝！思想就是建樹，遞迴，挖到底，返回。眾所周知，yooq是圖論之神，lc是數論之神。yooq正在看xx群裡的訊息。由於群裡面的訊息太多了，而且參差不齊，讓yooq看的很難受。不過，yooq在群裡有乙個特殊許可權，每一次操...
IM群聊訊息的已讀回執功能該怎麼實現？
學習交流 即時通訊開發交流3群 185926912 推薦 移動端im開發入門文章 新手入門一篇就夠 從零開發移動端im 本文同步發布於 im訊息送達保證機制實現 二 保證離線訊息的可靠投遞 如何保證im實時訊息的 時序性 與 一致性 im群聊訊息如此複雜，如何保證不丟不重？一種android端im智...
哨兵系統 釘釘群訊息推送
前言 之前哨兵系統提醒只是在前台使用聲音提醒，現在把訊息推送到值班人員群裡。避免值班人員在前台，專注寫 忽略了鈴聲，還有一點鈴聲確實有點打擾其他同事工作。所以下乙個版本哨兵系統，的確鬧鈴可以完全取消，替換成群訊息提醒。下面是釘釘群訊息推送的 目錄 頁面呼叫 業務實現 傳送群訊息 http介面訪問類 ...