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

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

1.用戶個(gè)人消息，平臺(tái)消息（平臺(tái)給所有人發(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 "操作更新時(shí)間【不由程序控制，由mysql系統(tǒng)控制】",
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC;

2.平臺(tái)信息表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)消息默認(rèn)為0",
  `start_time` datetime DEFAULT NULL COMMENT "消息有效時(shí)間（開始時(shí)間）",
  `end_time` datetime DEFAULT NULL COMMENT "消息失效時(shí)間（結(jié)束時(shí)間）",
  `ope_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT "操作更新時(shí)間【不由程序控制，由mysql系統(tǒng)控制】",
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT COMMENT="平臺(tái)的系統(tǒng)消息|通知";

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

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

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

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

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

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

兩張表 users_message 和 sys_message

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

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

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

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

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

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

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

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

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

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

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