消息存儲設計如下莽龟，存于mongodb：
MsgInfo
{
cli_msgid
srv_msgid
msg_order
msg_time
msg_content
all_read_flag
from_uid
group_id
msg_status
}
消息存儲方式
消息存儲分庫，按照群id進行分庫锨天，總共分成256個庫吧。(對于mongodb就是集合)
消息已讀人數單獨存檔绍绘，包含uid數組奶镶，這個數組可以刪陪拘，也可以保留纤壁。
群消息已讀條數放在會話信息中，消息產生時更新未讀條數酌媒，設置消息已讀時將未讀條數清零。
群成員處理
方案一秒咨，直接走消息中心喇辽，群成員uid列表時實從緩存拉取，之后分別拉列表中的用戶在線信息雨席，數據包含在線設備及狀態(tài)菩咨，因為要區(qū)分是否推在線通知，是否推push陡厘。
方案二抽米，不走消息中心而是走群服務，在群服務做消息流程處理糙置。即獨立出群服務云茸，保存群成員列表及所有用戶設備在線狀態(tài)信息，懶加載這些信息到內存谤饭。數據有過期時間标捺，比如一小時過期，再配合數據變更通知揉抵。如果成員有變更需要通知群服務更新亡容。因為基于懶加載方式，群服務也是無狀態(tài)功舀，可以隨時重啟萍倡。
群消息處理流程
基于方案二，群消息按照群id進行hash辟汰，推送到某一臺群服務列敲。
消息去重阱佛，
懶加載群成員列表再加載成員在線設備狀態(tài)信息到內存，
生成msgid戴而，
消息寫一次db凑术，
回復ack，
更新所有群成員的會話信息所意，
為在線設備推通知淮逊，
為去重做臨時存儲。
群服務用戶結構設計要滿足如下條件：
通過一個群id找到群用戶列表扶踊，
通過uid找用戶設備在線信息泄鹏，
用戶在線設備信息僅存一份，不要冗余秧耗，
用戶狀態(tài)變更通知要告知群服務去及時更新备籽，能否做到自動失效或者無需通知？那就每次去拉一波用戶在線狀態(tài)分井，如此比較耗性能车猬，
多個服務可能都有某個群信息，所以用戶設備在線信息變更要廣播到所有群服務尺锚，能否有設計避免這種廣播通知珠闰？
萬人群的消息通知如何避免或者減少消息風暴？通知合并批量下發(fā)瘫辩，或者設計修改伏嗜，走異步消息通知隊列做緩沖『贾欤或者不下發(fā)阅仔！
