資訊專欄INFORMATION COLUMN
摘要：也可以在凌晨系統(tǒng)不是那么繁忙的時候操作?？偨Y(jié)一下少量用戶設(shè)計簡單，但浪費空間，冗余高中量用戶設(shè)計較簡單，對表的操作壓力大大量用戶這不是增加幾個表能解決的問題
基本功能
點到點的消息傳送：
用戶給用戶
管理員給用戶
點到面的消息傳送
管理員給用戶群
少量用戶（10-999）對于用戶非常少的情況，沒有必要深入的考慮數(shù)據(jù)庫的優(yōu)化，采用簡單的表設(shè)計：
如表message
| 列名 | 字段 |
|---|---|
| sendId | 發(fā)送者id |
| recId | 接受者id |
| message | 站內(nèi)信內(nèi)容 |
| status | 查看 |
| create_date | 發(fā)送日期 |
點對點的信息發(fā)送，只需要在表中插入一條數(shù)據(jù)，記錄雙方的ID以及信息即可。查看自己是否有信息也很簡單：表中recId字段值等于自己的ID且status為0（未讀）的信息就是自己需要查看的信息
店對面的操作和點對點的信息發(fā)送一致。
中量用戶（1000-99999）如果按照少量用戶的設(shè)計思路來處理中量用戶的情況，會出現(xiàn)什么問題？假設(shè)用戶數(shù)量10000，管理員要向所有用戶發(fā)送系統(tǒng)通知。那么，上述的表就需要一次操作插入10000條數(shù)據(jù)，這并沒什么，但里面的message就必須重復(fù)10000次，這意味著，100個漢字的消息，一次消息發(fā)送，就會占用2M的空間，多發(fā)幾次，這張表就冗余到不能接受了。
那為什么不用recId=0來代表向所有人發(fā)送，這樣不就可以解決message重復(fù)10000次的問題了。當(dāng)然可以這樣做，但必須引入另一張表，不然，就沒法記錄哪一個用戶讀過系統(tǒng)消息，哪一個用戶沒有讀過。
因此，表設(shè)計如下：
表message
| 列名 | 字段 |
|---|---|
| sendId | 發(fā)送者id |
| recId | 接受者id |
| messageId | 站內(nèi)信內(nèi)容id |
| status | 查看 |
| create_date | 發(fā)送日期 |
表message_text
| 列名 | 字段 |
|---|---|
| messageId | 編號 |
| message_content | 內(nèi)容 |
| create_date | 發(fā)送日期 |
點對點的信息發(fā)送，首先在message_text表中插入一條記錄，得到對應(yīng)的ID，然后在message表中插入一條記錄，記錄相關(guān)發(fā)送人，接收人以及信息的ID
點對面的操作和點對點類似，一一對記錄好即可
這樣設(shè)計，每一次的信息發(fā)送操作，都只會記錄一條信息數(shù)據(jù)而不會重復(fù)。這樣能有效解決信息重復(fù)記錄導(dǎo)致占用大量空間的問題。當(dāng)然也會這樣也不是完美的
大量用戶（幾十萬到上百萬）同樣，如果在百萬級的情況下，使用中量用戶的方案會出現(xiàn)什么問題？
從功能出發(fā)，管理員要向所有用戶發(fā)送站內(nèi)信，那么，message表中一下子就得涌入百萬條數(shù)據(jù)，這個數(shù)據(jù)量對于數(shù)據(jù)庫來說，簡直可怕！而且，著還意味著，這張表有著百萬次潛在的是否已讀的修改請求。并且是每個用戶在百萬條數(shù)據(jù)中尋找自己的那一條數(shù)據(jù)進(jìn)行修改。這個效率是完全不能接受的。
因此，我們可以設(shè)計一條規(guī)則來優(yōu)化這個問題：
群發(fā)的消息，接收人的ID為0。這樣雖然可以避免巨量操作，但是會引入另一個問題：我怎么知道那個用戶讀了？那個用戶沒讀？
那么，咱們就要將整體結(jié)構(gòu)拆分為三張表：
message：收發(fā)關(guān)系表
message_text：發(fā)送消息表
message_customer：用戶消息關(guān)系表，加索引
表設(shè)計如下：
表message
| 列名 | 字段 |
|---|---|
| sendId | 發(fā)送者id |
| recId | 接受者id |
| messageId | 站內(nèi)信內(nèi)容id |
| create_date | 發(fā)送日期 |
表message_text
| 列名 | 字段 |
|---|---|
| messageId | 編號 |
| message_content | 內(nèi)容 |
| create_date | 發(fā)送日期 |
表message_customer
| 列名 | 字段 |
|---|---|
| customerId | 用戶id |
| messageId | 信息id |
| status | 閱讀狀態(tài) |
這樣每次點對面的消息發(fā)送，首先在message_text表中插入一條數(shù)據(jù)，得到ID，然后在message記錄相應(yīng)的數(shù)據(jù)。用戶在閱讀后，會在message_customer表中插入一條數(shù)據(jù)，表明自己已經(jīng)閱讀了。這樣就即解決沒發(fā)知道那個用戶是否已經(jīng)閱讀的問題，也解決了需要在百萬表中查找修改狀態(tài)的問題。當(dāng)然也會引入其他問題，比如說：
增加了message_customer表的插入操作
如果用戶想將已讀的信息改為未讀，怎么辦
當(dāng)然，還可以在其他當(dāng)面對站內(nèi)信做一些優(yōu)化操作，比如說：
數(shù)百萬的用戶，肯定有僵尸用戶，那么對于那些僵尸用戶，咱們就不用發(fā)系統(tǒng)消息。
分時段的群發(fā)，對于實效性不是那么強的信息，可以分時段的向部分用戶發(fā)送，直至發(fā)送完全。也可以在凌晨系統(tǒng)不是那么繁忙的時候操作。
總結(jié)上述的站內(nèi)信只是在單應(yīng)用系統(tǒng)下的一個很初步的設(shè)計，可以這樣說，哪怕是按照大量用戶來設(shè)計單應(yīng)用系統(tǒng)的站內(nèi)信，也會出現(xiàn)這這那那的瓶頸，不僅是數(shù)據(jù)庫的，還有網(wǎng)絡(luò)的，IO操作的等；因此，對于基礎(chǔ)單應(yīng)用系統(tǒng)的站內(nèi)信設(shè)計，只推薦使用中量用戶的設(shè)計，大量用戶的設(shè)計是一個非常復(fù)雜的架構(gòu)，并不是再分一個表就能解決的。
總結(jié)一下
少量用戶：設(shè)計簡單，但浪費空間，冗余高
中量用戶：設(shè)計較簡單，對表的操作壓力大
大量用戶：這不是增加幾個表能解決的問題
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://www.ezyhdfw.cn/yun/70684.html
摘要：第一版設(shè)計需求單用戶之間通信融合了用戶反饋需求數(shù)據(jù)庫設(shè)計內(nèi)容和收發(fā)者存在一張表中表這里一條存兩次，類似郵件服務(wù)。參考群發(fā)站內(nèi)信的實現(xiàn)群發(fā)站內(nèi)信的實現(xiàn)續(xù)兩年后，再議站內(nèi)信的實現(xiàn)百萬級用戶量的站內(nèi)信群發(fā)數(shù)據(jù)庫設(shè)計 第一版設(shè)計 需求 ：單用戶之間通信（融合了用戶反饋需求） 數(shù)據(jù)庫設(shè)計：Message內(nèi)容和收發(fā)者存在一張表中 message表： 這里一條Message存兩次，類似郵件服務(wù)。...
摘要：第一版設(shè)計需求單用戶之間通信融合了用戶反饋需求數(shù)據(jù)庫設(shè)計內(nèi)容和收發(fā)者存在一張表中表這里一條存兩次，類似郵件服務(wù)。參考群發(fā)站內(nèi)信的實現(xiàn)群發(fā)站內(nèi)信的實現(xiàn)續(xù)兩年后，再議站內(nèi)信的實現(xiàn)百萬級用戶量的站內(nèi)信群發(fā)數(shù)據(jù)庫設(shè)計 第一版設(shè)計 需求 ：單用戶之間通信（融合了用戶反饋需求） 數(shù)據(jù)庫設(shè)計：Message內(nèi)容和收發(fā)者存在一張表中 message表： 這里一條Message存兩次，類似郵件服務(wù)。...
摘要：客戶端訪問后端，確認(rèn)是否有發(fā)送給自己的站內(nèi)信，如有，播放消息提示音，并更改頁面站內(nèi)信未讀數(shù)。登陸請求成功，服務(wù)器監(jiān)聽程序會以作為用戶的連接標(biāo)識。調(diào)用上述的服務(wù)將信息推送到服務(wù)器監(jiān)聽程序。 流程說明 使用 web-msg-sender 作為 服務(wù)器監(jiān)聽程序。 客戶端（瀏覽器）通過websocket連接 服務(wù)器監(jiān)聽程序。 服務(wù)器應(yīng)用程序（后端） 通過curl訪問 服務(wù)器監(jiān)聽程序，將需...
閱讀 3649·2021-11-18 10:02
閱讀 3181·2019-08-29 18:34
閱讀 3484·2019-08-29 17:00
閱讀 498·2019-08-29 12:35
閱讀 826·2019-08-28 18:22
閱讀 2072·2019-08-26 13:58
閱讀 1751·2019-08-26 10:39
閱讀 2748·2019-08-26 10:11
