面向內存云的協調器選舉策略

王躍飛　于炯　魯亮

摘要：

針對ZooKeeper機制難以滿足內存云（RAMCloud）低延遲、快恢復的問題，提出了一種面向內存云的協調器選舉策略（CES）。首先根據內存云網絡環境與協調器自身因素將協調器性能指標分為個體指標與協調器間指標兩類并分別建立模型；然后將內存云的運行分為正常運行期與數據恢復期兩階段并分別建立適應度函數，再按時間比合并為總適應度函數；最后在備選協調器（RBC）的適應度值的基礎上提出一個具備穩定擇優性與隨機性的新算子，CES首先通過篩選來排除性能較差的個體，縮小選擇范圍后再在理想協調器的集合中采用輪盤賭方法選擇最終的個體。實驗結果表明，在NS2仿真環境下CES選擇的個體相比其他備選協調器數據處理延遲降低了19.35%；在搭建的內存云環境中，與ZooKeeper機制相比，CES的選擇結果在快速恢復中時間減少了10.02%。在內存云的實際應用中，CES在處理單點失效問題上能有效選擇性能更優的協調器，確保了低延遲、快恢復的要求。

關鍵詞：

內存云；協調器；單點失效；適應度函數；選舉策略

中圖分類號：

TP393.02

文獻標志碼：A

Abstract：

Focusing on the issue that ZooKeeper cannot meet the requirement of low latency and quick recovery of RAMCloud， a Coordinator Election Strategy （CES） based on RAMCloud was proposed. First of all， according to the network environment of RAMCloud and factors of the coordinator itself， the performance indexes of coordinator were divided into two categories including individual indexes and coordinator indexes， and models for them were built separately. Next， the operation of RAMCloud was divided into errorfree running period and data recovery period， their fitness functions were built separately， and then the two fitness functions were merged into a total fitness function according to time ratio. Lastly， on the basis of fitness value of RAMCloud Backup Coordinator （RBC）， a new operator was proposed with randomness and the capacity of selecting an ideal target： CES would firstly eliminate poorperforming RBC by screening， as the range of choice was narrowed， CES would select the ultimate RBC from the collection of ideal coordinators by means of roulette. The experimental results showed that compared with other RBCs in the NS2 simulation environment， the coordinator selected by CES decreased latency by 19.35%； compared with ZooKeeper in the RAMCloud environment， the coordinator selected by CES reduced recovery time by 10.02%. In practical application of RAMCloud， the proposed CES can choose the coordinator with better performance， ensure the demand of low latency and quick recovery.

英文關鍵詞Key words：

RAMCloud； coordinator； singlepoint failure； fitness function； election strategy

0引言

隨著電子商務與社交網絡的快速發展，越來越多的企業與組織常常面臨百萬級的用戶并發訪問與每秒數以千計的并發事務處理[1]。2011年7月，《中國計算機學會通訊》針對數據密集型計算（DataIntensive Computing， DIC）展開了專題研究[2]，并將極限事務處理（Extreme Transaction Processing， XTP）作為解決密集型應用的關鍵。斯坦福大學于2009年提出內存云理念，使相關問題得到良好的緩解[3]：內存云（RAMCloud）是一組以內存為存儲媒介，所有數據均存儲在動態隨機訪問存儲器（Dynamic Random Access Memory， DRAM）內，硬盤僅作為數據備份。由于文件數據始終存儲在內存，系統的吞吐量與時延得到了高效的優化。近年來有關內存云的研究領域逐漸得到擴展與深化：研究人員不僅對數據的管理與恢復作出了系統的改善[4-5]，同樣針對數據的并發容錯，存儲查詢提出了新的模型與框架[6-8]。目前國內也開展了相關研究，對包括磁盤節能[9]、小文件合并[10]等問題作出了優化與完善。

由于內存云協調器（coordinator）在斷電等自然災害情況下會不可避免地面臨由單點失效造成的系統癱瘓問題，針對關鍵節點再選舉，Hadoop的擴展項目ZooKeeper開源實現了Google的chubby服務，通過paxos的變種算法解決了候選節點的選舉問題[11]。然而Zab（ZooKeeper atomic broadcast）協議難以支撐內存云高效的讀取速率，Junqueira等[12]對Zab協議的延遲進行了分析，實驗證明在單獨的一個操作中，服務器間的平均延遲在100ms以上，遠高于內存云的微秒級別[13]。另外，Zab協議更適用于競選id確定的情況下執行[14]，內存云網絡情況復雜，備選協調器（RAMCloud Backup Coordinator， RBC）數目較多，備選集合隨情況不同數目也會有所變化。

文獻[15]對內存云使用Zab協議進行了研究，結果表明：1）單點失效后內存云僅采用隨機的方法在備選協調器集群內選擇協調器；2）在配置文件較小的情況下單點恢復速度低于服務器恢復速度。以上問題表明傳統選舉機制并不適用于內存云環境，突破延遲問題并依據網絡狀況才是選擇備選協調器的重要方法。

本文主要針對備選協調器（RBC）的選擇問題進行研究，為解決該問題，提出了一種適于內存云日志文件系統的協調器選舉策略（Coordinator Election Strategy， CES）。首先，根據內存云網絡拓撲與協調器自身性能，將協調器指標分為個體指標與協調器間指標并分別建立模型，這些模型能夠對任意協調器進行客觀評價；然后，引入遺傳算法的適應度函數，為保證客觀，將內存云適應度函數分為正常運行與數據恢復兩階段，之后根據時間比合并；最后，為篩選最優協調器，本文提出一個穩定的新算子，該算子能在備選集里不失隨機性地選擇狀況良好的協調器作為最終選擇。

1內存云架構

1.1內存云結構

在內存云集群中，每臺服務器既是由內存構造的主服務器（Master），用作數據文件的存儲；同時也是由硬盤組成的備份服務器（Backup），用來防止斷電等災害而備份內存中的數據，框架結構如圖1所示。另外，集群中含一個類似Hadoop中namenode節點[16]的協調器，在集群運行與數據恢復階段負責管理服務器，記錄鍵值對日志，完成對應功能。

1.2內存云協調器

協調器關系到服務中心的正常運行，雖然它不涉及數據的讀寫，但作為建立檢查點、分配和調用資源、存儲數據映射信息的核心服務器，協調器在各階段承擔著監察和統籌全局的重要角色。考慮到各時期的差異，將協調器功能分為兩階段，分別是服務器正常運行時期以及數據的快速恢復時期。

1）服務器正常運行時期[17]。協調器需控制主服務器、備份服務器在線；需周期性監測是否有任意服務器宕機；需管理數據映射服務器的信息表；當客戶端緩存丟失時，需與客戶端連接。絕大部分時間內，集群內的服務器均是正常工作的，但并不排除突發故障等問題，若發生斷電等災害問題時協調器則會啟動應急項。

2）數據快速恢復期[18]。主服務器在宕機前，數據以段（segment）的形式復制3份，并分別存儲在不同的備份服務器中，協調器存儲了關于當前服務器數據備份的物理位置的映射信息，作為并行恢復查找點。另外，當恢復后所有段拼接完畢，協調器需查看拼接日志的完整性。

2協調器模型

內存云網絡拓撲不遵循單一結構，而是呈混合多樣化，即便容納更多服務器也能保證集群的易拓展性，圖2是一個典型的內存云網絡拓撲簡化。

圖2中S表示交換機（Switch， S），每臺備選協調器C與多臺聚合交換機（Aggregation Switch， AS）交互，網絡內部關系復雜；當機架較多或有新的服務設備納入時，底層交換機下還可能建立新的交換網絡。根據內存云日志文件系統的運行方法與規律，可將內存云網絡抽象，為RBC設置若干參數并建立模型，并將這些參數作為選舉策略的重要依據。通過1.1節對協調器的功能分析以及內存云網絡拓撲，現將參數劃分為兩類：1）個體指標；2）協調器間指標。

2.1個體指標

定義1備選協調器個體指標。備選協調器個體指標是指在內存云網絡拓撲結構中，備選集內每臺協調器個體特性以及網絡結構特性，包括：RBC連通性、RBC中心性和剩余內存空間。

2.1.1RBC連通性

協調器的連通性是指：1）與主服務器、備份服務器的連通性；2）與客戶端的連通性。內存云中，協調器為探測集群中是否存在宕機服務器，以及為管理各類在線服務器，主服務器會周期性地向協調器發送心跳，協調器如果在一段時間內沒有收到心跳，就會將該服務器標記為宕機。另外，客戶端存儲了與主服務器直接連接的緩存數據，如若緩存丟失，客戶端將嘗試與協調器建立連接，并重新建立緩存。由于暫不模擬與客戶端的交互，連通性僅將與各服務器的連接關系納入考慮范圍。

針對與各服務器的連接關系，RBC連通性模型建立如下：

C（c）=λ·1n∑nk=1j·Ttk（1）

其中：C（c）表示協調器c的連通性（connectivity）；n為集群中服務器數量； j為主服務器向協調器發送心跳次數，次數較多統計越為準確；T為系統設置的心跳周期；tk是協調器記錄的服務器k在j次心跳循環中總接收時間；為協調連通值與其他因素的關系，插入在最后計算適應度值時連通性的權重λ，可依據情況改變大小。可以觀察到連通性反映了平均接收心跳時間，能夠以時間衡量影響主服務器與協調器通信路徑的因素。這是因為數據中心網絡拓撲中接入層、匯聚層的光纖帶寬是相同的，當協調器欲與某服務器通信，需經過若干交換機到達機架交換機（TopofRank switch， ToR），再將消息轉發至目標服務器中，如圖3。因此真正影響接收時間的實際是通信路徑中的交換機以及路徑長度等因素。

若系統采用雙向心跳機制時，即協調器在周期時間也向主服務器發送心跳，同樣可以采用式（1）來判斷各協調器連通性能，但需注意tk是受前若干次心跳時間影響的，需要控制心跳次數j統一才可判斷各協調器連通值大小。內存云數據中心能支持混合型網絡拓撲結構以實現應用廣泛、拓展靈活等特性，與協調器間存在較少交換機的服務器則具有很大的優勢，考慮到與協調器的通信距離、強度等問題，這類服務器在獲得、提交數據等方面將具有更高的優先級。

2.1.2RBC中心性

RBC中心性表示該協調器在網絡拓撲中的作用和影響力，用來評估周圍服務器節點與該協調器連接的緊密性。一般的，若某協調器連接交換機在網絡中所處位置占據了該網絡所有最短路徑中的絕大多數，則說明該協調器在網絡的核心位置，所發出的信息指令也能更迅速地傳遞到網絡中的各臺服務器內。

為評估任意備選協調器影響力，引入節點介數[19-20]概念。包括內存云的眾多網絡中，在關鍵路徑上能夠傳遞信息的節點的重要性并不亞于具備重要信息的節點。節點介數能夠客觀反映RBC中各個協調器在網絡拓撲的中心化程度，是網絡節點重要性的關鍵標志。協調器介數值表示如下：

B（c）=∑s≠t≠Sσst（Sc）σst（2）

RBC中心性的計算可依照介數的計算方法。式（2）中σst表示從s到t的所有最短路徑數目；分子部分σst（Sc）表示在所有的最短路徑中，協調器c所連接交換機S經過的數目。B（c）的值越大，表示協調器c處理的信息路徑越多，網絡位置也就越為核心；若協調器位于網絡邊緣且與服務器連接，則中心性為零。

2.1.3剩余內存空間

剩余內存空間指除了必須存儲的數據信息外協調器剩余空間大小。剩余空間有以下作用：1）與主服務器并行地交互數據。協調器雖不負責數據的讀寫，卻存在很高的數據吞吐量。假設集群中含1024臺主服務器，平均每臺主服務器更新并傳遞100MB數據備份信息，考慮集群中的主服務器在同一時刻發送更新數據，則協調器至少應含有100GB剩余空間以供并行交互。2）剩余空間有效地保障了用戶與協調器的通信。絕大部分的用戶在初期需要和協調器建立通信連接服務，以獲取主服務器地址等消息，應有足夠大內存空間保證與用戶動態鏈接。

協調器剩余內存空間的數學模型定義如下：

CFS=1γ{CRS-∑ni=1（maplist+iso）-∑ni=1cache-∑ni=1∑objectsbackupId}（3）

式（3）描述了協調器剩余空間（Coordinator Free Space， CFS）的計算方式，其中：γ用作在計算適應度函數時對CFS大小的調整，可通過訓練獲得。協調器總內存容量（Coordinator RAM Space， CRS）中包含以下存儲信息：

1）∑ni=1（maplist+iso）表示n臺主服務器存儲的數據映射表以及備份鏡像的總空間。主服務器數據塊（object）的鍵值對一般存儲在表單中，當用戶請求主服務器數據或該主服務器宕機后協調器均需按表單查找源數據；另外，協調器應同樣存儲類似數據的備份鏡像，以方便RBC的數據同步。

2）∑ni=1cache表示協調器與集群內所有主服務器通信信息的緩存空間總和協調器作為中樞節點必須存儲于各個主服務器的通信信息并建立緩存，方便用戶以及主服務器的接入。

3）∑ni=1∑objectsbackupId表示集群中每臺主服務器每個數據塊備份地址信息占用的空間總和。每臺主服務器包含任意多個數據塊，每個數據塊備份在任意3個備份服務器中。

剩余內存大小關系到集群運行狀況，是評價RBC的重要指標。一般備選RBC集合中剩余內存由于初始化、網絡位置不同等因素大小不一，因此內存較高的協調器更能夠保證數據交互的平穩與存儲的安全。

2.2協調器間指標

定義2備選協調器間指標。備選協調器個體指標是指在內存云網絡拓撲結構中，備選集內每臺協調器網絡結構特性，包括：1）RBC相互關聯性；2）其他因素。

2.2.1RBC相互關聯性

若某RBC被最終選為協調器，則該協調器將與RBC時刻保持大量的信息交互，這是因為協調器需在RBC集合中同步、備份數據鏡像，以防止當前協調器宕機后數據丟失。為表示RBC內部的通信長度，引入平均路徑長度作為參數用以評估當前協調器各RBC關聯程度的高低。

協調器與RBC間關聯程度表示如下：

R=1D=1/（∑Ci=1dijkstra（c，i））（4）

數據中心規模較大，消息存在多路徑選擇。式（4）中：dijkstra（c，i）表示從定點協調器到某一個RBC之間的單源最短路徑，C表示RBC集合內的備選協調器數量。該算法的累加部分為從源點到RBC集合中全部服務器的最短路徑距離之和，距離D越長，關聯程度越低。

平均路徑長度一般用來描述內存云數據包的通信有效性，通信路徑越短，有效性越強。依照內存云網絡部署可以簡單有效評估該協調器與RBC間的通信能力，判斷協調器間的緊密程度。

2.2.2其他因素

目前的一些復雜網絡分析提供了一些判斷節點性質的標準，這些標準作為網絡的分析方法為內存云協調器的網絡結構分析提出了參考依據：如Google采用的PageRank算法不僅能夠排列網頁，同樣的原理也能定位并計算網絡節點的重要程度；另外，安全因素同樣也應納入考慮范疇之內，局部網絡拓撲的脆弱性容易引發惡性網絡攻擊，安全網絡下的協調器則更被優先考慮。

3協調器選擇策略

3.1遺傳算法在RBC集合的應用

遺傳算法是解決最優化問題的良好途徑，通過選擇、交叉、變異處理基因與染色體，遺傳算法能夠遴選出較為滿意的個體傳遞到下一代種群里。

在內存云數據中心集群中，可以將RBC集合看作需要被遴選的初始化種群，為選出狀態最佳的協調器，可依據第2章討論的內容建立合適的適應度函數，該函數能夠客觀反映理想化的協調器在任意階段的必備條件，根據適應度函數對每臺RBC的計算，可以衡量并評價集合內每臺RBC與最優效果的接近程度。

3.2適應度評估函數

為解決不同的問題，遺傳算法對適應度函數有著不同的要求。針對大部分簡單的計算，算法始終執行唯一的適應度函數，處理問題雖然簡單明確，但容易引發計算初期的未成熟收斂問題以及后期的競爭區分度不高問題。內存云協調器工作內容按時間劃分可分為服務器運行期以及快速恢復期，兩個階段對協調器要求各不相同，為客觀分析RBC集合內各協調器指標，兩階段可分別創建不同的適應度函數。

3.2.1運行期適應度函數

通過第2章對RBC模型的建立與性質的探討，并結合正常運行的協調器工作內容，分析并建立運行期適應度函數如下：

frun=（C+B+CFS）·R（5）

其中：C、B、CFS、R分別表示協調器的連通性、中心性、協調器剩余空間以及RBC間通信狀況。參考第2章運行期協調器任務，對評價標準討論如下：首先，協調器需要及時與主服務器、備份服務器甚至丟失緩存的客戶端發送消息，頻繁的通信不僅能夠及時探測失效節點，而且可以在第一時間獲取各主服務器數據更新信息的狀況并及時記錄，因此需將協調器的連通性C和中心性B考慮在內；其次，內存云工作期間協調器會不定期接受各個主服務器發送的數據，數據并行傳送時對協調器內存大小有較高的要求，因此適應度函數納入CFS因素；最后，RBC相關性R在運行與恢復期都起到至關重要的作用，不僅能在運行時周期地將數據鏡像復制傳遞到RBC集合中，而且恢復期間允許從其他RBC中獲取需要的數據，因此R值是參照的重要因素。

3.2.2快速恢復期適應度函數

快速恢復期與運行期大致相同，不同的是對協調器網絡性能要求比正常運行時高很多。參照快速恢復機制，任意服務器宕機后需要盡快恢復完畢，而恢復的關鍵便是協調器能否將要求的數據信息快速及時地發送給主服務器并接受響應。這不僅考量了協調器與服務器是否連通，同時檢測了協調器是否處于網絡核心以及其通信影響力。

另外，為防止大量服務器同時癱瘓，協調器間的關聯R也存在要求，這是因為內存云在面對大量服務器癱瘓情況時可采用多協調器共同恢復機制。通過對快速恢復期協調器任務分析，可建立適應度函數如下：

frecovery=C·B·R（6）

協調器對網絡的要求很高，在適應度函數中表示為C·B，代表了某節點連通性與中心性的乘積，這是由內存云即時性要求決定的。倘若某節點具有網絡連通優勢且與周圍服務器連接緊密，則被選為協調器的概率也就大大提升。

3.2.3協調器適應度函數

綜合兩階段不同要求所提出的不同適應度函數，得到如下總適應度函數：

F=αfrun+βfrecovery（7）

其中α， β為兩階段適應度函數系數，α∶ β表示在內存云集群中所有服務器正常運行與任意服務器宕機次數之比。兩階段適應度函數之和能夠客觀評價某RBC在不同時期的綜合情況，適應度越高的RBC越接近理想狀態。

3.3協調器選擇策略

選擇算子以RBC集合內每臺服務器的適應度評估值為基礎，按一定規律選擇一臺理想的協調器。內存云網絡結構中RBC可夠部署在核心層任意位置，若依照比例選擇采用輪盤賭的方式存在很高的不穩定性；若僅取計算后值最高的RBC則喪失了隨機性，同樣理想的RBC可能因為特殊問題不能入選。

目前關于算子理論的發展已經非常成熟，針對以上的特殊情況，結合擇優與隨機特性提出一種適于內存云環境下選擇RBC的算子方法。該方法能夠遴選出理想RBC作為新的集合，將輪盤賭的隨機選擇縮小在質量很高的RBC集合中。

算法說明：設在RBC集合內含N臺備選協調器，通過期望生存值（Expected Value， EV）與輪盤策略選擇最終的協調器C。

4實驗與分析

4.1實驗設計與環境

4.1.1實驗設計

實驗首先通過協調器模型與選擇策略模擬推舉出最終協調器，再根據不同協調器下消息傳遞時延、數據恢復時間選擇RBC內實際最優者，通過比對CES與實驗結果的一致性判斷選擇策略的優劣。

實驗首先在NSG2包內創建45個節點，其中包括C0至C4共5個協調器模擬節點，為模仿內存云網絡，將環形、星形、總線三類構成混合狀拓撲結構，仿真拓撲簡化如圖4所示。

配置節點與鏈路參數并生成tcl腳本文件，將文件運行在Fedora系統環境下的NS2.35版本平臺上，編寫協調器屬性值算法；其中連通性的精簡偽碼如下：

最后執行仿真實驗，仿真時間60s，并對生成的trace文件進行分析。根據第3章所討論的協調器選擇策略，對實驗中RBC內5臺協調器計算適應度函數frun與frecovery（忽略剩余內存空間大小），按9∶1控制正常運行與恢復頻率，計算得到總適應度函數F后，按選擇策略算法1執行。根據適應度大小和對穩定性的控制，可對期望生存值的扣除因子作適當調整。

協調器需要時刻獲取主服務器傳遞的數據，并向RBC傳遞備份數據。同樣大小的數據在網絡中傳輸，依靠網絡的結構差異與路由機制的不同，延遲高低實際上是存在區別的。圖5中5個協調器的數據傳輸延遲基本上隨著數據量的增加而升高，可以觀察到，C3于RBC中基本處于最小延遲狀態。實際上NS2在模擬中存在一些非客觀因素，數據延遲的大小更依賴節點傳輸的路徑長度，在這種情況下，C3延遲依然較低，這是由于其處于網絡拓撲中心環狀處，且與節點密集區距離較近，因此延遲低于其他RBC。相應的如C1或C4在傳輸相同數據情況下延遲較大，這是由于傳輸經過節點多。若在內存云真實環境下，可能會在接收、傳遞、轉發消息過程中出現請求高、任務排隊等情況。

4.2.2數據恢復時間分析

數據恢復時間是衡量當前協調器性能的重要參數，然而在仿真環境下，NS2難以測試內存云的恢復時間。本節實驗通過搭建內存云模擬環境，建立15個節點，其中包括10臺服務器，以及構成RBC的5臺協調器；每臺主服務器內存16GB，硬盤100GB，內存云版本為1.0。

當前數據中心處理單點故障問題的主流方法為ZooKeeper和chubby。為檢驗CES效果，選擇ZooKeeper作為實驗對照。ZooKeeper是開源Hadoop中的一個子項目，能夠下載并安裝使用[21]。內存云數據備份在備份服務器中，當某臺服務器宕機后，備份服務器需要將存儲的數據表單提交至協調器，并將恢復數據傳遞至新的替代服務器內，實驗通過執行CES，選擇出最佳協調器C1，通過恢復時間比對執行ZooKeeper后的最佳協調器C2。

圖6展示了CES與ZooKeeper選擇結果對數據恢復時間的影響。C1與C2在恢復過程中影響差異基本維持在200～300ms，在最初恢復數據小的情況下，不同協調器對恢復時間影響可以忽略不計；當恢復數據增加時，差異變得明顯且穩定。雖然單個主服務器容量不大，但從圖6的趨勢能夠判斷，若需恢復100GB的情況下，不同協調器對恢復時間還是有影響的。

造成差異的原因是由于CES選擇的協調器能夠更快獲取備份服務器主鍵，或者能夠更快查詢到需要數據的物理位置等信息。ZooKeeper在內存云的處理情況是將失效節點配置信息隨機傳遞給相鄰協調器，并未將該協調器個體指標與周圍網絡納入考慮范圍，因此最終選擇結果不及CES客觀。

5結語

目前的一些大型數據中心如Yahoo！等在面對單點失效問題時均采用ZooKeeper機制[22]，相似的數據中心之間，類似方法策略也具有一定的移植性。由于內存云的存儲介質與大部分數據中心具有本質差異，相關方法難以結合吞吐大、時延小等特性，因此考慮結合內存云特殊架構下的單點恢復策略也就顯得更加緊迫。

通過面向協調器建模并分析模型，建立雙時期適應度函數并合并，計算函數并求解算子等一系列的執行過程，不僅能夠在RBC集合中選舉出優秀理想的協調器作為內存云網絡中任務調度資源分配的承擔者，同樣能對選舉參與者狀態作出有效評估，對各服務器網絡最佳位置提供有效參考。當然，選舉策略同樣存在一定的缺陷，表現如下：1）將來的完善中，可以把網絡安全、綠色計算等因素納入建模研究范疇。協調器作為服務中心首先不應存在被黑客攻擊的安全隱患，另外在研究消息傳遞路徑時也應考慮能耗因素。1）選舉策略下的框架結構并未將網絡安全、綠色計算等因素納入建模研究范疇。協調器作為服務中心首先不應存在被黑客攻擊的安全隱患，另外在研究消息傳遞路徑時也應考慮能耗因素。2）若在最初部署時協調器網絡位置分布過于密集，差異較低，則CES效果并不顯著，更適宜直接采用隨機輪盤的形式。

下一步將針對優化內存云快速恢復網絡拓撲進行探索與改進，結合圖論、網絡群體演化等相關技術，對內存云主服務器數據段的備份位置展開分析。在恢復中，數據的備份位置會影響到恢復時間、效率等關鍵指標，因此擬劃分適當的域并在域中建立環狀網絡結構，使恢復性能獲得新的優化。至于域內服務器的建模與部署，則是下一步重點考慮的問題。

參考文獻：

[1]

秦秀磊，張文博，魏峻，等.云計算環境下分布式緩存技術的現狀與挑戰[J].軟件學報，2013，24（1）：50-66.（QIN X L， ZHANG W B， WEI J， et al. Progress and challenges of distributed caching techniques in cloud computing[J]. Journal of Software， 2013， 24（1）： 50-66.）

[2]

肖儂.數據密集型計算[C]// 中國計算機學會通訊，北京：中國計算機學會，2011，7（7）：6-7.（XIAO N. Dataintensive computing[C]// CCF 2011： Communications of the CCF， Beijing： CCF， 2011，7（7）：6-7.）

肖儂.數據密集型計算[J].中國計算機學會通訊，2011，7（7）：6-7.（XIAO N. Dataintensive computing[J]. Communications of the CCF， 2011，7（7）：6-7.）

[3]

OUSTERHOUT J， AGRAWAL P， ERICKSON D， et al. The case for RAMClouds： scalable highperformance storage entirely in DRAM [J]. ACM SIGOPS Operating Systems Review， 2010， 43（4）： 92-105.

[4]

RUMBLE S M， KEJRIWAL A， OUSTERHOUT J. Logstructured memory for DRAMbased storage [C] // Proceedings of the 12th USENIX Conference on File and Storage Technologies. Berkeley， CA： USENIX Association， 2014： 1-16.

[5]

OUSTERHOUT J， GOPALAN A， GUPTA A， et al. The RAMCloud storage system [J]. ACM Transactions on Computer Systems， 2015， 33（3）： Articl No. 7.1-55

[6]

STUTSMAN R， LEE C， OUSTERHOUT J. Experience with rulesbased programming for distributed， concurrent， faulttolerant code [C]// Proceedings of the 2015 USENIX Conference on Usenix Annual Technical Conference. Berkeley， CA： USENIX Association， 2015： 17-30.

[7]

TINNEFELD C， KOSSMANN D， GRUND M， et al. Elastic online analytical processing on RAMCloud [C]// Proceedings of the 16th International Conference on Extending Database Technology. New York： ACM， 2013： 454-464.

[8]

TINNEFELD C， KOSSMANN D， BOESE J H， et al. Parallel join executions in RAMCloud [C]// Proceedings of the 2014 IEEE 30th International Conference on Data Engineering Workshops. Washington， DC： IEEE Computer Society， 2014： 182-190.

[9]

魯亮，于炯，英昌甜，等.內存云架構的磁盤節能策略[J].計算機應用，2014，34（9）：2518-2522.（LU L，YU J，YING C T， et al. Energyefficient strategy for disks in RAMCloud[J]. Journal of Computer Applications， 2014， 34（9）： 2518-2522.）

[10]

英昌甜，于炯，魯亮，等.基于小文件的內存云存儲優化策略[J].計算機應用，2014，34（11）：3104-3108.（YING C T， YU J， LU L， et al. An optimization storing strategy based on small files in RAMCloud [J]. Journal of Computer Applications， 2014， 34（11）： 3104-3108.）

[11]

RIVETTI N， CORSARO A. State based Paxos[C]// Middleware Industry 13： Proceedings of the Industrial Track of the 13th ACM/IFIP/USENIX International Middleware Conference. New York： ACM， 2013： Article No. 4.

[12]

JUNQUEIRA F P， REED B C， SERAFINI M. Zab： highperformance broadcast for primarybackup systems [C]// DSN 11： Proceedings of the 2011 IEEE/IFIP 41st International Conference on Dependable Systems & Networks. Washington， DC： IEEE Computer Society， 2011： 245-256.

[13]

RUMBLE S M， ONGARO D， STUTSMAN R， et al. Its time for low latency [C]// Proceedings of the 13th USENIX Conference on Hot Topics in Operating Systems. Berkeley， CA： USENIX Association， 2011： 11-16.

[14]

HUNT P， KONAR M， JUNQUEIRA F P， et al. ZooKeeper： waitfree coordination for Internetscale systems [C]// Proceedings of the 2010 USENIX Conference on USENIX Annual Technical Conference. Berkeley， CA： USENIX Association， 2010：11.

[15]

ONGARO D， RUMBLE S M， STUTSMAN R， et al. Fast crash recovery in RAMCloud [C]// SOSP 11： Proceedings of the 23rd ACM Symposium on Operating Systems Principles. New York： ACM， 2011： 29-41.

[16]

BORTHAKUR D. The hadoop distributed file system： architecture and design[EB/OL]. （20070701） [20151005]. http：//hadoop.apache.org/common/docs/r0.18.2/hdfs_design.pdf.

BORTHAKUR D. The hadoop distributed file system： architecture and design[EB/OL]. （20070701） [20151005]. http：//web.mit.edu/～mriap/hadoop/hadoop0.13.1/docs/hdfs_design.pdf.

[17]

RUMBLE S. Memory and object management in RAMCloud [D]. Stanford： Stanford University， 2014： 5-22.

[18]

STUTSMAN R. Durability and crash recovery in distributed inmemory storage systems [D]. Stanford： Stanford University， 2013.

OUSTERHOUT A J. Undergraduate durability and crash recovery in a distributed inmemory storage system [D]. Stanford： Stanford University， 2013： 17-47.

[19]

FREEMAN L C. Centrality in social networks conceptual clarification [J]. Social Networks， 1979， 1（3）： 215-239.2012年

[20]

王元卓，于建業，邱雯，等.網絡群體行為的演化博弈模型與分析方法[J].計算機學報，2015，38（2）：282-300.（WANG Y Z， YU J Y， QIU W， et al. Evolutionary game model and analysis methods for network group behavior [J]. Chinese Journal of Computers， 2015， 38（2）： 282-300.）

[21]

The Apache Software Foundation. ZooKeeper： because coordinating distributed systems is a zoo [EB/OL].[20151112]. https：//zookeeper.apache.org/doc/r3.5.1alpha/index.pdf.

[22]

JUNQUEIRA F P， REED B C. The life and times of a ZooKeeper [C]// PODC 09： Proceedings of the 28th ACM Symposium on Principles of Distributed Computing. New York： ACM， 2009： 4.