基本功能

• 點到點的消息傳送：

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

• 點到面的消息傳送

  • 管理員給用戶群

少量用戶（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操作的等；因此，對于基礎單應用系統的站內信設計，只推薦使用中量用戶的設計，大量用戶的設計是一個非常復雜的架構，并不是再分一個表就能解決的。

總結一下

• 少量用戶：設計簡單，但浪費空間，冗余高
• 中量用戶：設計較簡單，對表的操作壓力大
• 大量用戶：這不是增加幾個表能解決的問題

轉載于:https://www.cnblogs.com/sein777/p/11214524.html

總結

以上是生活随笔為你收集整理的站内信1-100万的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。