消息中間件持久化研究

摘 要：本文從消息中間件的定義、基本體系結(jié)構(gòu)入手，介紹消息中間件持久化的意義，著重提出了幾種持久化的解決方案，同時(shí)分析了這幾種解決方案各自適用的場景和性能。

關(guān)鍵詞：消息中間件；持久化；高可用；容錯(cuò)

中圖分類號(hào)：TN915

1 消息中間件概述

中間件是介于應(yīng)用系統(tǒng)和系統(tǒng)軟件之間的一類軟件，它使用系統(tǒng)軟件所提供的基礎(chǔ)服務(wù)（功能），銜接網(wǎng)絡(luò)上應(yīng)用系統(tǒng)的各個(gè)部分或不同的應(yīng)用，能夠達(dá)到資源共享、功能共享的目的。消息中間件也稱消息服務(wù)，是一種由消息傳送機(jī)制或消息隊(duì)列模式組成的中間件技術(shù)，利用高效可靠的消息傳遞機(jī)制進(jìn)行平臺(tái)無關(guān)的數(shù)據(jù)交流，并基于數(shù)據(jù)通信來進(jìn)行分布式系統(tǒng)的集成。一個(gè)典型的消息中間件體系結(jié)構(gòu)如圖1所示。

圖1 消息中間件體系結(jié)構(gòu)

根據(jù)JMS規(guī)范定義，消息中間件應(yīng)提供可選擇的消息在服務(wù)器端的可靠性級(jí)別，即持久化消息和非持久化消息，持久化消息指消息在服務(wù)器端存儲(chǔ)后轉(zhuǎn)發(fā)，當(dāng)服務(wù)器發(fā)生故障或者正常退出后，能夠在重啟后恢復(fù)現(xiàn)場。此外在用戶對(duì)主題進(jìn)行持續(xù)訂閱的應(yīng)用場景下，如果不支持對(duì)消息的持久化存儲(chǔ)，訂閱者就不能收到它在不活動(dòng)狀態(tài)下，發(fā)布者發(fā)布到主題的消息。當(dāng)然，持久化消息對(duì)消息中間件服務(wù)器的性能有一定影響。主要目的是為了滿足消息中間件的高可用。

消息持久化存儲(chǔ)的原理很簡單，就是在消息的發(fā)布者將消息發(fā)布到服務(wù)器端時(shí)，先將消息存儲(chǔ)到本地文件、數(shù)據(jù)庫或者分布式文件系統(tǒng)等，然后再試圖將消息轉(zhuǎn)發(fā)給相應(yīng)的接收者，并且更新該消息狀態(tài)。直到所有訂閱者都收到消息后將消息從存儲(chǔ)中刪除，并且由圖1所知，消息服務(wù)運(yùn)行過程中，只有持久化的數(shù)據(jù)需要存儲(chǔ)到磁盤等持久化設(shè)備上，所以持久化方案是消息中間件轉(zhuǎn)發(fā)消息的性能瓶頸，決定了消息中間件的吞吐量。

2 基于文件的消息持久化方法

2.1 存儲(chǔ)模型

層次模型，基于文件的消息持久化存儲(chǔ)模型采用的是層級(jí)結(jié)構(gòu)，邏輯結(jié)構(gòu)上分為應(yīng)用程序訪問接口、文件存儲(chǔ)層來實(shí)現(xiàn)。

圖2 文件持久化存儲(chǔ)模型

持久化訪問接口的設(shè)計(jì)是期望通過消息中間件業(yè)務(wù)邏輯與持久化邏輯實(shí)現(xiàn)分離，通過模塊化、松耦合的方式降低軟件設(shè)計(jì)實(shí)現(xiàn)以及維護(hù)的復(fù)雜性，有助于明確各模塊的具體功能，明確職責(zé)以幫助實(shí)現(xiàn)更加健壯的持久化模塊。程序訪問接口的實(shí)現(xiàn)，參照hibernate的設(shè)計(jì)概念，實(shí)現(xiàn)結(jié)構(gòu)化數(shù)據(jù)到關(guān)系對(duì)象的映射，在消息中間件的主題與隊(duì)列，存儲(chǔ)-轉(zhuǎn)發(fā)消息的業(yè)務(wù)邏輯中，軟件操作的是結(jié)構(gòu)化的數(shù)據(jù)，當(dāng)消息持久化到磁盤上時(shí)，是經(jīng)過序列化的有key-value關(guān)系的data node，如果直接通過業(yè)務(wù)邏輯對(duì)消息持久化的文件進(jìn)行操作，一方面是文件操作與業(yè)務(wù)操作耦合太過緊密，邏輯太過復(fù)雜，不易實(shí)現(xiàn)；另一方面，軟件的實(shí)現(xiàn)不可能一簇而就，如果采用這種方式，在軟件面臨修改的時(shí)候，很容易造成從頭再來的情況，軟件重用率太低；此外，這樣實(shí)現(xiàn)容易造成業(yè)務(wù)邏輯與文件操作無法分離，出現(xiàn)問題無法定位，軟件不夠健壯。

文件存儲(chǔ)層居于操作系統(tǒng)與消息中間件中間，對(duì)下調(diào)用操作系統(tǒng)文件接口實(shí)現(xiàn)文件操作，對(duì)上將機(jī)構(gòu)化的數(shù)據(jù)抽象并解析序列化為塊狀的datanode。文件存儲(chǔ)層的實(shí)現(xiàn)分為數(shù)據(jù)文件和索引文件，對(duì)于消息中間件的業(yè)務(wù)邏輯來說，需要持久化的數(shù)據(jù)項(xiàng)粗略分為索引和消息，索引數(shù)據(jù)用以區(qū)分消息中間件的容器，訂閱等，管理消息在服務(wù)器端存在的生命周期以及查找消息的位置。分別通過Index Manager和MsgData Manager管理。

2.2 性能

消息中間件基于文件的持久化方法的優(yōu)勢在于，由于是直接操作文件，所以能夠提供消息中間件較高的可用性的同時(shí)提供較高的性能，經(jīng)測試此種數(shù)據(jù)庫持久化方式在服務(wù)器端吞吐率能達(dá)到每秒8200條左右。（本文測試使用的軟硬件環(huán)境如下：硬件配置：Intel（R） Core（TM） 2 Duo CPU E8400 @ 3.00GHz，單核，內(nèi)存4GB。硬盤轉(zhuǎn)速7200轉(zhuǎn)。操作系統(tǒng)：Microsoft windows XP professor sp3。）

2.3 可能面臨的問題

直接操作文件可能面臨的問題主要包括兩個(gè)，一方面，消息中間件轉(zhuǎn)發(fā)的消息以及對(duì)應(yīng)的索引非定長數(shù)據(jù)，因此，在持續(xù)讀寫文件后，可能會(huì)造成文件碎片，文件不可繼續(xù)使用的情況；另一個(gè)問題為，直接操作文件，如果沒有設(shè)計(jì)文件鎖的保護(hù)，一旦在讀寫文件的時(shí)候發(fā)生斷電等意外情況，有可能導(dǎo)致消息文件發(fā)生了數(shù)據(jù)異?；蚱渲写鎯?chǔ)的數(shù)據(jù)出現(xiàn)不一致，甚至于文件失效打不開的情況，此時(shí)該消息文件將被作廢，該文件記錄的信息也不可恢復(fù)，持久化以提供消息中間件的初衷則得不到滿足。

可以通過一定策略一定程度的避免第一個(gè)問題：在服務(wù)器上同時(shí)持有幾個(gè)備用文件，寫滿一個(gè)后換新文件，如果該文件所記錄的所有消息都被取走，則棄用此文件并替換為新文件，這樣不存在文件碎片以及索引管理的問題，消息從前往后存儲(chǔ)，按照文件偏移量有序取出。對(duì)于第二個(gè)問題，較簡單的方法是在應(yīng)用中增加文件鎖，一次消息存取的操作沒有完全執(zhí)行完，不更新到磁盤等存儲(chǔ)設(shè)備。可以解決部分問題，但并不能解決將來數(shù)據(jù)不一致的情況（消息已被取走但未更新索引，導(dǎo)致無意義的重發(fā)，消息仍然丟失）。

3 基于文件數(shù)據(jù)庫的持久化方法

3.1 存儲(chǔ)模型

與基于文件持久化方法相同，基于數(shù)據(jù)庫的持久化操作也是層級(jí)模型，同樣由持久化訪問接口與數(shù)據(jù)庫訪問層組成，可以利用良好的設(shè)計(jì)將持久化訪問接口抽象成一組接口，將來可以作為規(guī)范，用于將消息中間件業(yè)務(wù)處理邏輯與持久化邏輯分離，同時(shí)提供多個(gè)版本的持久化方法支持不同的應(yīng)用場景，理想情況下甚至可以由用戶的選擇進(jìn)行切換。以下是作者提出的一組接口：

AddPersistMsg（Message msg）；

QueryPersistMsg（MsgID id）；

updatePersistMsg（MsgId id，BodyValue value）；

DeletePersistMsg（MsgId id）；

數(shù)據(jù)庫訪問層則是將文件數(shù)據(jù)庫API封裝，將結(jié)構(gòu)化的索引和消息存儲(chǔ)到對(duì)應(yīng)數(shù)據(jù)庫表格中，封裝為Save，Update，Query，Delete等操作，避免程序直接通過SQL語句對(duì)數(shù)據(jù)庫進(jìn)行訪問，仍是為了程序的健壯和可維護(hù)性?；谖募?shù)據(jù)庫的持久化方法關(guān)鍵在于數(shù)據(jù)庫設(shè)計(jì)，即如何組織索引與消息的表結(jié)構(gòu)，能夠支持盡量高的訪問性能，這里采用將存儲(chǔ)索引的表作為主表，存儲(chǔ)消息的表作為子表，通過唯一消息標(biāo)識(shí)作為關(guān)聯(lián)主鍵的模式，具體方式如圖3。

圖3 基于數(shù)據(jù)庫的存儲(chǔ)模型

3.2 性能

業(yè)界有很多性能非常優(yōu)秀的文件數(shù)據(jù)庫，這些數(shù)據(jù)庫實(shí)現(xiàn)的方式不盡相同，性能也千差萬別，但在消息持久化的場景下，我們最需要的是數(shù)據(jù)庫能否提供事務(wù)保護(hù)（能夠保持?jǐn)?shù)據(jù)一致性），同時(shí)性能較好，滿足條件的有Berkeley DB（需要復(fù)雜配置）、Sqlite DB、Berkeley DB（已不更新），這里采用的文件數(shù)據(jù)庫為Sqlite3，Sqlite3在的機(jī)器上能夠達(dá)到每秒數(shù)萬次到十萬次的訪存效率，并且Sqlte3支持事務(wù)保護(hù)，內(nèi)部分為5級(jí)文件鎖，可以保證不會(huì)出現(xiàn)寫數(shù)據(jù)庫出現(xiàn)數(shù)據(jù)失效的情況。

3.3 可能面臨的問題

Sqlite3的性能與使用模式相關(guān)，在開啟同一個(gè)事務(wù)的情況下性能最高，可達(dá)每秒十萬條，如果在要求絕對(duì)實(shí)時(shí)的使用模式下，相當(dāng)于每條數(shù)據(jù)庫操作當(dāng)作一個(gè)事務(wù)，每秒只能操作到160條消息存儲(chǔ)，究其原因在于sqlite3提供的5級(jí)文件鎖導(dǎo)致每次事務(wù)提交要進(jìn)行4次IO操作，因此數(shù)據(jù)庫性能被每秒能操作的事務(wù)限制，機(jī)器性能越高（主要依賴于硬盤轉(zhuǎn)速），能操作的事務(wù)越多，但不會(huì)有太大提高，數(shù)據(jù)的可靠性需要犧牲時(shí)間保證。如果不是要求絕對(duì)實(shí)時(shí)的情況下，可以通過一定機(jī)制解決這個(gè)問題，作者采用時(shí)間+消息條數(shù)雙重判定的方式來開啟，提交事務(wù)，服務(wù)器每收到n條消息或者m秒內(nèi)未收到n條消息，就將緩存中的這些消息和索引持久化到數(shù)據(jù)庫，如果沒達(dá)到提交條件，就將收到的消息存儲(chǔ)到臨時(shí)文件上，能最高程度的滿足實(shí)時(shí)性和性能的要求。如果要求絕對(duì)實(shí)時(shí)的情況，以上的設(shè)計(jì)仍不能滿足要求（臨時(shí)文件的消息可能丟失），鑒于Sqlite3性能低下的原因是逐條提交事務(wù)，而Sqlite3為開源軟件，研究其源代碼發(fā)現(xiàn)，在開啟事務(wù)的情況下，Sqlite3性能較高，但是在此次事務(wù)提交之前如果斷電，此次事務(wù)會(huì)自動(dòng)回滾，因此，對(duì)事務(wù)處理進(jìn)行優(yōu)化，去除不必要的文件同步及互斥操作，則可支持完全實(shí)時(shí)并且可以達(dá)到接近每秒萬條的性能，缺點(diǎn)為可能仍有極低的概率出現(xiàn)文件不可讀的異常情況。

4 基于分布式系統(tǒng)的消息持久化方法

消息中間件的持久化主要目的是為了保證消息在服務(wù)器上轉(zhuǎn)發(fā)時(shí)的可靠性，盡量不要丟失消息，即使因?yàn)槟撤N原因停機(jī)也能通過持久化的消息及索引信息將停機(jī)前一瞬間的場景恢復(fù)，在此基礎(chǔ)上能夠保證盡量高的吞吐率。從這個(gè)角度來看，上面提出的持久化方法，在性能和可靠性上均有瑕疵。性能的瓶頸主要在于單機(jī)的存儲(chǔ)設(shè)備性能有限制（如硬盤轉(zhuǎn)速有上限），單機(jī)的存儲(chǔ)設(shè)備無法滿足不斷增長的數(shù)據(jù)需求，考慮到高并發(fā)的訪問場景下，單機(jī)的消息中間件服務(wù)器由于操作系統(tǒng)限制，能夠同時(shí)響應(yīng)的訪問請(qǐng)求也受到限制，這里作者提出一個(gè)新的解決方案，通過多個(gè)服務(wù)器的集群來提高消息中間件服務(wù)器的并發(fā)響應(yīng)能力，依靠多服務(wù)器的冗余備份保證消息的可靠存儲(chǔ)轉(zhuǎn)發(fā)。

主要目標(biāo)：（1）高可用性，保證數(shù)據(jù)在服務(wù)器集群上的存儲(chǔ)不丟失。（2）并發(fā)支持，體現(xiàn)在三個(gè)方面，每臺(tái)管理節(jié)點(diǎn)都支持多個(gè)消息服務(wù)用戶做數(shù)據(jù)操作；支持同一消息服務(wù)用戶在不同管理節(jié)點(diǎn)登錄訪問數(shù)據(jù)，且異地訪問數(shù)據(jù)對(duì)消息服務(wù)用戶透明；在兩個(gè)消息服務(wù)用戶訪問同一組數(shù)據(jù)時(shí)能夠保護(hù)數(shù)據(jù)節(jié)點(diǎn)數(shù)據(jù)不被兩個(gè)消息服務(wù)用戶同時(shí)操作（類似數(shù)據(jù)庫鎖）。（3）監(jiān)聽數(shù)據(jù)節(jié)點(diǎn)，如果有節(jié)點(diǎn)因異常狀態(tài)無響應(yīng)，其他節(jié)點(diǎn)可以恢復(fù)該節(jié)點(diǎn)存儲(chǔ)的數(shù)據(jù)，并且對(duì)消息服務(wù)用戶透明。（4）可拓展性，各個(gè)節(jié)點(diǎn)對(duì)新加入集群的節(jié)點(diǎn)是自適應(yīng)的，無需經(jīng)過復(fù)雜的配置或者重啟，即可使用，這是考慮到消息中間件作為長期運(yùn)行的基礎(chǔ)服務(wù)，不應(yīng)頻繁通過重啟拓展服務(wù)器集群。（5）數(shù)據(jù)一致性，發(fā)現(xiàn)數(shù)據(jù)異常時(shí)能夠通過校驗(yàn)邏輯恢復(fù)正確的數(shù)據(jù)，當(dāng)與可用性沖突時(shí)，優(yōu)先考慮可用性。

4.1 存儲(chǔ)模型

圖4 基于分布式系統(tǒng)的存儲(chǔ)模型

Client（消息服務(wù)用戶）訪問管理節(jié)點(diǎn)，查詢索引表獲知需要訪問的數(shù)據(jù)位于哪個(gè)數(shù)據(jù)節(jié)點(diǎn)機(jī)器上，到數(shù)據(jù)節(jié)點(diǎn)機(jī)器上獲取消息。Index Node（管理節(jié)點(diǎn)）與Data Node（數(shù)據(jù)節(jié)點(diǎn)）都可以存儲(chǔ)在內(nèi)存中，因?yàn)槎鄼C(jī)冗余，每份數(shù)據(jù)均有備份，消息存儲(chǔ)在內(nèi)存中關(guān)機(jī)也并不會(huì)丟失，并且消息持久化的效率可以接近內(nèi)存操作。

圖5 數(shù)據(jù)在節(jié)點(diǎn)上存在形式

圖6 數(shù)據(jù)訪問模式

冗余管理節(jié)點(diǎn)多份備份，管理多個(gè)數(shù)據(jù)節(jié)點(diǎn)，管理節(jié)點(diǎn)存儲(chǔ)索引表，數(shù)據(jù)節(jié)點(diǎn)存儲(chǔ)數(shù)據(jù)塊，服務(wù)器集群一共處理的容器按照現(xiàn)有的數(shù)據(jù)節(jié)點(diǎn)個(gè)數(shù)，通過哈希計(jì)算的方式，確定存儲(chǔ)在哪個(gè)數(shù)據(jù)節(jié)點(diǎn)上，數(shù)據(jù)節(jié)點(diǎn)直接也有冗余備份，數(shù)據(jù)在節(jié)點(diǎn)間的冗余備份由以下方式實(shí)現(xiàn)：其中管理節(jié)點(diǎn)之間，定時(shí)通信將索引表備份，保持管理節(jié)點(diǎn)之間索引一致；管理節(jié)點(diǎn)上持續(xù)運(yùn)行管理線程，專門管理數(shù)據(jù)的冗余備份，即在一個(gè)數(shù)據(jù)節(jié)點(diǎn)上增加一條數(shù)據(jù)，一定會(huì)在另外兩個(gè)數(shù)據(jù)節(jié)點(diǎn)上同時(shí)添加兩份備份，在管理節(jié)點(diǎn)上記錄三份數(shù)據(jù)時(shí)始終指定一份為主數(shù)據(jù)；消息服務(wù)用戶訪問時(shí)取主數(shù)據(jù)進(jìn)行操作，通過數(shù)據(jù)備份線程定時(shí)備份保證備份數(shù)據(jù)與主數(shù)據(jù)之間的一致性，依次保證備份數(shù)據(jù)操作不會(huì)降低服務(wù)器吞吐率；每個(gè)數(shù)據(jù)節(jié)點(diǎn)按時(shí)向數(shù)據(jù)節(jié)點(diǎn)發(fā)送?；蠲?，表明該節(jié)點(diǎn)仍然處于工作狀態(tài)，一旦某個(gè)數(shù)據(jù)節(jié)點(diǎn)發(fā)生異常，管理節(jié)點(diǎn)可即時(shí)獲知，調(diào)用管理線程將該節(jié)點(diǎn)上存儲(chǔ)的數(shù)據(jù)備份到其他機(jī)器上，始終保持?jǐn)?shù)據(jù)節(jié)點(diǎn)上存在三份數(shù)據(jù)備份。

當(dāng)有消息服務(wù)用戶登錄服務(wù)器端請(qǐng)求數(shù)據(jù)處理時(shí)，管理節(jié)點(diǎn)記錄該節(jié)點(diǎn)用戶名，以及想要訪問的數(shù)據(jù)塊，當(dāng)同名用戶想要訪問相同數(shù)據(jù)塊時(shí)，每次數(shù)據(jù)請(qǐng)求在管理節(jié)點(diǎn)之間加互斥鎖進(jìn)行限制訪問，如果訪問不同數(shù)據(jù)塊則無此限制。

管理節(jié)點(diǎn)維持一個(gè)管理節(jié)點(diǎn)索引和一個(gè)數(shù)據(jù)節(jié)點(diǎn)索引，分別記錄當(dāng)前活動(dòng)管理節(jié)點(diǎn)和當(dāng)前活動(dòng)數(shù)據(jù)節(jié)點(diǎn)和數(shù)據(jù)塊對(duì)應(yīng)關(guān)系，當(dāng)有新節(jié)點(diǎn)加入，新節(jié)點(diǎn)向當(dāng)前局域網(wǎng)廣播?；蠲?，管理節(jié)點(diǎn)受到此命令后會(huì)將該節(jié)點(diǎn)加入對(duì)應(yīng)索引表，備份線程按照索引表將該節(jié)點(diǎn)應(yīng)該備份的數(shù)據(jù)進(jìn)行備份操作。當(dāng)管理節(jié)點(diǎn)失效，其他管理節(jié)點(diǎn)偵知后，將該管理節(jié)點(diǎn)從索引表中刪除，如果數(shù)據(jù)節(jié)點(diǎn)失效，則通過查詢數(shù)據(jù)節(jié)點(diǎn)索引表將該節(jié)點(diǎn)的數(shù)據(jù)備份到另外的節(jié)點(diǎn)上，之后將該節(jié)點(diǎn)從數(shù)據(jù)節(jié)點(diǎn)索引中刪除。

4.2 性能分析

上述描述的基于分布式系統(tǒng)的消息持久化方法性能與用戶使用模式相關(guān)，理想情況下，如果多個(gè)管理節(jié)點(diǎn)均接入消息服務(wù)用戶進(jìn)行數(shù)據(jù)存取操作，且多個(gè)消息服務(wù)用戶操作數(shù)據(jù)不沖突的情況下，該持久化方式能達(dá)到N倍于非持久消息（僅通過內(nèi)存轉(zhuǎn)發(fā)）的吞吐率（N為服務(wù)節(jié)點(diǎn)個(gè)數(shù)），最差情況下也能與單機(jī)非持久消息吞吐率相當(dāng)，約為每秒2W條。

4.3 存在的問題

至少需要3+3臺(tái)計(jì)算機(jī)組成服務(wù)器集群，規(guī)模較大，不適合作為輕量級(jí)解決方案，另外，為了保持?jǐn)?shù)據(jù)一致性，數(shù)據(jù)備份線程與存取操作對(duì)同一個(gè)數(shù)據(jù)塊進(jìn)行操作時(shí)會(huì)需要同步，因此導(dǎo)致服務(wù)器處理數(shù)據(jù)的吞吐量與數(shù)據(jù)訪問的實(shí)時(shí)性沖突，即在高并發(fā)訪問的情況下，數(shù)據(jù)訪問響應(yīng)時(shí)間會(huì)比較長，如果為了保證數(shù)據(jù)能夠?qū)崟r(shí)響應(yīng)，服務(wù)處理數(shù)據(jù)的吞吐量會(huì)下降。

5 結(jié)束語

本文首先介紹了消息中間件、消息中間件體系結(jié)構(gòu)以及消息中間件持久化對(duì)于消息中間件的意義后，詳細(xì)介紹了三種消息中間件的持久化方案，以應(yīng)多各種應(yīng)用場景、用戶使用模式的需求。本文提供的持久化方案參照了消息中間件的使用場景、使用模式，以及業(yè)界幾種與持久化相關(guān)的比較流行的開源軟件的設(shè)計(jì)思路，如文件數(shù)據(jù)庫參照和使用了sqlite3，分布式文件系統(tǒng)參照了memcached、Hadoop分布式文件系統(tǒng)。以上介紹的消息中間件的持久化方法，都是適用于各自特定的場景的，每一種持久化方法都各有利弊，在實(shí)際應(yīng)用中應(yīng)考慮實(shí)際情況，選擇合適的方式。

參考文獻(xiàn)：

[1]Bernstein P.Middleware：A Model for Distributed System Services.Communications of the ACM，1996（02）：86-98

[2]Korhonen M.Message Oriented Middleware.Helsinki University of Technology，http：//www.tml.hut.fi/Opinnot/Tik-110.551/1997/mqs.htm，1997（08）.

[3]Lingel K.Security Requirements for Message-oriented Middleware.http：//www.eaijournal.com/PDF/MomSecure.pdf，2001（06）.

[4]徐晶，許煒.消息中間件綜述[J].計(jì)算機(jī)工程，2005（08）：16-31.

[5]周園春，李淼，張建，李曉歐，張飛.中間件技術(shù)概述[J].計(jì)算機(jī)工程與應(yīng)用，2002（08）.

[6]劉伯睿.海量數(shù)據(jù)小文件分布式存儲(chǔ)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].湖南大學(xué)，2013.

[7]王偉娜.分布式存儲(chǔ)系統(tǒng)中容錯(cuò)子系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].東北大學(xué)，2008.

[8]舒敏.分布式數(shù)據(jù)存儲(chǔ)機(jī)制與優(yōu)化方法研究[D].西安電子科技大學(xué)，2013.

[9]何潤潤.網(wǎng)絡(luò)環(huán)境下的分布式存儲(chǔ)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].華中科技大學(xué)，2011.

作者簡介：宿凱翔（1989-），男，山西人，在讀研究生，助理工程師，碩士，研究方向：中間件。

作者單位：華北計(jì)算技術(shù)研究所，北京 100083