隨著web2.0的發展，使用者之間的資訊互動也變得十分龐大，而且實時性要求越來越高。現在很多sns**和一部分cms**都廣泛地應用了站內信這一模組，這個看似簡單的東西其實背後隱藏著很多需要設計師重視的設計細節，要做好這個「郵遞員」是很不容易的。為什麼這麼說呢？下面我們就一步步來探索設計乙個百萬級使用者量的站內信** 資料庫，看完以後你就會明白什麼是真正可靠高效的「郵遞員」。
1、幾十——幾百的使用者量
這樣的**規模最小，可能是乙個中小企業的cms系統，面對這樣的使用者量，我們就不必要考慮短訊息資料量太大的問題了，所以按照怎麼方便怎麼來的原則，**就每人複製一條訊息資料，這樣使用者可以自己管理自己的訊息，可以非常方便進行「已讀、未讀、刪除」等操作。按照這個思路，我們的資料庫設計如下：
表t_message12
3456
id bigint --訊息id
senderid bigint --傳送者id
receiverid bigint --接收者id
sendtime datetime --傳送時間
readflag tinyint --已讀標誌
messagetext text --訊息正文
這樣，我們接受自己的訊息時只要做如下查詢：
1select * from t_message where receiverid=myid
查詢自己的未讀訊息只要做如下查詢：
1select * from t_message where receiverid=myid and readflag=0
這種方法很簡單，可能是我們第乙個想到的，對於這樣的使用者量的情況這樣的設計確實也足夠了。
2、幾千——幾萬的使用者量
使用者量到了這樣的級哦別，這個**應該算是比較大了，筆者估計，可能是乙個地區性的sns**。那麼面對這樣的使用者量，我們又該如何來設計站內信**呢？上面第一種思路還行得通嗎？應該這樣說，如果勉強要用上面那種設計，也是可以的，只不過t_message可能要考慮分割槽。但是，大家會不會覺得訊息正文複製那麼多條對於這樣的使用者量來講空間浪費太大，因為考慮到接收者一般是不修改訊息正文的，所以我們可以讓所有接收者共享一條訊息正文。具體資料庫設計方法和上面大同小異：
t_message12
3456
id bigint --訊息id
senderid bigint --傳送者id
receiverid bigint --接收者id
sendtime datetime --傳送時間
readflag tinyint --已讀標誌
messagetextid bigint --這裡把訊息正文內容換成訊息正文id
t_messagetext12
3id bigint --id標識
senderid bigint --傳送者id
messagetext text --訊息正文
這樣，我們就大大節省了訊息的儲存空間，但是查詢的時候就稍微麻煩一點，就需要進行聯合查詢了，查詢自己的未讀訊息可以這樣（意思一下，可能還有更高效的查詢方式）：12
3select 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、百萬級大使用者量
如果乙個**到了百萬級的使用者量了，那我不得不膜拜該**和**經營者了，因為經營這樣的**一直是筆者的夢想：）好了，回歸正題，如果這樣的系統放你面前，讓你設計乙個站內信**資料庫，你該何去何從，總之，上面兩種常規的辦法肯定是行不通了的，因為龐大的資料量會讓訊息表撐爆，即使你分割槽也無濟於事。這時候作為乙個系統架構師的你，可能不僅僅要從技術的角度去考慮這個問題，更要從使用者實際情況去著手尋找解決問題的辦法。這裡，有乙個概念叫「活躍使用者」，即經常登入**的使用者，相對於那些一時衝動註冊而接下來又從來不登入的使用者來說，活躍使用者對**的忠誠度很高，從商業的角度來講，忠誠的客戶享受更高階的服務。
根據這個思路，我們來探索一種方法。假設**有500萬註冊使用者，其中活躍使用者為60萬（這個比例真很不錯了），現在我們要對所有使用者**一封致謝信。還是上面兩張表，首先我們可以先往訊息表中插入一條**標識為-1 的訊息，這裡我們用字段sourcemessageid（原始訊息）來標識（-1為原始**訊息本身，其他則是原始訊息id），這樣其實**的工作已經完成了，使用者可以看到這條公共的訊息了。但是使用者需要有訊息的控制權，所以必須讓每個使用者擁有一條自己的訊息。要達到這個目的，我們可以讓使用者登入時檢查是否已經拷貝原始訊息，如果沒有拷貝，則拷貝乙份原始訊息並插入訊息表，**標識為原始訊息的id ；如果已經存在原始訊息的拷貝，則什麼都不做。這樣，我們就只要為這60萬活躍使用者消耗訊息空間就可以了。具體資料庫設計如下：
t_message12
3456
7id bigint --訊息id
senderid bigint --傳送者id
receiverid bigint --接收者id，如果為原始**訊息則為-1
sendtime datetime --傳送時間
readflag tinyint --已讀標誌，如果為原始**訊息則統一為0未讀
sourcemessageid bigint --如果為-1則為原始**訊息，其他則為原始訊息id
messagetextid bigint --這裡把訊息正文內容換成訊息正文id
表t_messagetext 與上面方法的一樣。
當然，如果你的活躍使用者達到100%，那這種方法相對前一種就沒有優勢了，但這種情況基本上不太可能，所以，筆者覺得這種方法來處理大使用者量的訊息**還是可行的。
4、總結
本文只是大致闡述了實現的原理，很多細節都忽略沒有考慮，純粹乙個設計想法而已，有興趣的朋友可以去自己實踐一下，另外，筆者對資料庫也不是很精通，如果有**闡述錯誤的還請指出，讓我們一起進步。
轉【王國峰】
百萬級使用者量的站內信群發資料庫設計
隨著web2.0的發展，使用者之間的資訊互動也變得十分龐大，而且實時性要求越來越高。現在很多sns 和一部分cms 都廣泛地應用了站內信這一模組，這個看似簡單的東西其實背後隱藏著很多需要設計師重視的設計細節，要做好這個 郵遞員 是很不容易的。為什麼這麼說呢？下面我們就一步步來探索設計乙個百萬級使用者...
百萬級使用者量的站內信群發資料庫設計
隨著web2.0的發展，使用者之間的資訊互動也變得十分龐大，而且實時性要求越來越高。現在很多sns 和一部分cms 都廣泛地應用了站內信這一模組，這個看似簡單的東西其實背後隱藏著很多需要設計師重視的設計細節，要做好這個 郵遞員 是很不容易的。為什麼這麼說呢？下面我們就一步步來探索設計乙個百萬級使用者...
電商系統百萬級站內信系統設計（主要資料庫設計）
大家知道，電商系統都是百萬級以上的使用者活動量，如果用正常的思路設計的程式，肯定是有很多漏洞和效能無法滿足系統的需求，那麼為了解決這個問題，本人特意寫下部落格給有需要的或者正在開發的新人一點設計思路。寫的好的地方請借鑑，不好的地方請指正 設計兩張表，一張是訊息表，另一張是訊息狀態表。傳送站內公告的時...