快捷導(dǎo)航

站內(nèi)群發(fā)消息三種不同用戶量的數(shù)據(jù)庫設(shè)計

更新時間：2023年12月02日 08:47:03 投稿：yin

很多SNS網(wǎng)站和一部分CMS網(wǎng)站都廣泛地應(yīng)用了站內(nèi)信這一模塊,這個看似簡單的東西其實背后隱藏著很多需要設(shè)計師重視的設(shè)計細(xì)節(jié),要做好這個“郵遞員”是很不容易的,本文講述站內(nèi)群發(fā)消息三種不同用戶量的數(shù)據(jù)庫設(shè)計,逐漸設(shè)計一個百萬級用戶量的站內(nèi)信群發(fā)數(shù)據(jù)庫

隨著WEB2.0的發(fā)展，用戶之間的信息交互也變得十分龐大，而且實時性要求越來越高。現(xiàn)在很多SNS網(wǎng)站和一部分CMS網(wǎng)站都廣泛地應(yīng)用了站內(nèi)信這一模塊，這個看似簡單的東西其實背后隱藏著很多需要設(shè)計師重視的設(shè)計細(xì)節(jié)，要做好這個“郵遞員”是很不容易的。本文講述站內(nèi)群發(fā)消息三種不同用戶量的數(shù)據(jù)庫設(shè)計，逐漸設(shè)計一個百萬級用戶量的站內(nèi)信群發(fā)數(shù)據(jù)庫，看完以后你就會明白什么是真正可靠高效的“郵遞員”。

1、幾十——幾百的用戶量

這樣的網(wǎng)站規(guī)模最小，可能是一個中小企業(yè)的CMS系統(tǒng)，面對這樣的用戶量，我們就不必要考慮短消息數(shù)據(jù)量太大的問題了，所以按照怎么方便怎么來的原則，群發(fā)就每人復(fù)制一條消息數(shù)據(jù)，這樣用戶可以自己管理自己的消息，可以非常方便進(jìn)行“已讀、未讀、刪除”等操作。按照這個思路，我們的數(shù)據(jù)庫設(shè)計如下：

表T_Message

1

2

3

4

5

6

Id bigint --消息ID

SenderId bigint --發(fā)送者ID

ReceiverId bigint --接收者ID

SendTime datetime --發(fā)送時間

ReadFlag tinyint --已讀標(biāo)志

MessageText text --消息正文

這樣，我們接受自己的消息時只要做如下查詢：

1	`SELECT` `*` `FROM` `T_Message` `WHERE` `ReceiverId=myid`

查詢自己的未讀消息只要做如下查詢：

1	`SELECT` `*` `FROM` `T_Message` `WHERE` `ReceiverId=myid` `and` `ReadFlag=0`

這種方法很簡單，可能是我們第一個想到的，對于這樣的用戶量的情況這樣的設(shè)計確實也足夠了。

2、幾千——幾萬的用戶量

用戶量到了這樣的級哦別，這個網(wǎng)站應(yīng)該算是比較大了，筆者估計，可能是一個地區(qū)性的SNS網(wǎng)站。那么面對這樣的用戶量，我們又該如何來設(shè)計站內(nèi)信群發(fā)呢？上面第一種思路還行得通嗎？應(yīng)該這樣說，如果勉強(qiáng)要用上面那種設(shè)計，也是可以的，只不過T_Message可能要考慮分區(qū)。但是，大家會不會覺得消息正文復(fù)制那么多條對于這樣的用戶量來講空間浪費太大，因為考慮到接收者一般是不修改消息正文的，所以我們可以讓所有接收者共享一條消息正文。具體數(shù)據(jù)庫設(shè)計方法和上面大同小異：

T_Message

1

2

3

4

5

6

Id bigint --消息ID

SenderId bigint --發(fā)送者ID

ReceiverId bigint --接收者ID

SendTime datetime --發(fā)送時間

ReadFlag tinyint --已讀標(biāo)志

MessageTextId bigint --這里把消息正文內(nèi)容換成消息正文Id

T_MessageText

1

2

3

Id bigint --ID標(biāo)識

SenderId bigint --發(fā)送者ID

MessageText text --消息正文

這樣，我們就大大節(jié)省了消息的存儲空間，但是查詢的時候就稍微麻煩一點，就需要進(jìn)行聯(lián)合查詢了，查詢自己的未讀消息可以這樣（意思一下，可能還有更高效的查詢方式）：

1

2

3

SELECT T_Message.*,T_MessageText.* FROM T_Message

INNER JOIN T_MessageText ON T_Message.MessageTextId=T_MessageText.Id

WHERE T_Message.ReceiverId=myid AND T_Message.ReadFlag=0

用這種方法除了正文我們不能隨便刪除外，用戶還是可以自己管理自己的消息。

3、百萬級大用戶量

如果一個網(wǎng)站到了百萬級的用戶量了，那我不得不膜拜該網(wǎng)站和網(wǎng)站經(jīng)營者了，因為經(jīng)營這樣的網(wǎng)站一直是筆者的夢想：）好了，回歸正題，如果這樣的系統(tǒng)放你面前，讓你設(shè)計一個站內(nèi)信群發(fā)數(shù)據(jù)庫，你該何去何從，總之，上面兩種常規(guī)的辦法肯定是行不通了的，因為龐大的數(shù)據(jù)量會讓消息表撐爆，即使你分區(qū)也無濟(jì)于事。這時候作為一個系統(tǒng)架構(gòu)師的你，可能不僅僅要從技術(shù)的角度去考慮這個問題，更要從用戶實際情況去著手尋找解決問題的辦法。這里，有一個概念叫“活躍用戶”，即經(jīng)常登錄網(wǎng)站的用戶，相對于那些一時沖動注冊而接下來又從來不登錄的用戶來說，活躍用戶對網(wǎng)站的忠誠度很高，從商業(yè)的角度來講，忠誠的客戶享受更高端的服務(wù)。

根據(jù)這個思路，我們來探索一種方法。假設(shè)網(wǎng)站有500萬注冊用戶，其中活躍用戶為60萬（這個比例真很不錯了），現(xiàn)在我們要對所有用戶群發(fā)一封致謝信。還是上面兩張表，首先我們可以先往消息表中插入一條群發(fā)標(biāo)識為-1的消息，這里我們用字段SourceMessageId（原始消息）來標(biāo)識（-1為原始群發(fā)消息本身，其他則是原始消息id），這樣其實群發(fā)的工作已經(jīng)完成了，用戶可以看到這條公共的消息了。但是用戶需要有消息的控制權(quán)，所以必須讓每個用戶擁有一條自己的消息。要達(dá)到這個目的，我們可以讓用戶登錄時檢查是否已經(jīng)拷貝原始消息，如果沒有拷貝，則拷貝一份原始消息并插入消息表，群發(fā)標(biāo)識為原始消息的id；如果已經(jīng)存在原始消息的拷貝，則什么都不做。這樣，我們就只要為這60萬活躍用戶消耗消息空間就可以了。具體數(shù)據(jù)庫設(shè)計如下：

T_Message

1

2

3

4

5

6

7

Id bigint --消息ID

SenderId bigint --發(fā)送者ID

ReceiverId bigint --接收者ID，如果為原始群發(fā)消息則為-1

SendTime datetime --發(fā)送時間

ReadFlag tinyint --已讀標(biāo)志，如果為原始群發(fā)消息則統(tǒng)一為0未讀

SourceMessageId bigint --如果為-1則為原始群發(fā)消息，其他則為原始消息id

MessageTextId bigint --這里把消息正文內(nèi)容換成消息正文Id

表T_MessageText與上面方法的一樣。

當(dāng)然，如果你的活躍用戶達(dá)到100%，那這種方法相對前一種就沒有優(yōu)勢了，但這種情況基本上不太可能，所以，筆者覺得這種方法來處理大用戶量的消息群發(fā)還是可行的。

4、總結(jié)

本文只是大致闡述了實現(xiàn)的原理，很多細(xì)節(jié)都忽略沒有考慮，純粹一個設(shè)計想法而已，有興趣的朋友可以去自己實踐一下，另外，筆者對數(shù)據(jù)庫也不是很精通，如果有哪里闡述錯誤的還請指出，讓我們一起進(jìn)步。

到此這篇關(guān)于站內(nèi)群發(fā)消息三種不同用戶量的數(shù)據(jù)庫設(shè)計的文章就介紹到這了,更多相關(guān)站內(nèi)群發(fā)消息的數(shù)據(jù)庫設(shè)計內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: