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

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

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

表T_Message

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

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

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

2、幾千——幾萬(wàn)的用戶量

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

T_Message

T_MessageText

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

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

3、百萬(wàn)級(jí)大用戶量

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

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

T_Message

表T_MessageText與上面方法的一樣。

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

4、總結(jié)

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

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

最新評(píng)論