單系統站內信設計概述

基本功能

• 點到點的消息傳送：

  • 用戶給用戶
  • 管理員給用戶

• 點到面的消息傳送

  • 管理員給用戶羣

少許用戶（10-999）

對於用戶很是少的狀況，沒有必要深刻的考慮數據庫的優化，採用簡單的表設計：

如表message

列名	字段
sendId	發送者id
recId	接受者id
message	站內信內容
status	查看
create_date	發送日期

點對點的信息發送，只須要在表中插入一條數據，記錄雙方的ID以及信息便可。查看本身是否有信息也很簡單：表中recId字段值等於本身的ID且status爲0（未讀）的信息就是本身須要查看的信息

店對面的操做和點對點的信息發送一致。

中量用戶（1000-99999）

若是按照少許用戶的設計思路來處理中量用戶的狀況，會出現什麼問題？假設用戶數量10000，管理員要向全部用戶發送系統通知。那麼，上述的表就須要一次操做插入10000條數據，這並沒什麼，但裏面的message就必須重複10000次，這意味着，100個漢字的消息，一次消息發送，就會佔用2M的空間，多發幾回，這張表就冗餘到不能接受了。

那爲何不用recId=0來表明向全部人發送，這樣不就能夠解決message重複10000次的問題了。固然能夠這樣作，但必須引入另外一張表，否則，就無法記錄哪個用戶讀過系統消息，哪個用戶沒有讀過。

所以，表設計以下：

表message

列名	字段
sendId	發送者id
recId	接受者id
messageId	站內信內容id
status	查看
create_date	發送日期

表message_text

列名	字段
messageId	編號
message_content	內容
create_date	發送日期

點對點的信息發送，首先在message_text表中插入一條記錄，獲得對應的ID，而後在message表中插入一條記錄，記錄相關發送人，接收人以及信息的ID

點對面的操做和點對點相似，一一對記錄好便可

這樣設計，每一次的信息發送操做，都只會記錄一條信息數據而不會重複。這樣能有效解決信息重複記錄致使佔用大量空間的問題。固然也會這樣也不是完美的

大量用戶（幾十萬到上百萬）

一樣，若是在百萬級的狀況下，使用中量用戶的方案會出現什麼問題？

從功能出發，管理員要向全部用戶發送站內信，那麼，message表中一會兒就得涌入百萬條數據，這個數據量對於數據庫來講，簡直可怕！並且，着還意味着，這張表有着百萬次潛在的是否已讀的修改請求。而且是每一個用戶在百萬條數據中尋找本身的那一條數據進行修改。這個效率是徹底不能接受的。

所以，咱們能夠設計一條規則來優化這個問題：

羣發的消息，接收人的ID爲0。這樣雖然能夠避免巨量操做，可是會引入另外一個問題：我怎麼知道那個用戶讀了？那個用戶沒讀？

那麼，我們就要將總體結構拆分爲三張表：

• message：收發關係表
• message_text：發送消息表
• message_customer：用戶消息關係表，加索引

表設計以下：

表message

列名	字段
sendId	發送者id
recId	接受者id
messageId	站內信內容id
create_date	發送日期

表message_text

列名	字段
messageId	編號
message_content	內容
create_date	發送日期

表message_customer

列名	字段
customerId	用戶id
messageId	信息id
status	閱讀狀態

這樣每次點對面的消息發送，首先在message_text表中插入一條數據，獲得ID，而後在message記錄相應的數據。用戶在閱讀後，會在message_customer表中插入一條數據，代表本身已經閱讀了。這樣就即解決沒發知道那個用戶是否已經閱讀的問題，也解決了須要在百萬表中查找修改狀態的問題。固然也會引入其餘問題，好比說：

• 增長了message_customer表的插入操做
• 若是用戶想將已讀的信息改成未讀，怎麼辦

固然，還能夠在其餘當面對站內信作一些優化操做，好比說：

• 數百萬的用戶，確定有殭屍用戶，那麼對於那些殭屍用戶，我們就不用發系統消息。
• 分時段的羣發，對於實效性不是那麼強的信息，能夠分時段的向部分用戶發送，直至發送徹底。也能夠在凌晨系統不是那麼繁忙的時候操做。

總結

上述的站內信只是在單應用系統下的一個很初步的設計，能夠這樣說，哪怕是按照大量用戶來設計單應用系統的站內信，也會出現這這那那的瓶頸，不只是數據庫的，還有網絡的，IO操做的等；所以，對於基礎單應用系統的站內信設計，只推薦使用中量用戶的設計，大量用戶的設計是一個很是複雜的架構，並非再分一個表就能解決的。

總結一下

• 少許用戶：設計簡單，但浪費空間，冗餘高
• 中量用戶：設計較簡單，對錶的操做壓力大
• 大量用戶：這不是增長几個表能解決的問題