Swift的哈希一致性副本數(shù)據(jù)備份節(jié)點自適應(yīng)選取研究

杜華 郭俊 劉華春

摘 ?要： 冗余數(shù)據(jù)備份是云數(shù)據(jù)中心下數(shù)據(jù)可靠性的重要保障機制之一，OpenStack是一種開源的云計算IaaS層私有云服務(wù)搭建平臺，目前已經(jīng)在行業(yè)界廣泛應(yīng)用。OpenStack的Swift模塊采用一致性哈希算法，通過Ring環(huán)選取副本備份節(jié)點的方式完成負(fù)載均衡和數(shù)據(jù)備份。通過對Swift的實現(xiàn)機理和代碼進行分析研究，指出其在副本放置節(jié)點選取上的不足，進而提出優(yōu)化選取策略ABS。該機制在實時監(jiān)控當(dāng)前存儲節(jié)點的負(fù)載情況基礎(chǔ)上，根據(jù)預(yù)先設(shè)定的閾值上、下限自適應(yīng)選取最近可用的節(jié)點完成備份，以優(yōu)化整體備份效率。通過與現(xiàn)有副本備份策略進行對比和實驗驗證表明，ABS在保持?jǐn)?shù)據(jù)副本分配均衡性的基礎(chǔ)上，將系統(tǒng)存儲的四種讀寫性能分別提高了3.4%～9.1%，達到了優(yōu)化存取的目的。

關(guān)鍵詞： 副本; 數(shù)據(jù)備份; Swift; ABS; 自適應(yīng)選取; 負(fù)載均衡

中圖分類號： TN915.9?34; TP311 ? ? ? ? ? ? ? ? ? 文獻標(biāo)識碼： A ? ? ? ? ? ? ? ? ? ?文章編號： 1004?373X（2019）13?0090?06

Research on adaptive selection of Swift′s Hash consistency replica data backup node

DU Hua1， 2， GUO Jun2， LIU Huachun2

（1. Southwestern Institute of Physics， Chengdu 610225， China; 2. Department of Electronic Information and Computer Engineering， The Engineering

and Technical College of Chengdu University of Technology， Leshan 614000， China）

Abstract： Redundant data backup is one of the important guarantee mechanisms to ensure the reliability of data under the cloud data center. OpenStack is an open source platform for cloud computing， which belongs to IaaS layer private cloud services， and is widely used in computer field. The Swift module， as one of the OpenStack′s modules， uses the consistent Hash algorithm， and adopts Ring loop method to choose the replica backup node for load balancing and data backup. The implementation mechanism and code of Swift are researched to point out the shortcomings of the selection of the nodes in the replica placement nodes， and then the optimization selection strategy adaptive backup strategy （ABS） is put forward. On the basis of real?time monitoring of the current storage node load， the mechanism selects the recently available nodes adaptively to complete the backup according to predetermined threshold， which can optimize the overall backup efficiency. The proposed replica strategy is compared with the existing replica backup strategy. The experimental results show that the ABS can improve four reading and writing performances of the system by 3.4%～9.1% while maintaining the balance of data replica allocation， and achieves the purpose of optimizing access.

Keywords： replica; data backup; Swift; ABS; adaptive selection; load balancing

0 ?引 ?言

根據(jù)NIST對云計算的定義，云計算是利用虛擬化技術(shù)將各種IT資源整合到一起，以IT資源池的形式向云用戶提供“按需獲取、按量計費”的一種新的資源使用形式。存儲資源是IT資源中比較基礎(chǔ)的資源之一，云計算采用大量低成本、低性能的基礎(chǔ)設(shè)施構(gòu)建大容量、高性能存儲服務(wù)[1]，所以在行業(yè)范圍內(nèi)快速發(fā)展。

OpenStack是目前國內(nèi)外較為流行的開源云計算IaaS層搭建平臺，該平臺技術(shù)已經(jīng)在多個實踐業(yè)務(wù)領(lǐng)域有過成功的項目經(jīng)驗，且處在快速的版本迭代中，平臺功能日趨完善，平臺性能日趨穩(wěn)定。

OpenStack的Swift模塊專門負(fù)責(zé)云存儲功能[2]，該模塊目前主要采用基于復(fù)制的靜態(tài)副本管理策略。其主要思路是根據(jù)機架敏感與原理，將數(shù)據(jù)的一個副本放置在本地機架的存儲節(jié)點上，以獲取較高的網(wǎng)絡(luò)交換速度，從而提高數(shù)據(jù)備份的效率;另一個副本放置在不同機架的存儲節(jié)點上，以犧牲一定的網(wǎng)絡(luò)交換速度的方式來獲取更高的數(shù)據(jù)可靠性，避免一個機架的故障造成同一機架上的原始數(shù)據(jù)和備份數(shù)據(jù)同時損壞，從而造成數(shù)據(jù)不可恢復(fù)。

但是Swift在保持?jǐn)?shù)據(jù)一致性時，通過簡單的再次哈希方式選取副本存儲節(jié)點[3]，而沒有具體分析不同節(jié)點在存儲性能上的差異，可能形成性能瓶頸并造成整體存儲性能優(yōu)化不夠的問題。

為此，本文在深入分析Swift的一致性哈希算法和Ring環(huán)機制的基礎(chǔ)上，提出一種自適應(yīng)備份機制，通過綜合分析副本節(jié)點的計算、存儲和網(wǎng)絡(luò)帶寬性能，選取更加合適的副本節(jié)點，提高Swift的存儲效率。

1 ?Swift模塊

1.1 ?Swift的存儲組織結(jié)構(gòu)

OpenStack是2010年7月，由RackSpace和美國國家航空航天局合作，分別貢獻出RackSpace云文件平臺代碼和NASA Nebula，并以Apache許可證開源發(fā)布的一個云計算IaaS層搭建平臺[4]。它是一種云操作系統(tǒng)，通過數(shù)據(jù)中心控制計算、存儲和網(wǎng)絡(luò)資源池，所有的管理工作只需要通過網(wǎng)絡(luò)接口使用系統(tǒng)自帶的Dashboard來操作。

OpenStack主要支持兩種形式的存儲：一種是對象存儲（Object?Based Storage），由Swift模塊負(fù)責(zé)完成;另一種是塊存儲（Block Storage），由Cinder模塊負(fù)責(zé)完成。

對象存儲適合用于存放靜態(tài)數(shù)據(jù)[5]。所謂靜態(tài)數(shù)據(jù)是指不太可能發(fā)生更新，或是更新頻率比較低的數(shù)據(jù)。例如虛擬機的鏡像、多媒體數(shù)據(jù)以及數(shù)據(jù)備份的副本都屬于此類。

Swift從架構(gòu)上可以分為兩個層次：訪問層和存儲層。訪問層負(fù)責(zé)RESTful請求的處理和用戶身份的認(rèn)證。存儲層由一系列的物理存儲節(jié)點組成，負(fù)責(zé)對象數(shù)據(jù)的存儲。為了在系統(tǒng)出現(xiàn)故障的情況下有效隔離，存儲層在物理上又劃分為以下4個部分[6]：

1） Region：物理位置上相互隔絕的地區(qū)，每個Swift系統(tǒng)默認(rèn)至少有一個Region。

2） Zone：一個Region內(nèi)部相互隔離的硬件區(qū)域，一個Zone代表一個獨立的存儲節(jié)點。

3） Device：在OpenStack中，通常是指一個廉價的磁盤。

4） Partition：OpenStack的Partition是指在Device上的文件系統(tǒng)中的目錄，不是通常意義上的磁盤分區(qū)。在Swift中，副本是以Partition為單位實現(xiàn)的，Swift管理副本的最小粒度是Partition。

Swift所存儲的對象在邏輯上又分為Account，Container和Object三個層次[7]，如圖1所示。

圖1 ?Swift對象存儲的邏輯結(jié)構(gòu)

Account代表對象存儲過程中的頂層隔離。一個Account代表一個租戶，一個租戶可能由多個個人賬戶共同使用。Container代表一組對象的封裝，類似文件夾或目錄。Swift要求一個對象必須存儲在某個Container中，所以一個Account至少應(yīng)該由一個Container來提供對象的存儲。Object代表被存儲的確切的數(shù)據(jù)對象。

1.2 ?Swift的負(fù)載均衡

通過對用Python語言編寫的Swift源代碼（/common/ring/ring.py文件）進行分析可以發(fā)現(xiàn)：Swift主要采用一致性哈希算法來選擇存儲節(jié)點，存放原始數(shù)據(jù)，以保證節(jié)點存儲負(fù)載的均衡，其核心工作機制如圖2所示。

Ring環(huán)的主要工作原理如下：根據(jù)數(shù)據(jù)中心存儲節(jié)點的個數(shù)[n]，將Ring均勻地分為[n]段，然后每個分段的長度就是[232n]。計算每個待存儲對象的Hash值，如果計算結(jié)果為[m]，那么它就應(yīng)該分配到[m×232n]分段所對應(yīng)的節(jié)點服務(wù)器上。

為了快速尋找對象的副本數(shù)據(jù)所在節(jié)點位置，Ring還要使用2個數(shù)據(jù)結(jié)構(gòu)表：設(shè)備表（Device Table）和設(shè)備查詢表（Device Lookup Table）。其中，設(shè)備表用來記錄每一個確切的Device所在的具體位置信息。設(shè)備表包含Region，Zone，IP，Port和Weight信息。而設(shè)備查詢表存儲的就是每個副本（默認(rèn)為3個）所在Device的確切信息。

圖2 ?Swift的Ring環(huán)映射圖

1.3 ?Swift的負(fù)載均衡

按照Eric Brewer的CAP（Consistency，Availability，Partition Tolerance）理論，數(shù)據(jù)存儲無法同時滿足三個方面。

假設(shè)變量[N]代表數(shù)據(jù)的副本總數(shù)，變量[W]代表寫操作被確認(rèn)接受的副本數(shù)量，變量[R]代表讀操作的副本數(shù)量。則有如下定義：

強一致性（[R+W>N]）：在這種一致性原則下，副本的讀寫操作一定會產(chǎn)生交集，從而保證可以讀取到最新版本。

弱一致性（[R+W≤N]）：在這種一致性原則下，讀寫操作的副本集合不產(chǎn)生交集，所以可能會讀到臟數(shù)據(jù);適合對一致性要求比較低的場景。

Swift采用比較折中的策略，寫操作需要滿足至少一半以上成功，即[W>N2]，再保證讀操作與寫操作的副本集合至少產(chǎn)生一個交集，即[R+W>N]。這種方式稱作最終一致性模型（Eventual Consistency），目的是兼顧高可用性和無限水平擴展能力[8]。

Swift默認(rèn)配置是[N=3]，[W=2>N2]，[R=1]或2，即每個對象會存在3個副本，這些副本會盡量被存儲在不同區(qū)域的節(jié)點上，[W=2]表示至少需要更新2個副本才算寫成功。

當(dāng)[R=1]時，意味著某一個讀操作成功便立刻返回，此種情況下可能會讀取到舊版本（弱一致性模型）;

當(dāng)[R=2]時，需要通過在讀操作請求中增加[x-]newest=true參數(shù)來同時讀取2個副本的元數(shù)據(jù)信息。

然后比較時間戳來確定哪個是最新版本（強一致性模型）;如果數(shù)據(jù)出現(xiàn)不一致，后臺服務(wù)進程會在一定時間窗口內(nèi)通過檢測和復(fù)制協(xié)議來完成數(shù)據(jù)同步，從而保證達到最終一致性。

Swift通過三種服務(wù)解決副本數(shù)據(jù)的一致性問題[9]：

Auditor：通過持續(xù)掃描磁盤來檢查Account，Container和Object的完整性。如果發(fā)現(xiàn)數(shù)據(jù)有所損壞，Auditor就會對文件進行隔離，然后通過Replicator從其他節(jié)點上獲取對應(yīng)的副本以恢復(fù)本地數(shù)據(jù)。

Updater：在創(chuàng)建一個Container時需要對包含該Container的Account信息進行更新，使得該Account數(shù)據(jù)庫里面的Container列表包含新創(chuàng)建的Container。同時，在創(chuàng)建一個Object時，需要對包含該Object的Container信息進行更新，使得該Container的數(shù)據(jù)庫里面的Object列表包含新創(chuàng)建的Object信息。

Replicator：負(fù)責(zé)檢測各個節(jié)點上的數(shù)據(jù)及其副本是否一致。當(dāng)發(fā)現(xiàn)不一致時，會將過時的副本更新為最新版本，并且將標(biāo)記為刪除的數(shù)據(jù)真正從物理介質(zhì)上刪除。

2 ?自適應(yīng)備份策略ABS

2.1 ?Swift存在的不足

從前面對Swift的分析可以發(fā)現(xiàn)：Swift采用Ring結(jié)構(gòu)，使用一致性哈希的原理很好地解決了負(fù)載均衡性問題。但是在副本存放節(jié)點的選擇上，簡單地查找通過進一步Hash的方式隨機獲取放置節(jié)點，沒有考慮所選節(jié)點本身的實時存儲性能和網(wǎng)絡(luò)帶寬，這在理論上可能形成兩個結(jié)果：

1） 副本所在節(jié)點設(shè)備存儲性能有差異，使得數(shù)據(jù)同步讀寫時性能降低到與性能較低的設(shè)備匹配，降低了系統(tǒng)的整體存儲性能。

2） 副本所在Zone的網(wǎng)絡(luò)帶寬有差異，可能使得網(wǎng)絡(luò)帶寬成為數(shù)據(jù)讀寫時的瓶頸，降低系統(tǒng)的整體存儲性能。

從以往的研究來看也證實了這兩種現(xiàn)象。文獻[10]發(fā)現(xiàn)在千兆網(wǎng)環(huán)境下，負(fù)載均衡服務(wù)器網(wǎng)卡的數(shù)據(jù)吞吐能力是存儲節(jié)點利用率的瓶頸。在萬兆網(wǎng)和超高并發(fā)連接時，存儲節(jié)點的帶寬基本用完，而負(fù)載均衡節(jié)點和代理節(jié)點的帶寬還有富余。文獻[11]中采用單線程測試上傳速率，發(fā)現(xiàn)在相同存儲環(huán)境下，傳輸相同大小的文件，并發(fā)量越大Swift傳輸性能越高。文獻[12]中實測發(fā)現(xiàn)多線程比單線程性能提升約25%的Swift寫性能，但即使如此，從整體上看，Swift的大文件寫性能依然比較差，沒有充分利用磁盤的帶寬[13]。

2.2 ?Swift的改進方法

為了彌補Swift的上述兩個不足，提高存儲效率，可以從存儲節(jié)點的網(wǎng)絡(luò)帶寬、讀寫速率、磁盤負(fù)載方面著力，盡可能提高基礎(chǔ)設(shè)施的利用率，在整體上發(fā)揮設(shè)備性能。

因此，考慮為不同的存儲節(jié)點增加性能評估預(yù)測，在保持整個Ring負(fù)載均衡的前提下，選擇性能較優(yōu)的節(jié)點作為副本放置的節(jié)點[14]。所謂性能較優(yōu)主要表現(xiàn)為兩個方面：

1） 網(wǎng)絡(luò)性能較優(yōu)：帶寬更高、交換速率更快的網(wǎng)絡(luò)設(shè)備所在節(jié)點在選擇性上應(yīng)該更優(yōu)。

2） 存儲性能較優(yōu)：CPU處理速度更快、磁盤的平均讀寫速率更快、IOPS更高，當(dāng)前存取負(fù)載較低的節(jié)點，在選擇性上應(yīng)該更優(yōu)。

所以，為了改進Swift的工作性能，必須在對現(xiàn)有節(jié)點的負(fù)載進行實時監(jiān)控的情況下[15]，根據(jù)監(jiān)控數(shù)據(jù)評估各個節(jié)點，然后根據(jù)Hash值和評估結(jié)果選擇較好的副本存儲節(jié)點。

2.3 ?ABS

根據(jù)前面的改進思路，繪制出ABS（Adaptive Backup Strategy）工作機制示意圖，如圖3所示。

圖3 ?ABS工作機制示意圖

為了便于描述算法，定義如下概念：

1） 實時負(fù)載率[R]：某存儲節(jié)點的實際負(fù)載與滿負(fù)載情況下的比值。特別地，[Ri]表示第[i]個存儲節(jié)點的實時負(fù)載率。

2） 資源利用率：存儲節(jié)點的CPU、磁盤、網(wǎng)絡(luò)帶寬之中任何一個的實時利用情況。

3） 資源上閾值：存儲節(jié)點的某項資源利用率上限值。

4） 資源下閾值：存儲節(jié)點的某項資源空閑時的利用率。

并據(jù)此定義節(jié)點[i]的實時負(fù)載率為：

5） 定義VIM（Virtual Infrastructure Manager）負(fù)責(zé)計算當(dāng)前所有存儲節(jié)點的[Ri]值，并依據(jù)該值維護負(fù)載排序表LST（Load Sorting Table）。

定義當(dāng)前Ring中所有節(jié)點的平均負(fù)載率為[Ravg]：

ABS算法的目標(biāo)就是實時監(jiān)測當(dāng)前所選節(jié)點的實時負(fù)載率。如果實時負(fù)載率低于平均負(fù)載率，那么選擇該節(jié)點作為副本放置目標(biāo);如果實時負(fù)載率高于平均負(fù)載率，那么在LST中選擇緊挨著該節(jié)點的、首個低于平均負(fù)載率的節(jié)點作為副本放置目標(biāo)。

2.4 ?ABS的實現(xiàn)

構(gòu)建的LST數(shù)據(jù)結(jié)構(gòu)表中包含三種重要信息，即設(shè)備所在的物理地址信息（設(shè)備ID），設(shè)備的實時負(fù)載率和設(shè)備的優(yōu)先級排序。一個可能的LST示意表如表1所示。

表1 ?LST示意表

3 ?ABS仿真和分析

3.1 ?算法仿真

系統(tǒng)仿真使用了6臺Dell PowerEdgeT30服務(wù)器搭建了基本的OpenStack平臺，其中1臺作為控制節(jié)點，1臺作為計算節(jié)點，4臺作為存儲節(jié)點。服務(wù)器CPU為E3?1225，3.3 GHz，8 MB緩存;內(nèi)存為16 GB;STAT硬盤，容量1 TB;PCIe接口千兆網(wǎng)卡構(gòu)成局域網(wǎng)絡(luò)。

初始參數(shù)設(shè)置如表2所示。

表2 ?各項參數(shù)數(shù)值表

3.2 ?算法分析

從算法1可以分析得知，整個ABS算法的核心語句就是第6，12，18的if語句塊。它們的執(zhí)行次數(shù)決定了整個算法的執(zhí)行次數(shù)量級。

所以，ABS算法在隨機狀況下近似于最優(yōu)狀況下的執(zhí)行次數(shù)，時間復(fù)雜程度隨問題規(guī)模呈[Ο（n2）]增長態(tài)勢。

3.3 ?實測分析

本文所提出的ABS副本放置策略與Swift原來的簡單放置策略在負(fù)載均衡、資源利用和網(wǎng)絡(luò)動蕩三方面進行了比較。

1） 負(fù)載均衡

實驗方法：選取大量*.py文件（即OpenStack的源代碼文件）放置于/tmp/files目錄下。然后用server.py程序啟動服務(wù)器，將大量的源碼文件向測試系統(tǒng)進行上傳。所使用命令如下：

圖4 ?負(fù)載均衡情況對比

從圖4中可以看出，文件總數(shù)為1 896，在ABS算法下，存儲文件數(shù)最多的節(jié)點是Node3，有481個，比理論預(yù)期值超出0.37%;文件數(shù)存儲最少的節(jié)點是Node4，有466個，比理論預(yù)期值偏少0.42%。整體而言，新算法在負(fù)載均衡方面基本上保持了原有算法的均衡性。

2） 資源利用

實驗方法：通過使用TestDFSIO基準(zhǔn)測試來隨機評價單個節(jié)點磁盤的I/O效率，包括順序?qū)?、順序讀、隨機讀、反向讀四種。得到的對比結(jié)果如圖5所示。

圖5 ?磁盤資源利用率對比

從圖5中可以看出，ABS算法在順序讀和隨機讀兩項操作中提升相對明顯，分別提升了9.1%和6.7%的讀取性能。但在反向讀的讀取性能上提升比較有限，僅有4.8%。順序?qū)懙奶嵘畈幻黠@，僅有3.4%。

4 ?結(jié) ?語

本文提出的ABS算法在原來Swift一致性哈希原理對副本放置節(jié)點的順序選取基礎(chǔ)上進行改進，實現(xiàn)了一種根據(jù)實時負(fù)載情況進行存儲節(jié)點選取的增強算法。通過實驗分析，ABS算法在保持原來較好的負(fù)載均衡優(yōu)點之上，磁盤讀寫性能提高了3.4%～9.1%，有了一定的改進。

考慮到磁盤讀寫帶寬和IOPS基本已經(jīng)達到極限，要想在現(xiàn)有機制下更進一步提高整體存儲的效率很難，因此，如何使用糾刪碼等新方式，通過未來云的強大計算性能來提升副本備份的效率可能成為一個可行的研究方向。

參考文獻

[1] ?XU Jing， YANG Shoubao， WANG Shuling， et al. CDRS： an adaptive cost?driven replication strategy in cloud storage [J]. ?Journal of the Graduate School of the Chinese Academy of Sciences， 2011， 28（6）： 759?767.

[2] 英特爾開源技術(shù)中心.OpenStack設(shè)計與實現(xiàn)[M].北京：電子工業(yè)出版社，2015：183?217.

Intel Open Source Technology Center. The design & implementation of OpenStack [M]. Beijing： Electronic Industry Press， ? ? ?2015： 183?217.

[3] 戢友.OpenStack開源云王者歸來[M].北京： 清華大學(xué)出版社，2014：337?369.

JI You. Return of the Open Source Cloud King [M]. Beijing： Tsinghua University Press， 2014： 337?369.

[4] TSUYUZAKI K， SHIRAISHI M. Recent activities involving OpenStack Swift [J]. NTT technical review， 2015， 13（12）： 1?6.

[5] KIM J M， JEONG H Y， CHO I， et al. A secure smart?work service model based OpenStack for cloud computing [J]. Cluster computing， 2014， 17（3）： 691?702.

[6] ZHANG Tianwei， LEE R B. Monitoring and attestation of virtual machine security health in cloud computing [J]. IEEE micro， 2016， 36（5）： 28?37.

[7] YAMATO Yoji. Cloud storage application area of HDD?SSD hybrid storage， distributed storage， and HDD storage [J]. IEEE transactions on electrical & electronic engineering， 2016， 11（5）： 674?675.

[8] 荀亞玲，張繼福，秦嘯.MapReduce集群環(huán)境下的數(shù)據(jù)放置策略[J].軟件學(xué)報，2015，26（8）：2056?2073.

XUN Yaling， ZHANG Jifu， QIN Xiao. Data placement strategy for MapReduce cluster environment [J]. Journal of software， 2015， 26（8）： 2056?2073.

[9] 唐震，吳恒，王偉，等.虛擬化環(huán)境下面向多目標(biāo)優(yōu)化的自適應(yīng)SSD緩存系統(tǒng)[J].軟件學(xué)報，2017，28（8）：1982?1998.

TANG Zhen， WU Heng， WANG Wei， et al. Self?adaptive SSD caching system for multiobjective optimization in virtualization environment [J]. Journal of software， 2017， 28（8）： 1982?1998.

[10] 鄭馳.基于OpenStack的對象存儲性能實驗及研究[J].微型機與應(yīng)用，2014，33（18）：14?16.

ZHENG Chi. Object storage performance testing and research based on the OpenStack [J]. Microcomputer & its applications， 2014， 33（18）： 14?16.

[11] 王勝俊.Openstack云平臺中Swift組件的研究與測試[J].電腦知識與技術(shù)，2016，12（7）：77?78.

WANG Shengjun. Research and test of Swift components in Openstack cloud platform [J]. Computer knowledge and technology， 2016， 12（7）： 77?78.

[12] 葛江浩.OpenStack Swift關(guān)鍵技術(shù)分析與性能評測[J].微型電腦應(yīng)用，2013，29（11）：9?12.

GE Jianghao. The main technology analysis and performance evaluation on OpenStack Swift [J]. Microcomputer applications， 2013， 29（11）： 9?12.

[13] 陶永才，巴陽，石磊，等.一種基于可用性的動態(tài)云數(shù)據(jù)副本管理機制[J].小型微型計算機系統(tǒng)，2018，39（3）：490?495.

TAO Yongcai， BA Yang， SHI Lei， et al. Management mechanism of dynamic cloud data replica based on availability [J]. Journal of Chinese computer systems， 2018， 39（3）： 490?495.

[14] 徐敏.基于OpenStack的Swift負(fù)載均衡算法[J].計算機系統(tǒng)應(yīng)用，2018，27（1）：127?131.

XU Min. Swift load balancing algorithm based on OpenStack [J]. Computer systems & applications， 2018， 27（1）： 127?131.

[15] 周敬利.改進的云存儲系統(tǒng)數(shù)據(jù)分布策略[J].計算機應(yīng)用，2012，32（2）：309?312.

ZHOU Jingli. Improved data distribution strategy for cloud storage system [J]. Journal of computer applications， 2012， 32（2）： 309?312.

[16] 胡麗聰.基于動態(tài)反饋的一致性哈希負(fù)載均衡算法[J].微電子學(xué)與計算機，2012，29（1）：177?180.

HU Licong. A consistent Hash load balancing algorithm based on dynamic feedback [J]. Microelectronics & computer， 2012， 29（1）： 177?180.