摘要：需求用戶個人消息，平臺消息平臺給所有人發送消息。原因如果平臺用戶量較大時，假如萬，發一條系統消息，將要給萬的人發送一條，就是的消息記錄。千萬級的數據表，后期通過索引優化，結構優化，業務邏輯優化，避免大量并發查詢。

本文都是參加工作的實際情況,希望對大家有所幫助?！?螞蟻爬樹不怕高，有心學習不怕老。

1.用戶個人消息，平臺消息（平臺給所有人發送消息）。
2.用戶未讀消息展示，消息列表展示

1.用戶信息表users_message

CREATE TABLE `users_message` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`title` varchar(200) DEFAULT NULL,
`content` varchar(4000) DEFAULT NULL,
`uid` int(11) DEFAULT NULL,
`create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`msg_type` tinyint(4) DEFAULT "1" COMMENT "用戶消息為1, 系統消息為 0",
`is_read` tinyint(4) DEFAULT "0" COMMENT "是否已讀0未讀1已讀",
`ope_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT "操作更新時間【不由程序控制，由mysql系統控制】",
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC;

2.平臺信息表sys_message

CREATE TABLE `sys_message` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `title` varchar(20) DEFAULT NULL,
  `content` varchar(500) DEFAULT NULL,
  `create_time` timestamp NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP,
  `msg_type` tinyint(4) DEFAULT NULL COMMENT "系統消息默認為0",
  `start_time` datetime DEFAULT NULL COMMENT "消息有效時間（開始時間）",
  `end_time` datetime DEFAULT NULL COMMENT "消息失效時間（結束時間）",
  `ope_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT "操作更新時間【不由程序控制，由mysql系統控制】",
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT COMMENT="平臺的系統消息|通知";

1.用戶個人消息:平臺中用戶的個人普通消息(存儲在users_message)。
2.用戶系統消息：平臺給所有用戶發送的 系統消息(存儲在users_message)。
3.系統消息：平臺給所有用戶發送的 系統消息（存儲在sys_message）。
4.message:sysmessags:init (原始系統隊列) 存放數據庫中的sys_message的有效消息（定期需要更新）
5.message:user_sysmessage:compare（用戶系統消息隊列） 存儲 用戶與系統消息的關系（建議存儲 用戶唯一標識和系統消息的唯一標識）對應的時候數據庫的關系表

1.用戶的消息：當平臺給用戶發送用戶消息，直接在users_message添加一條記錄。
2.平臺消息：當平臺給用戶發送系統消息時，在sys_message添加一條系統消息記錄。
3.每個平臺都會有活躍用戶和僵尸用戶或不活躍用戶。所以系統消息的發送，不會給所有人都發送。
原因：如果平臺用戶量較大時，假如100萬，發一條系統消息，將要給100萬的人發送一條，就是100w的消息記錄。如果當系統消息堆積到20條，將會2000w用戶系統消息，對數據庫都是一個不小的壓力。當數據量大時，查詢，添加等操作都會變的異常慢
4.采取大家常用的處理方式：
1）使用中間表，存儲用戶的系統消息關系；如果系統消息關系表中沒有（系統消息和用戶的關系），添加關系，將系統消息插入到用戶到用戶消息表變為用戶系統消息；存在則不做操作。請查看單系統站內信設計概述
2) 使用mongo等，存儲用戶的消息，也類似上述一樣。請自己查閱資料...
我想說說自己的想法:上述的結構等，我在公司都嘗試過，但是效果在特殊場合會出現弊端。思路大致為：（數據存儲優化 + 業務邏輯優化）

表結構不變，上述中的中間表，我們使用redis替換。

redis緩存記錄不存在，插入數據，更新redis緩存。

未讀消息個數也使用redis緩存，不需要每次都去查詢數據庫或mongo(主要取決你的落地數據存儲在數據庫還是mongo)

消息列表查詢，是否每次都查詢數據庫或mongo,再考慮是否放入redis緩存。（續實踐后，再分享給大家）

兩張表 users_message 和 sys_message

將sys_message中有效時間內的消息同步或更新到redis列表 message:sysmessags:init (原始系統隊列)

        通過初始化自己的項目時，進行同步數據；通過定時程序同步更新數據庫和redis中的數據。

當用戶在客戶端和服務器交互的時候，觸發（消息處理）檢測用戶是否擁有當前有效的系統消息；
存在：不處理消息（可以判斷個數）;
不存在：需要添加并且更新數據庫或mongo;

        《原始系統隊列》與《用戶系統消息隊列》對比個數，判斷是否用戶系統消息隊列少了部分數據。
        少的部分，需要更新《用戶系統消息隊列》并且添加新的系統消息到**用戶的個人消息表**

消息未讀數：使用redis，key - value 的形式存儲一個用戶未讀消息個數數字；維護未讀消息，需要在用戶更新消息狀態和給用戶插入消息的時候，需要對未讀數進行更新（為了未讀數準確，可以進行特殊情況下更新未讀數）。

列表暫時查詢數據庫等數據落地庫。

能不使用數據庫的就不使用，減少并發情況下，影響數據庫的性能。

先做一個簡單版，后續慢慢在自己的代碼上的優化。

看看自己的情況，覺得選擇自己的方案。

千萬級的數據表，后期通過索引優化，結構優化，業務邏輯優化，避免大量并發查詢。一般都不會出現問題

想詳細的解釋一下，可是語言真的好難組織哇。寫著寫著寫成最終篇幅了。