低成本分布式郵件備份系統(tǒng)的設計和實現(xiàn)

劉 波，楊 強

（趨勢科技中國研發(fā)中心，江蘇 南京 210012）

在一個在線電子郵件掃描系統(tǒng)中，需要設計一個安全可靠的存儲系統(tǒng)，暫時保存被隔離的電子郵件。這些郵件一直保留在系統(tǒng)內，直到用戶選擇釋放或者到期失效。這是一個需要精心設計的系統(tǒng)，考慮牽涉到的數(shù)據(jù)量和在線系統(tǒng)所要求的高可靠性，如何用盡可能低的成本實現(xiàn)這個系統(tǒng)，成為項目團隊面對的主要挑戰(zhàn)。

1 分布式郵件備份系統(tǒng)的技術需求和設計原則

郵件備份系統(tǒng)最基本的要求是高吞吐量，具體來講，要求能達到每秒1 000封郵件（平均大小10 KB）的最大輸入速度，用戶的郵件要能保存最多60天，系統(tǒng)總容量在20 TB以上，用戶的檢索速度應該控制在1 s以內。

作為一個商業(yè)運營的在線系統(tǒng)，除了具備很高的性能以外，還要具備很高的可靠性和盡可能低的成本。系統(tǒng)的 SLA[1]（Service Level Agreement）要達到 99.99%以上，也就是說運行一年的停機時間必須控制在52 min以內。在線系統(tǒng)的主要成本包括數(shù)據(jù)中心的成本和運行維護成本。數(shù)據(jù)中心的成本主要由硬件成本、網(wǎng)絡成本、其他成本如電費、冷卻、機架空間等構成，而運營成本主要由運營維護、技術支持等費用構成。依據(jù)上述基本要求，確定了郵件備份系統(tǒng)的基本技術需求：(1)單機高效率，系統(tǒng)高吞吐；(2)使用低成本硬件，避免使用昂貴硬件；(3)提供高可伸縮性；(4)部署自動化；(5)管理智能化。

根據(jù)上述需求，確立系統(tǒng)整體設計的原則，主要包括下述四點：

（1）低耦合。耦合是指系統(tǒng)的子模塊之間結合的緊密程度，一個低耦合的系統(tǒng)不但要降低模塊之間的靜態(tài)依賴關系，而且要盡可能地降低模塊在時間和空間上的依賴關系。低耦合的系統(tǒng)可以降低模塊之間的相互影響，提高系統(tǒng)的擴展性。

（2）無狀態(tài)。無狀態(tài)的服務不在內部保留狀態(tài)數(shù)據(jù)，上一個請求和下一個請求之間沒有任何關系。無狀態(tài)的服務更容易實現(xiàn)水平擴展。

（3）異步通信。異步通信可以提高通信的效率，請求發(fā)送者無需等待服務的返回，節(jié)點之間不需要互相等待，可以提高每個節(jié)點的處理效率。

（4）自適應。自適應的系統(tǒng)能夠自動調整、優(yōu)化運行參數(shù)、應對運行環(huán)境的變化。能夠自我調整，也就減少了人為干預的要求，降低了維護費用，而且自動調整顯然比人為干預反應更快、也更準確，所以也提高了可靠性。

2 分布式郵件備份系統(tǒng)的設計

2.1 整體框架設計

系統(tǒng)的整體設計采用SOA[2]的架構，系統(tǒng)由三種不同的角色構成，其關系如圖1所示。

圖1 基于SOA的設計

組件A和B完成系統(tǒng)特定的某些功能，A和B對外部提供Restful[3]風格的Web應用接口，但是A和B之間互相沒有調用關系，也不知道彼此的存在。Registry是一個注冊服務器[4]，所有的組件都在Registry注冊，并不斷通過心跳信號更新自己的狀態(tài)到Registry；而且Registry維護一張系統(tǒng)所有組件的狀態(tài)表，對于超時沒有更新的組件，就將其從列表中刪除。Helper負責將數(shù)據(jù)從一個組件傳送到另一個組件；可以從Registry得到當前系統(tǒng)的所有組件清單以及組件之間的邏輯聯(lián)系關系，并據(jù)此進行數(shù)據(jù)轉運工作；使用標準的HTTP命令從一個組件的輸出隊列得到數(shù)據(jù)，然后同樣用HTTP命令將數(shù)據(jù)發(fā)送到下游的組件。

同一類型的組件可以同時有多個實例存在，以提供高可靠性和任務負載的均衡擴充。Helper本身也可以有多個實例存在，提供多個上游組件和下游組件之間的動態(tài)數(shù)據(jù)交換和負載均衡。

組件工作在異步的模式下，每個組件都有一個輸入隊列和一個輸出隊列，需要處理的數(shù)據(jù)通過Web接口被放進輸入隊列，組件的數(shù)據(jù)處理程序依次從輸入隊列讀取數(shù)據(jù)，處理完成后放入輸出隊列，然后通過Web接口被取走。組件擁有完成處理工作所需要的所有資源和數(shù)據(jù)，可以獨立完成自己的任務。這是保證組件異步、高效工作的重要前提條件。

一個最簡單的系統(tǒng)至少包括三種不同的功能組件，它們分別是 Generator、Processor和 Terminator。 它們之間的關系如圖2所示。

圖2 基本處理流程

Generator是任務的發(fā)起方，一個Generator至少有一個任務輸出隊列和一個對應的ACK輸入隊列。Generator產生的任務數(shù)據(jù)在任務輸出隊列中排隊等候Helper轉送到Processor進行處理。一旦一個任務被送到Processor，這個任務就被放入一個等候確認的隊列，等候任務完成的確認。Processor至少有一個任務輸入隊列和一個結果輸出隊列，即從任務輸入隊列取得待處理任務，進行處理后放入結果輸出隊列，由Helper送到Terminator。Terminator對結果進行最后的處理后，生成對應的ACK，ACK被送回Generator，完成一個完整的任務處理生命周期。如果Generator在規(guī)定時間里沒有收到一個任務的ACK，說明這個任務可能在系統(tǒng)內被丟失了，按不同的業(yè)務邏輯，Generator可以重新發(fā)送這個任務，也可以丟棄這個任務。確認-重發(fā)機制保證了異步系統(tǒng)中數(shù)據(jù)的可靠性問題，較好地解決了節(jié)點失效時丟失任務的問題。此外，通過Helper橋接的設計允許在一個任務處理序列里組合多個不同的Processor來完成復雜的任務而不用修改程序，這種重組甚至可以在運行中的系統(tǒng)上動態(tài)完成，大大提高了系統(tǒng)的彈性。

圖3是郵件備份系統(tǒng)的架構圖，主要的組件是QtStorage和QtDAL。QtStorage負責存儲郵件的原始信息（包括郵件的原文、發(fā)送者、接收者等信息），將收到的郵件寫入存儲區(qū)域后，會將郵件及相關信息編制成摘要。QtDAL負責將郵件的摘要存儲在數(shù)據(jù)庫中，并為用戶提供檢索服務。為了實現(xiàn)高效率的運作，存儲系統(tǒng)的設計采用了讀寫分開的思想。大量原始數(shù)據(jù)的寫入在QtStorage上完成，QtStorage擁有多個實例，可以分散寫入的壓力，同時也能夠提供多重冗余，實現(xiàn)高可用性。QtStorage可以實現(xiàn)無縫的橫向擴展，其存儲能力和容量隨之擴展。經(jīng)過QtStorage處理過的摘要信息，其容量已經(jīng)大大縮減，所以可以采用單一的索引節(jié)點來保存，單一節(jié)點可以以較低的代價實現(xiàn)數(shù)據(jù)的一致性。這里的QtDAL就是這樣的一個索引節(jié)點，用戶的查找和讀取主要發(fā)生在QtDAL上，查找和讀取索引信息和數(shù)據(jù)的寫入發(fā)生在不同的節(jié)點上，這樣就實現(xiàn)了數(shù)據(jù)的讀寫分開，提高了運行效率。只有在用戶需要取回被隔離的原始郵件時，才會到QtStorage上去讀取，按照系統(tǒng)的設計邏輯，這是一個概率極低的操作，不會對系統(tǒng)構成很大的影響。

圖3 系統(tǒng)架構圖

2.2 文件存儲服務

文件存儲服務為整個系統(tǒng)提供原始數(shù)據(jù)的存儲服務。根據(jù)經(jīng)驗，這部分的成本是整個系統(tǒng)成本的主要構成部分。為了保持低成本，必須避免使用價格昂貴的高性能存儲設備，如SAN、NAS等。而且為了便于擴展和維護，一些需要特別硬件支持的存儲設備也不能考慮，如RAID陣列等。一個可行的設計思路是使用最廉價的PC和隨機安裝的硬盤來構成系統(tǒng)。商用的PC可以安裝4個處理核心的CPU和2 TB以上的硬盤，其性能和容量已經(jīng)足以滿足系統(tǒng)的需求。但是不論是PC的硬件還是硬盤本身，其可靠性和穩(wěn)定性都不能達到99.99%的可靠性。解決的方法是用多重冗余的方式構建系統(tǒng)，不但數(shù)據(jù)的保存是多重冗余的，而且處理節(jié)點也是多重冗余的。

2.2.1 數(shù)據(jù)的寫入

圖4是文件存儲系統(tǒng)的設計。Storage 1～3是3個存儲節(jié)點，各自帶有2 TB的硬盤存儲數(shù)據(jù)，并對外開放3個Web接口，分別是接收文件輸入的 Input Queue、輸出文件索引信息的Index Queue和輸出文件同步包的Sync Queue。一個文件的存儲過程可以用以下步驟描述：

（1）Helper隨機挑選一個 Storage節(jié)點 （例如 Storage 1），將待保存的文件及控制信息一起發(fā)送到Storage 1的Input Queue。

（2）Storage 1將文件存盤，生成文件的索引信息，將索引放到Index Queue。

（3）Storage 1修改文件控制信息，將文件和控制信息添加到Sync Queue。

（4）Helper從 Storage 1的 Sync Queue中將待同步文件取出，送到另一個Storage節(jié)點（例如Storage 2）。

（5）Helper將索引信息從 Storage 1取出，送到數(shù)據(jù)庫保存。

（6）Storage 2重復上述步驟，直到重復存儲次數(shù)達到需要的冗余度為止。

圖4 文件存儲流程

這個設計的主要特點如下：

（1）每個Storage節(jié)點都同時具有處理能力和存儲容量，添加節(jié)點就可以同時擴展處理能力和容量，系統(tǒng)的擴展是對稱的，非常利于管理和維護。

（2）Storage節(jié)點之間沒有相互依賴性，任何一個Storage節(jié)點因為故障下線，都不會對整個系統(tǒng)產生影響。

（3）每個文件需要多少冗余度、是否加密、是否壓縮，都可以單獨控制，非常靈活。

（4）添加新的 Storage節(jié)點后，負載會自動均衡到新的節(jié)點上，有利于資源的有效利用。

（5）系統(tǒng)要求的保存文件期限最多 60天，所以在 3冗余或更多冗余的情況下，可以不用考慮損壞節(jié)點的文件恢復功能。即使使用可靠性較低的普通PC和SATA硬盤，也可以保證文件在60天內的可用性。

（6）讀寫分開，大負荷的文件寫入被分散到數(shù)量眾多的Storage節(jié)點上，數(shù)據(jù)庫節(jié)點只負責少量、偶爾的用戶查詢操作，提高了硬件效率，降低了成本。

（7）系統(tǒng)并不是嚴格一致的，通過犧牲部分一致性，獲得了較好的擴展性和可用性，是CAP[5]原則的具體實踐。

（8）Storage節(jié)點之間是沒有聯(lián)系、沒有交互的，所有的數(shù)據(jù)交換都通過Helper進行。文件的控制信息隨同文件數(shù)據(jù)本身傳送，沒有任何一個節(jié)點管理和追蹤文件的去向，各個節(jié)點間通過合作完成任務，沒有中心控制節(jié)點。這個過程充分體現(xiàn)了“低耦合”、“異步”、“無狀態(tài)”的設計原則。

需要說明的是，Storage節(jié)點的數(shù)目建議大于系統(tǒng)設置的最高冗余度。例如對于3冗余的系統(tǒng)，Storage節(jié)點建議至少設置4個，這樣，在某一個節(jié)點因故下線的時候，系統(tǒng)仍然可以正常運行。當然，設置更多的節(jié)點可以獲得更好的可靠性和性能。

2.2.2 數(shù)據(jù)的查詢

數(shù)據(jù)的查詢相當簡單，按照用戶提供的查詢條件，可以在數(shù)據(jù)庫中查詢到符合條件的記錄，每條記錄中都包含對應的數(shù)據(jù)文件在Storage節(jié)點上的位置。如果用戶需要讀取原始數(shù)據(jù)，可以調用Storage節(jié)點上的API接口，提供位置信息，讀取原始數(shù)據(jù)。記錄中包含文件的多個冗余備份的位置，如果一個節(jié)點失效或者不能訪問，可以讀取備用節(jié)點上的信息。

2.2.3 數(shù)據(jù)的刪除

數(shù)據(jù)的刪除分為數(shù)據(jù)庫記錄的刪除和數(shù)據(jù)文件的刪除，數(shù)據(jù)庫節(jié)點和Storage節(jié)點都有內置的定時任務，可以按時間刪除已經(jīng)過期的數(shù)據(jù)。

2.2.4 系統(tǒng)容量的擴展和故障節(jié)點的替換

當文件存儲系統(tǒng)的容量不能滿足要求時，需要對系統(tǒng)容量進行擴展，這種擴展應該是一種簡單的、無縫的操作，不能干擾系統(tǒng)的正常運行，不需要修改軟件，不需要停機以及盡量少的配置改動。本系統(tǒng)較好地實現(xiàn)了上述要求。

2.3 索引數(shù)據(jù)庫

索引數(shù)據(jù)庫保存著所有備份郵件的索引信息和位置信息。這是一個標準的關系型數(shù)據(jù)庫，采用開源的PostgresSQL實現(xiàn)。數(shù)據(jù)庫主要包括兩張表，如圖5所示。

圖5 數(shù)據(jù)庫表

主表qt_files保存郵件的摘要信息，例如郵件主題、發(fā)送時間、發(fā)送者等，用戶可以提供條件快速查詢到符合的郵件。qt_file_entries表里存放郵件具體的備份位置，包括所屬節(jié)點、在節(jié)點里的定位信息等。每封郵件對應有多個位置記錄，都通過外鍵聯(lián)接到主表上。

3 性能測試結果及分析

3.1 測試系統(tǒng)配置

為了盡量降低成本，本文選用普通的PC代替昂貴的服務器完成處理工作。在這個測試中，采用了4臺DELL 780MT 構 成 系 統(tǒng) ，CPU為 IntelQ8400， 主 頻2.66 GHz，內存 8 GB，配備2 TB的SATA硬盤。4個節(jié)點通過千兆交換機連接。

3.2 性能數(shù)據(jù)

測試中，通過前端不斷地灌入郵件，記錄系統(tǒng)能夠穩(wěn)定持續(xù)處理的最高上限，即為系統(tǒng)的最大性能點。為了考察不同大小的郵件對性能的影響，每種配置下，都用10 KB和30 KB的郵件測試兩組數(shù)據(jù)。

圖6是單節(jié)點配置下的性能數(shù)據(jù)，在單節(jié)點情況下，10 KB的郵件速率達到 1 800封/s，30 KB的則達到1 400封/s，完全達到了系統(tǒng)的設計要求。

為了提高數(shù)據(jù)的安全性，可以設置將備份的郵件在不同節(jié)點上拷貝多份冗余。圖7即為冗余度設置為2時的測試數(shù)據(jù)，考察了不同節(jié)點數(shù)量對性能的影響?？梢钥吹剑S著系統(tǒng)節(jié)點數(shù)的增加，系統(tǒng)性能也呈基本線性地增加，這充分反映了節(jié)點間異步通信的重要性。異步通信削弱了節(jié)點間在時間上的依賴關系，通過犧牲局部的、臨時的一致性，充分發(fā)揮了每個節(jié)點的處理能力，提高了系統(tǒng)的效率。

為了進一步提高數(shù)據(jù)可靠性，可以把冗余度設置到3，此時每封郵件在系統(tǒng)內有三份拷貝，達到了極高的可靠性。如圖8所示，在4節(jié)點3冗余的測試環(huán)境下，系統(tǒng)的吞吐速率達到了3 000封/s（10 KB郵件）和2 000封/s（30 KB郵件）。如果等價成單個節(jié)點的平均速率的話，分別達到2 250封/s和1 500封/s，比單節(jié)點的性能還要好些。這是因為隨節(jié)點的增多，不但存儲空間得到擴展、可靠性得到增加，CPU的數(shù)量和處理能力也得到加強，更多的CPU的加入，也在一定程度上提高了系統(tǒng)的整體處理能力。

3.3 結果分析

通過對結果的分析，發(fā)現(xiàn)在單節(jié)點場景下，采用30 KB郵件樣本時系統(tǒng)達到了42 MB/s的寫入速度，而10 KB郵件的寫入速度為18 MB/s，兩種測試環(huán)境中CPU占用均為30%左右，說明系統(tǒng)瓶頸不在CPU和I/O中。通過對代碼實現(xiàn)的審查發(fā)現(xiàn)，問題主要是同步寫文件導致的，對文件的同步讀寫操作降低了I/O的效率，并且隨樣本的縮小，讀寫操作的頻繁化而更趨惡化。這就是為什么小樣本性能不成比例增加的根本原因。全面采用異步磁盤I/O操作可以很好地改善這個問題，但是異步I/O程序遠較同步I/O復雜，而且在本項目里，即使是同步I/O也足夠滿足性能需求，所以本設計最后決定保持目前的代碼不變。

比較不同組合條件下的測試結果可以發(fā)現(xiàn)，性能隨冗余度的增加而降低、隨節(jié)點數(shù)目的增加而提高，三者間的關系接近線性關系。如果節(jié)點數(shù)目增加一倍，性能也能夠增加一倍。增加冗余度會降低性能，但可以通過增加節(jié)點來補償。同時添加節(jié)點數(shù)量和冗余度，能夠得到更好的可靠性和性能，并且收益并不隨節(jié)點數(shù)目的增加而遞減。對于一個分布式系統(tǒng)，這是一個非?？少F的特質。因為管理者可以通過簡單的添加處理節(jié)點，獲取更多的存儲和處理能力。

為了最大限度地降低成本、提高可靠性，在設計的初期階段就確立了低耦合、無狀態(tài)、異步通信和自適應這四個設計準則。通過放寬對一致性的要求，僅保證最終一致性，充分解耦各個節(jié)點間的依賴關系，獲得了優(yōu)異的可靠性和可擴展性。最終的測試結果也證明了這種設計思路的正確性，采用普通桌面計算機和廉價磁盤組成的系統(tǒng)足以在容量、性能、可靠性和可擴展性方面滿足要求，而成本僅為傳統(tǒng)方案的十分之一。

[1]TANENBAUMA S，STEEN M V.Distributedsystems principles and paradigms[M].楊劍鋒，常曉波，李敏，譯，北京：清華大學出版社，2004.

[2]JOSUTTIS N M.SOA in practice[M].程 樺 ，譯.北 京 ：電子工業(yè)出版社，2008.

[3]ROCHARDSON L， RUBY S.RESTful Web Services中文版[M].徐涵，李紅軍，胡偉，譯.北京：電子工業(yè)出版社，2008.

[4]杜宗霞，懷進鵬，主動分布式Web服務注冊機制研究與實現(xiàn)[J]. 軟件學報，2006，17（3）：454-462

[5]BREWER E A.Towards robust distributed systems.（Invited Talk）Principles of Distributed Computing， Portland，Oregon，July 2000.