隨著WEB2.0的發展，使用者之間的資訊互動也變得十分龐大，而且實時性要求越來越高。現在很多SNS網站和一部分CMS網站都廣泛地應用了站內信這一模組，這個看似簡單的東西其實背後隱藏著很多需要設計師重視的設計細節，要做好這個“郵遞員”是很不容易的。為什麼這麼說呢？下面我們就一步步來探索設計一個百萬級使用者量的站內信群發資料庫，看完以後你就會明白什麼是真正可靠高效的“郵遞員”。

1、幾十——幾百的使用者量

這樣的網站規模最小，可能是一箇中小企業的CMS系統，面對這樣的使用者量，我們就不必要考慮短訊息資料量太大的問題了，所以按照怎麼方便怎麼來的原則，群發就每人複製一條訊息資料，這樣使用者可以自己管理自己的訊息，可以非常方便進行“已讀、未讀、刪除”等操作。按照這個思路，我們的資料庫設計如下：

表T_Message

2、幾千——幾萬的使用者量

使用者量到了這樣的級哦別，這個網站應該算是比較大了，筆者估計，可能是一個地區性的SNS網站。那麼面對這樣的使用者量，我們又該如何來設計站內信群發呢？上面第一種思路還行得通嗎？應該這樣說，如果勉強要用上面那種設計，也是可以的，只不過T_Message可能要考慮分割槽。但是，大家會不會覺得訊息正文複製那麼多條對於這樣的使用者量來講空間浪費太大，因為考慮到接收者一般是不修改訊息正文的，所以我們可以讓所有接收者共享一條訊息正文。具體資料庫設計方法和上面大同小異：

T_Message

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

3、百萬級大使用者量

如果一個網站到了百萬級的使用者量了，那我不得不膜拜該網站和網站經營者了，因為經營這樣的網站一直是筆者的夢想：）好了，迴歸正題，如果這樣的系統放你面前，讓你設計一個站內信群發資料庫，你該何去何從，總之，上面兩種常規的辦法肯定是行不通了的，因為龐大的資料量會讓訊息表撐爆，即使你分割槽也無濟於事。這時候作為一個系統架構師的你，可能不僅僅要從技術的角度去考慮這個問題，更要從使用者實際情況去著手尋找解決問題的辦法。這裡，有一個概念叫“活躍使用者”，即經常登入網站的使用者，相對於那些一時衝動註冊而接下來又從來不登入的使用者來說，活躍使用者對網站的忠誠度很高，從商業的角度來講，忠誠的客戶享受更高階的服務。

根據這個思路，我們來探索一種方法。假設網站有500萬註冊使用者，其中活躍使用者為60萬（這個比例真很不錯了），現在我們要對所有使用者群發一封致謝信。還是上面兩張表，首先我們可以先往訊息表中插入一條群發標識為-1的訊息，這裡我們用欄位SourceMessageId（原始訊息）來標識（-1為原始群發訊息本身，其他則是原始訊息id），這樣其實群發的工作已經完成了，使用者可以看到這條公共的訊息了。但是使用者需要有訊息的控制權，所以必須讓每個使用者擁有一條自己的訊息。要達到這個目的，我們可以讓使用者登入時檢查是否已經拷貝原始訊息，如果沒有拷貝，則拷貝一份原始訊息並插入訊息表，群發標識為原始訊息的id；如果已經存在原始訊息的拷貝，則什麼都不做。這樣，我們就只要為這60萬活躍使用者消耗訊息空間就可以了。具體資料庫設計如下：

T_Message

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

4、總結

本文只是大致闡述了實現的原理，很多細節都忽略沒有考慮，純粹一個設計想法而