大型互動平臺中好友動態(tài)系統(tǒng)架構(gòu)設(shè)計與實現(xiàn)

劉 平，王治國，曹 剛，吳 迪，彭 升

（中國網(wǎng)絡(luò)電視臺，北京 100142）

0 引言

《第27次中國互聯(lián)網(wǎng)絡(luò)發(fā)展狀況統(tǒng)計報告》顯示，截至2010年12月，中國網(wǎng)民規(guī)模達到4.57億，較2009年底增加7330萬人；互聯(lián)網(wǎng)普及率攀升至34.3%，較2009年提高5.4個百分點。另外，《報告》顯示，中國網(wǎng)民的互聯(lián)網(wǎng)應(yīng)用表現(xiàn)出商務(wù)類應(yīng)用用戶規(guī)模繼續(xù)領(lǐng)漲、網(wǎng)絡(luò)娛樂漸入平穩(wěn)期、社交類應(yīng)用保持較快發(fā)展速度的特點[1]。

Web2.0[2]的浪潮席卷了整個互聯(lián)網(wǎng)，帶來了人們對互聯(lián)網(wǎng)應(yīng)用的徹底轉(zhuǎn)變?；诹瓤臻g理論發(fā)展起來的社會化網(wǎng)絡(luò)服務(wù)或社交網(wǎng)站（Social Network Service，SNS），是Web2.0的典型代表。SNS通過網(wǎng)絡(luò)服務(wù)不僅幫助人們找到朋友、合作伙伴，而且能夠?qū)崿F(xiàn)個人數(shù)據(jù)處理、個人社會關(guān)系管理、信息共享和知識分享，最終幫助用戶利用信任關(guān)系拓展自己的社交網(wǎng)絡(luò)，達成更有價值的溝通和協(xié)作，從而帶來豐富的商業(yè)機會和巨大的社會價值。

從2005年開始，以Facebook為代表的SNS類網(wǎng)站在一夜之間火遍全球，無數(shù)類似的網(wǎng)站出現(xiàn)在互聯(lián)網(wǎng)上。2010年上半年，F(xiàn)acebook的訪問量首次超過Google，成為全球流量最大的網(wǎng)站。在國內(nèi)，SNS也在蓬勃發(fā)展，成為過去兩年最熱門的網(wǎng)站類型之一。

動態(tài)（feeds）是將用戶在網(wǎng)站的活動進行記錄并推送到其好友主頁的功能，目前已經(jīng)廣泛用于社交網(wǎng)站。動態(tài)功能很好地把用戶和內(nèi)容結(jié)合起來，大幅提高了用戶的互動。當用戶在站內(nèi)進行某些操作行為后，該用戶相關(guān)的好友會收到相應(yīng)的此用戶行為的消息通知。筆者認為用戶看見好友的行為通知后很可能也跟進一個的類似或相關(guān)的行為，這就是“黏度”的體現(xiàn)。因此，好友動態(tài)系統(tǒng)是大型互動平臺的核心，承載著各個業(yè)務(wù)系統(tǒng)與用戶之間的互動。

本文分析了大型互動平臺中好友動態(tài)系統(tǒng)架構(gòu)面臨的調(diào)整，確定了架構(gòu)設(shè)計的模式和原則，并詳細介紹了好友動態(tài)系統(tǒng)架構(gòu)的設(shè)計與實現(xiàn)。

1 架構(gòu)挑戰(zhàn)

對于網(wǎng)站運營來說，以下場景在網(wǎng)站的整個生命周期里很有可能出現(xiàn)，而且一旦出現(xiàn)都是系統(tǒng)的噩夢：

1）場景一：某硬件或服務(wù)故障可能導致整個網(wǎng)站不可用

系統(tǒng)上線運營后，各項業(yè)務(wù)都逐漸進入上升軌道，活躍用戶也穩(wěn)步增加，各項數(shù)據(jù)都表明網(wǎng)站在年輕人群中的社會影響力與日俱增，此時系統(tǒng)中一個機器發(fā)生宕機，開始有用戶的某些操作無響應(yīng)，然后更多相關(guān)的服務(wù)獲取不到數(shù)據(jù)，最后甚至用戶根本無法登錄系統(tǒng)。故障已經(jīng)發(fā)生，用戶已受到影響，當務(wù)之急是快速恢復機器工作，縮短故障時間。如果機器只是掉電宕機，設(shè)備并無大礙，重新啟動系統(tǒng)后一切恢復正常；如果磁盤等硬件發(fā)生故障，需要將應(yīng)用遷移到備份服務(wù)器，快速啟動備用服務(wù)器。

如何避免單點故障或者將單點故障的影響降到最低呢？

2）場景二：新增業(yè)務(wù)規(guī)則或?qū)σ郧皹I(yè)務(wù)規(guī)則的升級導致重新開發(fā)系統(tǒng)

系統(tǒng)經(jīng)過一兩年的運營逐步趨于穩(wěn)定，但產(chǎn)品團隊和開發(fā)團隊之間的爭論卻越來越多，產(chǎn)品團隊開始抱怨新的創(chuàng)意無法得到快速響應(yīng)，開發(fā)團隊沒日沒夜加班仍然有干不完的活，對系統(tǒng)功能的改造總是牽一發(fā)動全身，更別說開發(fā)新的業(yè)務(wù)。

如何讓架構(gòu)能夠適應(yīng)未來業(yè)務(wù)的發(fā)展，為潛在的擴展點進行設(shè)計？

3）場景三：春節(jié)期間活躍用戶激增導致系統(tǒng)性能下降

春節(jié)前，營銷團隊在電視媒體、平面媒體、網(wǎng)絡(luò)媒體等進行了全方位的營銷宣傳，而且效果非常明顯，春節(jié)期間活躍用戶數(shù)快速增長，甚至超過去年整年的增長，但隨之而來的是，隨著用戶數(shù)的增長，以前沒有發(fā)現(xiàn)的問題開始暴露出來，運營團隊不得不每天堅守崗位，甚至采用輪班制，但網(wǎng)站的響應(yīng)時間還是下降了，而且開始出現(xiàn)間隔性的中斷服務(wù)，用戶開始抱怨，開始選擇其他平臺。

如何應(yīng)對潛在的用戶數(shù)激增對系統(tǒng)服務(wù)質(zhì)量的影響？

大型互動平臺中好友動態(tài)系統(tǒng)的架構(gòu)挑戰(zhàn)主要來自于設(shè)備、服務(wù)和用戶，因此假設(shè)：1）所有的硬件和服務(wù)總會有故障；2）業(yè)務(wù)規(guī)則在運營過程總會發(fā)生變化；3）用戶數(shù)會在某個時間呈現(xiàn)爆炸式增長。

2 架構(gòu)模式和設(shè)計原則

2.1 架構(gòu)模式選擇

好友動態(tài)的架構(gòu)實現(xiàn)有兩種選擇：拉模式和推模式（見表1）。推模式，指用戶發(fā)表一條動態(tài)時，動態(tài)系統(tǒng)將這條動態(tài)拷貝N次分發(fā)給他的粉絲或好友；用戶讀取時，直接從“我的動態(tài)”和“好友動態(tài)”中讀取動態(tài)列表。拉模式，指當用戶查詢動態(tài)消息時，從所有好友的動態(tài)隊列中獲取動態(tài)，拿到這些動態(tài)后再做排序和合并操作；用戶發(fā)表動態(tài)時，直接發(fā)布到自己的隊列中。

表1 推模式與拉模式的比較

結(jié)合項目的實際需求，項目組認為推模式架構(gòu)簡單，能夠給用戶提供更好的產(chǎn)品體驗，而多占用的存儲空間是可以接受的。

2.2 架構(gòu)設(shè)計原則

針對好友動態(tài)系統(tǒng)架構(gòu)面臨的調(diào)整，項目組為架構(gòu)設(shè)計確定如下架構(gòu)原則[3]：

1）可靠性

可靠的服務(wù)是系統(tǒng)的基礎(chǔ)，隨著系統(tǒng)中設(shè)備數(shù)量、服務(wù)數(shù)量的增加，服務(wù)大規(guī)模分布式部署，可靠性的成本越來越高。服務(wù)的可靠性也不再局限于設(shè)備的可靠，設(shè)計可靠的軟件架構(gòu)才能從根本上提高系統(tǒng)可靠性。

2）可伸縮性

可伸縮性就是通過增加資源使服務(wù)容量產(chǎn)生線性（理想情況下）增長的能力?？缮炜s應(yīng)用程序的主要特點是：附加負載只需要增加資源，而不需要對應(yīng)用程序本身進行大量修改?？缮炜s性包括兩個方面，向上伸縮（Scale-Up）和水平伸縮（Scale-Out）。

向上伸縮指通過使用性能更好、速度更快和成本更高的硬件來實現(xiàn)可伸縮性。包括添加更多內(nèi)存、添加更多或更快的處理器，或者只是將應(yīng)用程序遷移到功能更強大的單個計算機。通常，該方法能夠在不改變源代碼的情況下增加容量。從管理角度而言，情況并未發(fā)生變化，因為要管理的仍然只是一臺計算機。

水平伸縮的實現(xiàn)需要使用多臺計算機，但計算機集合本質(zhì)上是作為單個計算機運行的。通過使若干臺計算機專門執(zhí)行常見的任務(wù)，增加了應(yīng)用程序容錯。當然，從管理員的角度看，外擴使計算機的數(shù)目增多，從而提出了更大的管理挑戰(zhàn)。

考慮到高性能設(shè)備成本昂貴，服務(wù)器都采用普通的PC或PC服務(wù)器，可伸縮性需要更多依賴水平伸縮，即通過更多的普通設(shè)備擴展系統(tǒng)整體容量。

3）高并發(fā)性

系統(tǒng)的注冊用戶數(shù)決定了必須解決大量用戶并發(fā)訪問系統(tǒng)的問題，而且隨著網(wǎng)站整體影響力的擴展，用戶數(shù)會更大。此外，為了提供更豐富的用戶體驗，在用戶登錄網(wǎng)站期間會定期訪問好友動態(tài)系統(tǒng)，獲得更新的數(shù)據(jù)。以1000萬注冊用戶為例，10萬用戶同時在線，每個用戶10 s刷新一次動態(tài)數(shù)據(jù)，那么每秒將會有10000個并發(fā)請求，這樣的規(guī)模是傳統(tǒng)網(wǎng)絡(luò)不可比擬的，也是好友動態(tài)系統(tǒng)架構(gòu)的重點。

4）大數(shù)據(jù)量

一個用戶的每一個操作都會以消息的形式通知給其全部數(shù)量的好友；同樣其全部好友的每一個操作也將以消息的形式通知給用戶。好友動態(tài)系統(tǒng)的特點決定了好友越多系統(tǒng)的數(shù)據(jù)量就會越大。數(shù)據(jù)顯示，在Facebook網(wǎng)站等級的粉絲，全球最具人氣的人物是當紅女歌星La?dy Gaga，她的注冊粉絲達到了2200萬。

5）業(yè)務(wù)規(guī)則可擴展

好友動態(tài)系統(tǒng)是互動平臺的核心引擎，幾乎所有應(yīng)用都需要通過好友動態(tài)系統(tǒng)與用戶進行互動，每個應(yīng)用的業(yè)務(wù)邏輯和數(shù)據(jù)標準又有很大的差異；而且為了保證消息質(zhì)量，具有良好的可閱讀性必須對用戶的消息進行合并。因此需要架構(gòu)設(shè)計支持靈活的業(yè)務(wù)規(guī)則。

3 架構(gòu)設(shè)計

3.1 整體架構(gòu)

好友動態(tài)系統(tǒng)整體上采用分布式系統(tǒng)架構(gòu)方法，消息按流水線的方式進行處理，分別由轉(zhuǎn)發(fā)服務(wù)器、分發(fā)服務(wù)器和消息服務(wù)器處理，其中最重要的好友關(guān)系信息從好友關(guān)系系統(tǒng)獲得，并緩存在關(guān)系緩存集群中。另外，為了實現(xiàn)自動化運營，好友動態(tài)系統(tǒng)提供了服務(wù)監(jiān)視系統(tǒng)和配置管理系統(tǒng)，如圖1所示。轉(zhuǎn)發(fā)服務(wù)器將客戶端發(fā)布的動態(tài)消息轉(zhuǎn)發(fā)到分發(fā)服務(wù)器；分發(fā)服務(wù)器對客戶端的消息進行預處理，并根據(jù)好友關(guān)系將動態(tài)消息推送到各個好友的消息服務(wù)器；好友關(guān)系緩存服務(wù)器為分發(fā)服務(wù)器提供好友關(guān)系緩存，提高分發(fā)服務(wù)器消息推送性能；消息服務(wù)器接收分發(fā)服務(wù)器推送的消息，對消息進行合并處理，存儲用戶的動態(tài)消息，并為用戶提供動態(tài)檢索服務(wù)。

3.2 關(guān)鍵架構(gòu)點

3.2.1 水平伸縮

大型互動系統(tǒng)的特點是用戶基數(shù)大，而且無法預測將來的用戶數(shù)會達到什么水平，因此設(shè)計之初就考慮采用水平伸縮方案。當用戶規(guī)模增長后，不需要修改系統(tǒng)的源代碼，只需要增加普通的PC或PC服務(wù)器，部署更多的分布式服務(wù)，就可以擴充系統(tǒng)的容量，提升系統(tǒng)的性能。

系統(tǒng)的整體架構(gòu)上，各個關(guān)鍵服務(wù)都支持水平伸縮，包括轉(zhuǎn)發(fā)服務(wù)器、分發(fā)服務(wù)器、消息服務(wù)器。

客戶端隨機選擇轉(zhuǎn)發(fā)服務(wù)器發(fā)布消息。當用戶數(shù)增加，要求轉(zhuǎn)發(fā)服務(wù)器集群提供更高的并發(fā)，更快的響應(yīng)時間時，可以部署更多的轉(zhuǎn)發(fā)服務(wù)器，降低單個服務(wù)器的負載，提升響應(yīng)時間。

用戶ID與分發(fā)服務(wù)器進行綁定，綁定的算法有靜態(tài)綁定算法、哈希求余算法、一致性哈希算法等，這些算法的復雜度依次提高，而進行依次下降，但服務(wù)器數(shù)量擴展的友好型也依次提高。根據(jù)好友動態(tài)系統(tǒng)用戶ID線性增長的特點，最終采用簡單有效的靜態(tài)綁定算法。轉(zhuǎn)發(fā)服務(wù)器將用戶的消息發(fā)布到該用戶綁定的分發(fā)服務(wù)器。當用戶數(shù)增加，要求分發(fā)服務(wù)器集群提供更高的并發(fā)，更快的響應(yīng)時間時，可以部署更多的分發(fā)服務(wù)器，這樣單個分發(fā)服務(wù)器承載的用戶數(shù)沒有變化，響應(yīng)時間也不會受到影響。

用戶ID與消息服務(wù)器進行綁定，仍然采用靜態(tài)綁定，一個消息服務(wù)器只為某個號段的用戶提供服務(wù)。當新注冊用戶增加時，最后一個服務(wù)器的壓力會不斷增加，再增加一臺服務(wù)器將新注冊的用戶號段劃分到這個服務(wù)器，從而控制最后一臺服務(wù)器的壓力；當某個號段的用戶活躍程度顯著增加時，可以將該號段重新劃分，進行負載均衡。

3.2.2 消息隊列

隊列使系統(tǒng)的各個模塊之間實現(xiàn)松耦合，將同步業(yè)務(wù)調(diào)用轉(zhuǎn)化為異步處理過程。在系統(tǒng)架構(gòu)方面，關(guān)鍵業(yè)務(wù)模塊之間都是通過消息隊列實現(xiàn)異步消息處理，如圖2所示。

在此架構(gòu)中，因為各個服務(wù)只關(guān)心與其交換的消息隊列，中間處理的各個服務(wù)的故障都不會影響都之前或之后的業(yè)務(wù)處理，而且服務(wù)恢復后能夠繼續(xù)提供服務(wù)。因此消息中間件的穩(wěn)定性和性能是衡量中間件的關(guān)鍵指標。Kestrel是twitter開源的消息隊列中間件[4]，在twit?ter以及大量網(wǎng)站中經(jīng)過實踐檢驗，穩(wěn)定性和性能都非常不錯，內(nèi)部測試也證明可以滿足項目的需求，因此項目組選擇kestrel作為消息中間件。而且Kestrel采用mem?cached兼容的協(xié)議，這也是大多消息隊列中間件支持的協(xié)議接口，即使系統(tǒng)運行中發(fā)現(xiàn)Kestrel隊列存在問題，也可以快速遷移到其他消息中間件。

各個服務(wù)模塊采用無狀態(tài)的服務(wù)模式，即服務(wù)模塊每次都根據(jù)消息隊列中的消息進行處理，這樣即使遇到一些惡意的非法消息也能夠正常處理，不會影響其他消息的處理。

此外消息隊列還有蓄洪的作用。好友動態(tài)系統(tǒng)中，當發(fā)生特殊事件時用戶會有一個爆發(fā)效應(yīng)，比如世界杯期間活躍用戶數(shù)會有爆炸式增長。消息隊列的作用是，當洪峰到來時，快速容納大量請求，從而不影響隊列前端應(yīng)用的性能，然后隊列后端的應(yīng)用慢慢處理隊列中的消息。對于動態(tài)系統(tǒng)來說，只是延遲了動態(tài)被好友感知的時間，而且這種延遲好友是很難感知的，但對系統(tǒng)的負載能力的提升非常明顯。

3.2.3 緩存機制

眾所周知，內(nèi)存的訪問速度遠遠高于硬盤的訪問速度，因此緩存的效果對網(wǎng)站的響應(yīng)時間至關(guān)重要。緩存將系統(tǒng)中需要大量計算或頻繁訪問的資源由硬盤轉(zhuǎn)移到內(nèi)存中，降低系統(tǒng)IO的處理的時間，從而提高訪問的響應(yīng)時間。

系統(tǒng)架構(gòu)方面緩存主要應(yīng)用在分發(fā)服務(wù)器和消息服務(wù)器。

分發(fā)服務(wù)器中，每個消息的處理都需要用戶的好友關(guān)系，這些信息存儲在好友關(guān)系數(shù)據(jù)庫中，如果每次處理都直接訪問數(shù)據(jù)庫，每秒大概需要2000次并發(fā)的數(shù)據(jù)庫訪問，這樣的壓力對數(shù)據(jù)庫來說是致命的，很快就會發(fā)現(xiàn)已經(jīng)連不上數(shù)據(jù)庫，而且查詢數(shù)據(jù)庫的響應(yīng)時間也會很長。因此將好友關(guān)系加載到內(nèi)存中，將極大地提升查詢性能，而且好友關(guān)系的緩存命中率也決定了分發(fā)服務(wù)器的消息處理性能。

為用戶關(guān)系緩沖設(shè)計了兩個功能模塊，緩存服務(wù)器集群和用戶關(guān)系變更通知服務(wù)。前者將好友關(guān)系數(shù)據(jù)庫中的好友信息緩存在內(nèi)存中；后者在好友關(guān)系數(shù)據(jù)庫發(fā)生變更時，及時將變更的信息更新到緩存服務(wù)器集群。

消息服務(wù)器一方面接收分發(fā)服務(wù)器寫入的消息，另一方面響應(yīng)客戶端的查詢消息，而且兩者都存在大量的并購，對響應(yīng)時間也有一定要求，因此都設(shè)計了緩存機制。

為了提高分發(fā)服務(wù)器寫入消息的性能，消息服務(wù)器在接收消息后立即將消息寫入內(nèi)部的消息緩存隊列中，而不用等待消息合并到用戶的消息隊列中。

在大量注冊用戶中，有一部分用戶比較活躍，另外一部分用戶相對沉寂，客戶端的查詢請求大并發(fā)是活躍用戶的請求，而且活躍用戶往往會連續(xù)發(fā)送多次查詢請求，因此消息服務(wù)器會緩存活躍用戶的消息隊列。對活躍用戶判斷是否準確也決定了緩存的效果，那么如何判斷活躍用戶？本文采用最近訪問作為判斷依據(jù)，即如果用戶訪問時用戶的消息隊列不在內(nèi)存中，那么訪問過后將會被加載到內(nèi)存中，下次訪問時直接從內(nèi)存中讀取。當內(nèi)存不足時，將會替換內(nèi)存中最長時間未被訪問的內(nèi)容。

3.2.4 數(shù)據(jù)格式

數(shù)據(jù)采用互聯(lián)網(wǎng)廣泛應(yīng)用的JSON格式，在流水線的處理過程中數(shù)據(jù)格式也在不斷發(fā)生變化。

客戶端采用轉(zhuǎn)發(fā)服務(wù)器的數(shù)據(jù)格式發(fā)送消息，格式如圖3所示。

分發(fā)服務(wù)器將轉(zhuǎn)發(fā)服務(wù)器的數(shù)據(jù)結(jié)構(gòu)轉(zhuǎn)換成分發(fā)服務(wù)器數(shù)據(jù)機構(gòu)，并分發(fā)到消息服務(wù)器，格式如圖4所示。

分發(fā)服務(wù)器的消息經(jīng)消息服務(wù)器處理后，轉(zhuǎn)換成消息服務(wù)器的數(shù)據(jù)格式，格式如圖5所示。

3.2.5 協(xié)議接口

各個服務(wù)模塊主要提供對動態(tài)消息讀寫、刪除接口，而且動態(tài)消息的排序、合并都按內(nèi)部確定的合并規(guī)則執(zhí)行。此外，服務(wù)器內(nèi)部狀態(tài)的監(jiān)視接口為服務(wù)器狀態(tài)監(jiān)視提供了方便，控制接口則讓服務(wù)升級更加安全。

通信協(xié)議有很多選擇，如支持REST架構(gòu)風格的HTTP協(xié)議、SOAP協(xié)議和memcached協(xié)議，即時通信領(lǐng)域的XMPP協(xié)議等，但最終本文選擇了memcached協(xié)議，其一該協(xié)議支持REST架構(gòu)風格，適合于資源訪問類服務(wù)；其二該協(xié)議支持廣泛的客戶端開發(fā)語言，如Java、C＋＋、Php、Python、Perl等；其三，系統(tǒng)中消息隊列和內(nèi)存緩存中間件支持該協(xié)議，因此采用memcached協(xié)議的開發(fā)成本和風險是最小的。

4 核心服務(wù)的設(shè)計與實現(xiàn)

4.1 轉(zhuǎn)發(fā)服務(wù)器

轉(zhuǎn)發(fā)服務(wù)器的主要難點在于支持大量客戶端并發(fā)訪問。Apache Mina是一個Java NIO框架，為用戶開發(fā)高性能和高擴展的網(wǎng)絡(luò)應(yīng)用服務(wù)器帶來的方便，因此本文選擇基于Mina框架設(shè)計轉(zhuǎn)發(fā)服務(wù)器。本文的測試數(shù)據(jù)顯示，基于Mina的轉(zhuǎn)發(fā)服務(wù)器可以支持每秒1000次網(wǎng)絡(luò)消息處理，通過接收緩沖區(qū)大小還可以進一步提高消息的吞吐量。

4.2 分發(fā)服務(wù)器

分發(fā)服務(wù)器中最重要的設(shè)計是消息處理擴展框架，支持靈活的業(yè)務(wù)擴展。

消息的預處理框架，需要針對每種業(yè)務(wù)類型進行單獨的處理，并且要考慮以后新增業(yè)務(wù)類型或修改業(yè)務(wù)處理規(guī)則時，盡可能不影響系統(tǒng)其他組件。因此消息處理擴展框架基于OSGi框架進行設(shè)計。

OSGi又叫做Java語言動態(tài)模塊系統(tǒng)[5-6]，它為模塊化應(yīng)用的開發(fā)定義了一個基礎(chǔ)架構(gòu)。在OSGi中，軟件是以Bundle的形式發(fā)布的。一個Bundle由Java類和其他資源構(gòu)成，它可為其他的Bundle提供服務(wù)，也可以導入其他Bundle中的Java包。

消息處理流程如圖6所示，各個Business Processor組織成一個處理鏈，有Message Processor Center進行調(diào)度，并根據(jù)當前Business Processor的處理返回值決定下一步調(diào)用哪個Processor，最后一個Business Processor將處理后的消息寫入輸出消息隊列。

Business Processor支持兩種范圍類型：Next、Term和ProcessorID。 當 Business Processor返 回 Next，Message Processor Center調(diào)用預定義的下一個Business Proces?sor；當 Business Processor返回 Term，Message Processor Center終止當前消息處理鏈，處理下一條消息。

消息處理過程中，Business Processor可以將消息輸出到其他系統(tǒng)，并不影響下一步業(yè)務(wù)的處理；也可以將消息丟棄，從而實現(xiàn)消息過濾器的作用。

4.3 消息服務(wù)器

4.3.1 動態(tài)消息數(shù)據(jù)庫

動態(tài)消息數(shù)據(jù)庫通過分庫來優(yōu)化性能，包括緩存庫、索引庫和消息庫。

消息分發(fā)時，首先將消息分發(fā)到緩存庫，然后由消息處理進程分批處理；而在動態(tài)查詢時，首先訪問索引庫獲取用戶的消息隊列（我的動態(tài)隊列或好友動態(tài)隊列）獲取動態(tài)的索引，然后根據(jù)動態(tài)ID從消息庫中獲取動態(tài)消息，并將結(jié)果合并返回給用戶。

采用增加消息緩存庫主要出于兩方面考慮，一方面隔離了分發(fā)系統(tǒng)和消息服務(wù)器，分發(fā)服務(wù)器發(fā)布消息與消息服務(wù)器處理消息可以異步處理，只需要將消息發(fā)布到緩存庫，而不必等待消息服務(wù)器處理消息，提高分發(fā)系統(tǒng)的性能。另一方面緩存庫在不影響消息讀寫性能的情況下，又保證了消息可靠性，消息被持久化保存在緩存庫。

將索引庫和消息庫分離，降低了推模式下消息數(shù)據(jù)庫中重復消息的數(shù)量。一個動態(tài)的索引大約23～42 byte，而一個動態(tài)消息平均大小是1 kbyte，這樣一個消息庫只保存一份動態(tài)消息，每個消息將節(jié)約980 byte。比如一個名人在消息服務(wù)器上的好友10萬個，那么該名人每條動態(tài)將節(jié)約98 Mbyte數(shù)據(jù)。

4.3.2 備份與遷移

采用NoSQL數(shù)據(jù)庫帶來了高性能，同時也要面臨NoSQL數(shù)據(jù)庫備份遷移工具缺乏的現(xiàn)狀，為此開發(fā)了針對動態(tài)消息數(shù)據(jù)庫的備份和遷移工具。

備份工具支持動態(tài)消息數(shù)據(jù)庫熱備份、增量備份，因此設(shè)置計劃任務(wù)每天執(zhí)行本機備份，并將備份數(shù)據(jù)自動遷移到備份服務(wù)器。消息服務(wù)器故障時，可以快速部署消息服務(wù)器應(yīng)用，并從備份服務(wù)器下載相應(yīng)的動態(tài)消息數(shù)據(jù)庫，快速恢復服務(wù)。

遷移工具支持根據(jù)用戶空間進行消息數(shù)據(jù)庫合并。由于用戶ID與消息數(shù)據(jù)庫采用靜態(tài)綁定策略，重新劃分用戶空間將涉及到歷史數(shù)據(jù)的遷移，比如系統(tǒng)運行一段時間后，發(fā)現(xiàn)某些消息服務(wù)器中活躍用戶數(shù)少，負載小，可以將這些消息服務(wù)器合并成一臺消息服務(wù)器。

5 小結(jié)

系統(tǒng)測試數(shù)據(jù)顯示，好友動態(tài)系統(tǒng)架構(gòu)能夠滿足大量用戶并發(fā)訪問、響應(yīng)時間較快，而且架構(gòu)能夠通過水平伸縮快速擴容系統(tǒng)支持用戶規(guī)模，在穩(wěn)定性方面單個服務(wù)或硬件的故障對系統(tǒng)影響較小或只影響一定范圍的用戶。到目前為止，好友動態(tài)系統(tǒng)已經(jīng)上線運行兩個多月，表現(xiàn)穩(wěn)定可靠，友好地支撐了互動平臺好友動態(tài)的分發(fā)。

[1]CNNIC第27次互聯(lián)網(wǎng)報告：個人互聯(lián)網(wǎng)應(yīng)用狀況[EB/OL].（2011-01-19）[2011-04-01].http：//it.people.com.cn/GB/119390/118340/212787/212790/13765052.html.

[2]中國互聯(lián)網(wǎng)協(xié)會.中國Web2.0發(fā)展狀況和調(diào)查報告[R].北京：中國互聯(lián)網(wǎng)協(xié)會，2006.

[3]郭欣.構(gòu)建高性能Web站點[M].北京：電子工業(yè)出版社，2009.

[4]鄧侃.解剖Twitter：Twitter系統(tǒng)架構(gòu)設(shè)計分析[EB/OL].（2010-03-27）[2011-04-01].http：//www.tektalk.org.

[5]基于OSGi實現(xiàn)分布式服務(wù)框架歷程[EB/OL].（2008-01-14）[2011-02-01].http：//www.blogjava.net/BlueDavy/archive/2008/01/14/175054.html.

[6]Oracle.Oracle Berkeley DB Java editionhigh availability-large configuration and scalability testing[EB/OL].[2011-03-25].http：//www.oracle.com/technetwork/database/berkeleydb/bdb-je-highavailabilitywhitepaper--129298.pdf.