摘要：需求用戶個人消息，平臺消息平臺給所有人發(fā)送消息。原因如果平臺用戶量較大時，假如萬，發(fā)一條系統(tǒng)消息，將要給萬的人發(fā)送一條，就是的消息記錄。千萬級的數(shù)據(jù)表，后期通過索引優(yōu)化，結(jié)構(gòu)優(yōu)化，業(yè)務邏輯優(yōu)化，避免大量并發(fā)查詢。

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

1.用戶個人消息，平臺消息（平臺給所有人發(fā)送消息）。
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, 系統(tǒng)消息為 0",
`is_read` tinyint(4) DEFAULT "0" COMMENT "是否已讀0未讀1已讀",
`ope_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT "操作更新時間【不由程序控制，由mysql系統(tǒng)控制】",
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 "系統(tǒng)消息默認為0",
  `start_time` datetime DEFAULT NULL COMMENT "消息有效時間（開始時間）",
  `end_time` datetime DEFAULT NULL COMMENT "消息失效時間（結(jié)束時間）",
  `ope_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT "操作更新時間【不由程序控制，由mysql系統(tǒng)控制】",
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT COMMENT="平臺的系統(tǒng)消息|通知";

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

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

表結(jié)構(gòu)不變，上述中的中間表，我們使用redis替換。

redis緩存記錄不存在，插入數(shù)據(jù)，更新redis緩存。

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

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

兩張表 users_message 和 sys_message

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

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

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

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

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

列表暫時查詢數(shù)據(jù)庫等數(shù)據(jù)落地庫。

能不使用數(shù)據(jù)庫的就不使用，減少并發(fā)情況下，影響數(shù)據(jù)庫的性能。

先做一個簡單版，后續(xù)慢慢在自己的代碼上的優(yōu)化。

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

千萬級的數(shù)據(jù)表，后期通過索引優(yōu)化，結(jié)構(gòu)優(yōu)化，業(yè)務邏輯優(yōu)化，避免大量并發(fā)查詢。一般都不會出現(xiàn)問題

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