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