單系統站內信設計概述

Rainie 發布于2019-08-16 10:54 / 3361人閱讀

摘要：也可以在凌晨系統不是那么繁忙的時候操作。總結一下少量用戶設計簡單，但浪費空間，冗余高中量用戶設計較簡單，對表的操作壓力大大量用戶這不是增加幾個表能解決的問題

基本功能

點到點的消息傳送：

用戶給用戶

管理員給用戶

點到面的消息傳送

管理員給用戶群

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

總結一下

少量用戶：設計簡單，但浪費空間，冗余高

中量用戶：設計較簡單，對表的操作壓力大

大量用戶：這不是增加幾個表能解決的問題

GPU云服務器云服務器站內信群發站內信 linux操作系統概述海南州云藏大數據中心系統概述

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/70684.html

單系統站內信數據庫設計思路

摘要：第一版設計需求單用戶之間通信融合了用戶反饋需求數據庫設計內容和收發者存在一張表中表這里一條存兩次，類似郵件服務。參考群發站內信的實現群發站內信的實現續兩年后，再議站內信的實現百萬級用戶量的站內信群發數據庫設計第一版設計需求：單用戶之間通信（融合了用戶反饋需求）數據庫設計：Message內容和收發者存在一張表中 message表：這里一條Message存兩次，類似郵件服務。...

G9YH 2019-08-15 15:29 評論0 收藏0
單系統站內信數據庫設計思路

摘要：第一版設計需求單用戶之間通信融合了用戶反饋需求數據庫設計內容和收發者存在一張表中表這里一條存兩次，類似郵件服務。參考群發站內信的實現群發站內信的實現續兩年后，再議站內信的實現百萬級用戶量的站內信群發數據庫設計第一版設計需求：單用戶之間通信（融合了用戶反饋需求）數據庫設計：Message內容和收發者存在一張表中 message表：這里一條Message存兩次，類似郵件服務。...

Achilles 2019-06-25 18:37 評論0 收藏0
基于workerman實現的web消息推送站內信功能

摘要：客戶端訪問后端，確認是否有發送給自己的站內信，如有，播放消息提示音，并更改頁面站內信未讀數。登陸請求成功，服務器監聽程序會以作為用戶的連接標識。調用上述的服務將信息推送到服務器監聽程序。流程說明使用 web-msg-sender 作為服務器監聽程序。客戶端（瀏覽器）通過websocket連接服務器監聽程序。服務器應用程序（后端）通過curl訪問服務器監聽程序，將需...

YFan 2019-06-28 13:38 評論0 收藏0