免責(zé)聲明：
??? 本文轉(zhuǎn)自網(wǎng)絡(luò)文章，轉(zhuǎn)載此文章僅為個(gè)人收藏，分享知識(shí)，如有侵權(quán)，請(qǐng)聯(lián)系博主進(jìn)行刪除。
??? 原文作者：崔炳華?
??? 原文地址：http://blog.csdn.net/i_chips/article/details/17787017

1?????? 概述

OpenStack Object Storage（Swift）是OpenStack開(kāi)源云計(jì)算項(xiàng)目的子項(xiàng)目之一。Swift的目的是使用普通硬件來(lái)構(gòu)建冗余的、可擴(kuò)展的分布式對(duì)象存儲(chǔ)集群，存儲(chǔ)容量可達(dá)PB級(jí)。

Swift并不是文件系統(tǒng)或者實(shí)時(shí)的數(shù)據(jù)存儲(chǔ)系統(tǒng)，它是對(duì)象存儲(chǔ)，用于永久類型的靜態(tài)數(shù)據(jù)的長(zhǎng)期存儲(chǔ)，這些數(shù)據(jù)可以檢索、調(diào)整，必要時(shí)進(jìn)行更新。最適合存儲(chǔ)的數(shù)據(jù)類型的例子是虛擬機(jī)鏡像、圖片存儲(chǔ)、郵件存儲(chǔ)和存檔備份。

Swift無(wú)需采用RAID（磁盤(pán)冗余陣列），也沒(méi)有中心單元或主控結(jié)點(diǎn)。Swift通過(guò)在軟件層面引入一致性哈希技術(shù)和數(shù)據(jù)冗余性，犧牲一定程度的數(shù)據(jù)一致性來(lái)達(dá)到高可用性（High Availability，簡(jiǎn)稱HA）和可伸縮性，支持多租戶模式、容器和對(duì)象讀寫(xiě)操作，適合解決互聯(lián)網(wǎng)的應(yīng)用場(chǎng)景下非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)問(wèn)題。

2?????? 技術(shù)特性

2.1??????? Swift的主要特征

Swift的主要特性如下：

• 極高的數(shù)據(jù)持久性（Durability）。
• 完全對(duì)稱的系統(tǒng)架構(gòu)：“對(duì)稱”意味著Swift中各節(jié)點(diǎn)可以完全對(duì)等，能極大地降低系統(tǒng)維護(hù)成本。
• 無(wú)限的可擴(kuò)展性：一是數(shù)據(jù)存儲(chǔ)容量無(wú)限可擴(kuò)展；二是Swift性能（如QPS、吞吐量等）可線性提升。
• 無(wú)單點(diǎn)故障：Swift的元數(shù)據(jù)存儲(chǔ)是完全均勻隨機(jī)分布的，并且與對(duì)象文件存儲(chǔ)一樣，元數(shù)據(jù)也會(huì)存儲(chǔ)多份。整個(gè)Swift集群中，也沒(méi)有一個(gè)角色是單點(diǎn)的，并且在架構(gòu)和設(shè)計(jì)上保證無(wú)單點(diǎn)業(yè)務(wù)是有效的。
• 簡(jiǎn)單、可依賴。

2.2??????? Swift和HDFS的技術(shù)差異

Swift和Hadoop分布式文件系統(tǒng)（HDFS）都有著相似的目的：實(shí)現(xiàn)冗余、快速、聯(lián)網(wǎng)的存儲(chǔ)，它們的技術(shù)差異如下：

• 在Swift中，元數(shù)據(jù)呈分布式，跨集群復(fù)制。而在HDFS使用了中央系統(tǒng)來(lái)維護(hù)文件元數(shù)據(jù)（Namenode，名稱節(jié)點(diǎn)），這對(duì)HDFS來(lái)說(shuō)無(wú)異于單一故障點(diǎn)，因而擴(kuò)展到規(guī)模非常大的環(huán)境顯得更困難。
• Swift在設(shè)計(jì)時(shí)考慮到了多租戶架構(gòu)，而HDFS沒(méi)有多租戶架構(gòu)這個(gè)概念。
• 在Swift中，文件可以寫(xiě)入多次；在并發(fā)操作環(huán)境下，以最近一次操作為準(zhǔn)。而在HDFS中，文件寫(xiě)入一次，而且每次只能有一個(gè)文件寫(xiě)入。
• Swift用Python來(lái)編寫(xiě)，而HDFS用Java來(lái)編寫(xiě)。
• Swift被設(shè)計(jì)成了一種比較通用的存儲(chǔ)解決方案，能夠可靠地存儲(chǔ)數(shù)量非常多的大小不一的文件；而HDFS被設(shè)計(jì)成可以存儲(chǔ)數(shù)量中等的大文件（HDFS針對(duì)更龐大的文件作了優(yōu)化），以支持?jǐn)?shù)據(jù)處理。

3?????? 關(guān)鍵技術(shù)

3.1??????? 一致性哈希（ConsistentHashing）

在分布式對(duì)象存儲(chǔ)中，一個(gè)關(guān)鍵問(wèn)題是數(shù)據(jù)該如何存放。Swift是基于一致性哈希技術(shù)，通過(guò)計(jì)算可將對(duì)象均勻分布到虛擬空間的虛擬節(jié)點(diǎn)上，在增加或刪除節(jié)點(diǎn)時(shí)可大大減少需移動(dòng)的數(shù)據(jù)量；虛擬空間大小通常采用2的n次冪，便于進(jìn)行高效的移位操作；然后通過(guò)獨(dú)特的數(shù)據(jù)結(jié)構(gòu) Ring（環(huán)）再將虛擬節(jié)點(diǎn)映射到實(shí)際的物理存儲(chǔ)設(shè)備上，完成尋址過(guò)程。

圖1 一致性哈希環(huán)結(jié)構(gòu)

衡量一致性哈希的4個(gè)指標(biāo)：

• 平衡性（Balance）：平衡性是指Hash的結(jié)果能夠盡可能分布均勻，充分利用所有緩存空間。
• 單調(diào)性（Monotonicity）：單調(diào)性是指如果已經(jīng)有一些內(nèi)容通過(guò)哈希分派到了相應(yīng)的緩沖中，又有新的緩沖加入到系統(tǒng)中。哈希的結(jié)果應(yīng)能夠保證原有已分配的內(nèi)容可以被映射到新的緩沖中去，而不會(huì)被映射到舊的緩沖集合中的其他緩沖區(qū)。
• 分散性（Spread）：分散性定義了分布式環(huán)境中，不同終端通過(guò)Hash過(guò)程將內(nèi)容映射至緩存上時(shí)，因可見(jiàn)緩存不同，Hash結(jié)果不一致，相同的內(nèi)容被映射至不同的緩沖區(qū)。
• 負(fù)載（Load）：負(fù)載是對(duì)分散性要求的另一個(gè)緯度。既然不同的終端可以將相同的內(nèi)容映射到不同的緩沖區(qū)中，那么對(duì)于一個(gè)特定的緩沖區(qū)而言，也可能被不同的用戶映射為不同的內(nèi)容。

Swift使用該算法的主要目的是在改變集群的node數(shù)量時(shí)（增加/刪除服務(wù)器），能夠盡可能少地改變已存在key和node的映射關(guān)系，以滿足單調(diào)性。

考慮到哈希算法在node較少的情況下，改變node數(shù)會(huì)帶來(lái)巨大的數(shù)據(jù)遷移。為了解決這種情況，一致性哈希引入了“虛擬節(jié)點(diǎn)”（vnode，也稱為partition）的概念： “虛擬節(jié)點(diǎn)”是實(shí)際節(jié)點(diǎn)在環(huán)形空間的復(fù)制品，一個(gè)實(shí)際節(jié)點(diǎn)對(duì)應(yīng)了若干個(gè)“虛擬節(jié)點(diǎn)”，“虛擬節(jié)點(diǎn)”在哈希空間中以哈希值排列。

總的來(lái)說(shuō)，Swift中存在兩種映射關(guān)系，對(duì)于一個(gè)文件，通過(guò)哈希算法（MD5）找到對(duì)應(yīng)的虛節(jié)點(diǎn)（一對(duì)一的映射關(guān)系），虛節(jié)點(diǎn)再通過(guò)映射關(guān)系（ring文件中二維數(shù)組）找到對(duì)應(yīng)的設(shè)備（多對(duì)多的映射關(guān)系），這樣就完成了一個(gè)文件存儲(chǔ)在設(shè)備上的映射。

圖2 對(duì)象、虛結(jié)點(diǎn)、節(jié)點(diǎn)間的映射關(guān)系

在設(shè)置虛結(jié)點(diǎn)數(shù)的時(shí)候，需要對(duì)系統(tǒng)預(yù)期的規(guī)模做充分考慮，假如集群的規(guī)模不會(huì)超過(guò)6000個(gè)結(jié)點(diǎn)，那么可以將虛結(jié)點(diǎn)數(shù)設(shè)置為結(jié)點(diǎn)數(shù)的100倍。這樣，變動(dòng)任意一個(gè)結(jié)點(diǎn)的負(fù)載僅影響1%的數(shù)據(jù)項(xiàng)。此時(shí)有6百萬(wàn)個(gè)vnode數(shù)，使用2bytes來(lái)存儲(chǔ)結(jié)點(diǎn)數(shù)(0~65535)。基本的內(nèi)存占用是6*(10^6)*2bytes=12Mb，對(duì)于服務(wù)器來(lái)說(shuō)完全可以承受。

假設(shè)有65536（2^16）個(gè)node，有128（2^7）倍的partition數(shù)（2^23，則PARTITION_POWER=23）。由于MD5碼是32位的，使用PARTITION_SHIFT（等于32- PARTITION_POWER）將數(shù)據(jù)項(xiàng)的MD5哈希值映射到partition的2^23的空間中。

3.2??????? 數(shù)據(jù)一致性模型（ConsistencyModel）

按照Eric Brewer的CAP（Consistency，Availability，PartitionTolerance）理論，無(wú)法同時(shí)滿足3個(gè)方面，Swift放棄嚴(yán)格一致性（滿足ACID事務(wù)級(jí)別），而采用最終一致性模型（Eventual Consistency），來(lái)達(dá)到高可用性和無(wú)限水平擴(kuò)展能力。

為了實(shí)現(xiàn)這一目標(biāo)，Swift采用Quorum仲裁協(xié)議（Quorum有法定投票人數(shù)的含義）：

• 定義：N：數(shù)據(jù)的副本總數(shù)；W：寫(xiě)操作被確認(rèn)接受的副本數(shù)量；R：讀操作的副本數(shù)量。
• 強(qiáng)一致性：R+W>N，以保證對(duì)副本的讀寫(xiě)操作會(huì)產(chǎn)生交集，從而保證可以讀取到最新版本；如果 W=N，R=1，則需要全部更新，適合大量讀少量寫(xiě)操作場(chǎng)景下的強(qiáng)一致性；如果 R=N，W=1，則只更新一個(gè)副本，通過(guò)讀取全部副本來(lái)得到最新版本，適合大量寫(xiě)少量讀場(chǎng)景下的強(qiáng)一致性。
• 弱一致性：R+W<=N，如果讀寫(xiě)操作的副本集合不產(chǎn)生交集，就可能會(huì)讀到臟數(shù)據(jù)；適合對(duì)一致性要求比較低的場(chǎng)景。

Swift針對(duì)的是讀寫(xiě)都比較頻繁的場(chǎng)景，所以采用了比較折中的策略，即寫(xiě)操作需要滿足至少一半以上成功W>N/2，再保證讀操作與寫(xiě)操作的副本集合至少產(chǎn)生一個(gè)交集，即R+W>N。

在分布式系統(tǒng)中，數(shù)據(jù)的單點(diǎn)是不允許存在的。線上正常存在的replica數(shù)量是1的話將非常危險(xiǎn)的，因?yàn)橐坏┻@個(gè)replica再次錯(cuò)誤，就可能發(fā)生數(shù)據(jù)的永久性錯(cuò)誤。假如我們把N設(shè)置成為2，那么，只要有一個(gè)存儲(chǔ)節(jié)點(diǎn)發(fā)生損壞，就會(huì)有單點(diǎn)的存在。所以N必須大于2。但N越高，系統(tǒng)的維護(hù)和整體成本就越高。所以，工業(yè)界通常把N設(shè)置為3。

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

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

當(dāng)R=2時(shí)，需要通過(guò)在讀操作請(qǐng)求頭中增加x-newest=true參數(shù)來(lái)同時(shí)讀取2個(gè)副本的元數(shù)據(jù)信息，然后比較時(shí)間戳來(lái)確定哪個(gè)是最新版本（強(qiáng)一致性模型）。

如果數(shù)據(jù)出現(xiàn)了不一致，后臺(tái)服務(wù)進(jìn)程會(huì)在一定時(shí)間窗口內(nèi)通過(guò)檢測(cè)和復(fù)制協(xié)議來(lái)完成數(shù)據(jù)同步，從而保證達(dá)到最終一致性。

圖3 Quorum協(xié)議示例

3.3??????? 環(huán)（Ring）

Ring是Swift中最重要的組件，用于記錄存儲(chǔ)對(duì)象與物理位置間的映射關(guān)系。在涉及查詢Account、Container、Object信息時(shí)就需要查詢集群的Ring信息。

環(huán)是為了將虛擬節(jié)點(diǎn)（partition，分區(qū)）均衡地映射到一組物理存儲(chǔ)設(shè)備上，并提供一定的冗余度而設(shè)計(jì)的，其數(shù)據(jù)結(jié)構(gòu)由以下信息組成：

存儲(chǔ)設(shè)備列表、設(shè)備信息包括唯一標(biāo)識(shí)號(hào)（id）、區(qū)域號(hào)（zone）、權(quán)重（weight）、IP 地址（ip）、端口（port）、設(shè)備名稱（device）、元數(shù)據(jù)（meta）。

Swift為賬戶、容器和對(duì)象分別定義了的Ring，其查找過(guò)程是相同的。Ring中每個(gè)partition在集群中都默認(rèn)有3個(gè)replica。每個(gè)partition的位置由ring來(lái)維護(hù)，并存儲(chǔ)在映射中。

Ring使用zone來(lái)保證數(shù)據(jù)的物理隔離。每個(gè)partition的replica都確保放在了不同的zone中。Zone只是個(gè)抽象概念，它可以是一個(gè)磁盤(pán)（disk drive），一個(gè)服務(wù)器（server），一個(gè)機(jī)架（cabinet），一個(gè)交換機(jī)（switch），甚至是一個(gè)數(shù)據(jù)中心（datacenter），以提供最高級(jí)別的冗余性，建議至少部署5個(gè)zone。

權(quán)重參數(shù)是個(gè)相對(duì)值，可以來(lái)根據(jù)磁盤(pán)的大小來(lái)調(diào)節(jié)，權(quán)重越大表示可分配的空間越多，可部署更多的分區(qū)。

當(dāng)集群中發(fā)生存儲(chǔ)節(jié)點(diǎn)宕機(jī)、新增（刪）存儲(chǔ)節(jié)點(diǎn)、新增（刪）zone等必須改變partition和node間的映射關(guān)系時(shí)，還可以對(duì)Ring文件通過(guò)重新平衡（rebalance）來(lái)進(jìn)行更新。當(dāng)虛節(jié)點(diǎn)需要移動(dòng)時(shí)，環(huán)會(huì)確保一次移動(dòng)最少數(shù)量的虛節(jié)點(diǎn)數(shù)，并且一次只移動(dòng)一個(gè)虛節(jié)點(diǎn)的一個(gè)副本。

總的來(lái)說(shuō)，Ring引入一致性哈希的原因是為了減少由于增加結(jié)點(diǎn)導(dǎo)致數(shù)據(jù)項(xiàng)移動(dòng)的數(shù)量來(lái)提高單調(diào)性；引入partition的原因是為了減少由于節(jié)點(diǎn)數(shù)過(guò)少導(dǎo)致移動(dòng)過(guò)多的數(shù)據(jù)項(xiàng)；引入replica的原因是防止數(shù)據(jù)單點(diǎn)、提高冗余性；引入zone的原因是為了保證分區(qū)容忍性；引入weight的原因是為了保證partition分配的均衡。

4?????? 架構(gòu)設(shè)計(jì)

4.1??????? Swift數(shù)據(jù)模型

Swift采用層次數(shù)據(jù)模型，共設(shè)三層邏輯結(jié)構(gòu)：Account/Container/Object（賬戶/容器/對(duì)象）。每層節(jié)點(diǎn)數(shù)均沒(méi)有限制，可以任意擴(kuò)展。這里的賬戶和個(gè)人賬戶不是一個(gè)概念，可理解為租戶，用來(lái)做頂層的隔離機(jī)制，可以被多個(gè)個(gè)人賬戶所共同使用；容器類似文件夾，代表封裝一組對(duì)象；對(duì)象由元數(shù)據(jù)和數(shù)據(jù)兩部分組成。

4.2??????? Swift系統(tǒng)架構(gòu)

Swift采用完全對(duì)稱、面向資源的分布式系統(tǒng)架構(gòu)設(shè)計(jì)，所有組件都可擴(kuò)展，避免因單點(diǎn)失效而擴(kuò)散并影響整個(gè)系統(tǒng)運(yùn)轉(zhuǎn)；通信方式采用非阻塞式 I/O 模式，提高了系統(tǒng)吞吐和響應(yīng)能力。

Swift組件包括：

• 代理服務(wù)（ProxyServer）：Swift通過(guò)Proxy Server向外提供基于HTTP的REST服務(wù)接口，會(huì)根據(jù)環(huán)的信息來(lái)查找服務(wù)地址并轉(zhuǎn)發(fā)用戶請(qǐng)求至相應(yīng)的賬戶、容器或者對(duì)象，進(jìn)行CRUD（增刪改查）等操作。由于采用無(wú)狀態(tài)的REST請(qǐng)求協(xié)議，可以進(jìn)行橫向擴(kuò)展來(lái)均衡負(fù)載。在訪問(wèn)Swift服務(wù)之前，需要先通過(guò)認(rèn)證服務(wù)獲取訪問(wèn)令牌，然后在發(fā)送的請(qǐng)求中加入頭部信息 X-Auth-Token。代理服務(wù)器負(fù)責(zé)Swift架構(gòu)的其余組件間的相互通信。代理服務(wù)器也處理大量的失敗請(qǐng)求。例如，如果對(duì)于某個(gè)對(duì)象PUT請(qǐng)求時(shí)，某個(gè)存儲(chǔ)節(jié)點(diǎn)不可用，它將會(huì)查詢環(huán)可傳送的服務(wù)器并轉(zhuǎn)發(fā)請(qǐng)求。對(duì)象以流的形式到達(dá)（來(lái)自） 對(duì)象服務(wù)器，它們直接從代理服務(wù)器傳送到（來(lái)自）用戶—代理服務(wù)器并不緩沖它們。
• 認(rèn)證服務(wù)（AuthenticationServer）：驗(yàn)證訪問(wèn)用戶的身份信息，并獲得一個(gè)對(duì)象訪問(wèn)令牌（Token），在一定的時(shí)間內(nèi)會(huì)一直有效；驗(yàn)證訪問(wèn)令牌的有效性并緩存下來(lái)直至過(guò)期時(shí)間。
• 緩存服務(wù)（CacheServer）：緩存的內(nèi)容包括對(duì)象服務(wù)令牌，賬戶和容器的存在信息，但不會(huì)緩存對(duì)象本身的數(shù)據(jù)；緩存服務(wù)可采用Memcached集群，Swift會(huì)使用一致性哈希算法來(lái)分配緩存地址。
• 賬戶服務(wù)（AccountServer）：提供賬戶元數(shù)據(jù)和統(tǒng)計(jì)信息，并維護(hù)所含容器列表的服務(wù)，每個(gè)賬戶的信息被存儲(chǔ)在一個(gè)SQLite數(shù)據(jù)庫(kù)中。
• 容器服務(wù)（ContainerServer）：提供容器元數(shù)據(jù)和統(tǒng)計(jì)信息（比如對(duì)象的總數(shù)，容器的使用情況等），并維護(hù)所含對(duì)象列表的服務(wù)。容器服務(wù)并不知道對(duì)象存在哪，只知道指定容器里存的哪些對(duì)象。 這些對(duì)象信息以SQLite數(shù)據(jù)庫(kù)文件的形式存儲(chǔ)，和對(duì)象一樣在集群上做類似的備份。?
• 對(duì)象服務(wù)（ObjectServer）：提供對(duì)象元數(shù)據(jù)和內(nèi)容服務(wù)，可以用來(lái)存儲(chǔ)、檢索和刪除本地設(shè)備上的對(duì)象。在文件系統(tǒng)中，對(duì)象以二進(jìn)制文件的形式存儲(chǔ)，它的元數(shù)據(jù)存儲(chǔ)在文件系統(tǒng)的擴(kuò)展屬性（xattr）中，建議采用默認(rèn)支持?jǐn)U展屬性（xattr）的XFS文件系統(tǒng)。每個(gè)對(duì)象使用對(duì)象名稱的哈希值和操作的時(shí)間戳組成的路徑來(lái)存儲(chǔ)。最后一次寫(xiě)操作總可以成功，并確保最新一次的對(duì)象版本將會(huì)被處理。刪除也被視為文件的一個(gè)版本（一個(gè)以".ts"結(jié)尾的0字節(jié)文件，ts表示墓碑）。
• 復(fù)制服務(wù)（Replicator）：會(huì)檢測(cè)本地分區(qū)副本和遠(yuǎn)程副本是否一致，具體是通過(guò)對(duì)比哈希文件和高級(jí)水印來(lái)完成，發(fā)現(xiàn)不一致時(shí)會(huì)采用推式（Push）更新遠(yuǎn)程副本：對(duì)于對(duì)象的復(fù)制，更新只是使用rsync同步文件到對(duì)等節(jié)點(diǎn)。帳號(hào)和容器的復(fù)制通過(guò)HTTP或rsync來(lái)推送整個(gè)數(shù)據(jù)庫(kù)文件上丟失的記錄；另外一個(gè)任務(wù)是確保被標(biāo)記刪除的對(duì)象從文件系統(tǒng)中移除：當(dāng)有一項(xiàng)（對(duì)象、容器、或者帳號(hào)）被刪除，則一個(gè)墓碑文件被設(shè)置作為該項(xiàng)的最新版本。復(fù)制器將會(huì)檢測(cè)到該墓碑文件并確保將它從整個(gè)系統(tǒng)中移除。
• 更新服務(wù)（Updater）：當(dāng)對(duì)象由于高負(fù)載或者系統(tǒng)故障等原因而無(wú)法立即更新時(shí)，任務(wù)將會(huì)被序列化到在本地文件系統(tǒng)中進(jìn)行排隊(duì)，以便服務(wù)恢復(fù)后進(jìn)行異步更新；例如成功創(chuàng)建對(duì)象后容器服務(wù)器沒(méi)有及時(shí)更新對(duì)象列表，這個(gè)時(shí)候容器的更新操作就會(huì)進(jìn)入排隊(duì)中，更新服務(wù)會(huì)在系統(tǒng)恢復(fù)正常后掃描隊(duì)列并進(jìn)行相應(yīng)的更新處理。
• 審計(jì)服務(wù)（Auditor）：在本地服務(wù)器上會(huì)反復(fù)地爬取來(lái)檢查對(duì)象，容器和賬戶的完整性，如果發(fā)現(xiàn)比特級(jí)的錯(cuò)誤，文件將被隔離，并復(fù)制其他的副本以覆蓋本地?fù)p壞的副本；其他類型的錯(cuò)誤（比如在任何一個(gè)容器服務(wù)器中都找不到所需的對(duì)象列表）會(huì)被記錄到日志中。
• 賬戶清理服務(wù)（AccountReaper）：移除被標(biāo)記為刪除的賬戶，刪除其所包含的所有容器和對(duì)象。刪除賬號(hào)的過(guò)程是相當(dāng)直接的。對(duì)于每個(gè)賬號(hào)中的容器，每個(gè)對(duì)象先被刪除然后容器被刪除。任何失敗的刪除請(qǐng)求將不會(huì)阻止整個(gè)過(guò)程，但是將會(huì)導(dǎo)致整個(gè)過(guò)程最終失敗（例如，如果一個(gè)對(duì)象的刪除超時(shí)，容器將不能被刪除，因此賬號(hào)也不能被刪除）。整個(gè)處理過(guò)程即使遭遇失敗也繼續(xù)執(zhí)行，這樣它不會(huì)因?yàn)橐粋€(gè)麻煩的問(wèn)題而中止恢復(fù)集群空間。賬號(hào)收割器將會(huì)繼續(xù)不斷地嘗試刪除賬號(hào)直到它最終變?yōu)榭?#xff0c;此時(shí)數(shù)據(jù)庫(kù)在db_replicator中回收處理，最終移除這個(gè)數(shù)據(jù)庫(kù)文件。

圖4 Swift系統(tǒng)架構(gòu)

Swift支持的所有操作可以總結(jié)為下表：

表1 SwiftRESTful API總結(jié)

4.3??????? Ring的數(shù)據(jù)結(jié)構(gòu)

Ring 的數(shù)據(jù)結(jié)構(gòu)由三個(gè)頂層域構(gòu)成，其中：

• List of Devices，表示集群中設(shè)備的列表，在Ring類內(nèi)部被稱為devs；
• Partition Assignment List，用于存放每個(gè)replica與device間映射關(guān)系，在Ring類內(nèi)部被稱為_(kāi)replica2part2dev_id；
• Partition Shift Value，表示計(jì)算數(shù)據(jù)hash的移位量，在Ring類內(nèi)部稱為_(kāi)part_shift。

使用python讀取/etc/swift/object.ring.gz存放的數(shù)據(jù)，可以獲得以devs、 part_shift、 replica2part2dev_id 為key的dict類數(shù)據(jù)。

4.4??????? Swift存儲(chǔ)結(jié)構(gòu)

在Storage Node上運(yùn)行著Linux系統(tǒng)并使用了XFS文件系統(tǒng)，邏輯上使用一致性哈希算法將固定總數(shù)的partition映射到每個(gè)Storage Node上，每個(gè)data也使用同樣的哈希算法映射到partition上。

存儲(chǔ)內(nèi)容一般放在/srv/node/sdb1之類的路徑下，其目錄結(jié)構(gòu)如下所示：accounts、async_pending、containers、objects、quarantined和tmp。其中accounts、containers、objects分別是賬號(hào)、容器、對(duì)象的存儲(chǔ)目錄，async_pending是異步待更新目錄，quarantined是隔離目錄，tmp是臨時(shí)目錄。

• objects：在objects目錄下存放的是各個(gè)partition目錄，其中每個(gè)partition目錄是由若干個(gè)suffix_path名的目錄和一個(gè)hashes.pkl文件組成，suffix_path目錄下是由object的hash_path名構(gòu)成的目錄，在hash_path目錄下存放了關(guān)于object的數(shù)據(jù)和元數(shù)據(jù)；object的數(shù)據(jù)存放在后綴為.data的文件中，它的metadata存放在以后綴為.meta的文件中，將被刪除的Object以一個(gè)0字節(jié)后綴為.ts的文件存放。
• accounts：在accounts目錄下存放的是各個(gè)partition，而每個(gè)partition目錄是由若干個(gè)suffix_path目錄組成，suffix_path目錄下是由account的hsh名構(gòu)成的目錄，在hsh目錄下存放了關(guān)于account的sqlite db；在account的db文件中，包含了account_stat、container、incoming_sync 、outgoing_sync 4張表；其中，表account_stat是記錄關(guān)于account的信息，如名稱、創(chuàng)建時(shí)間、container數(shù)統(tǒng)計(jì)等等；表container記錄關(guān)于container的信息；表incoming_sync記錄到來(lái)的同步數(shù)據(jù)項(xiàng)；表outgoing_sync表示推送出的同步數(shù)據(jù)項(xiàng)。
• containers：containers目錄結(jié)構(gòu)和生成過(guò)程與accounts類似，containers的db中共有5張表，其中incoming_sync和outgoing_sync的schema與accounts中的相同。其他3張表分別為container_stat、object、sqlite_sequence；表container_stat與表account_stat相似，其區(qū)別是container_stat存放的是關(guān)于container信息。
• tmp：tmp目錄作為account/container/object server向partition目錄內(nèi)寫(xiě)入數(shù)據(jù)前的臨時(shí)目錄。例如，client向server上傳某一文件，object server調(diào)用DiskFile類的mkstemp方法創(chuàng)建在路徑為path/device/tmp的目錄。在數(shù)據(jù)上傳完成之后，再調(diào)用put()方法，將數(shù)據(jù)移動(dòng)到相應(yīng)路徑。
• async_pending：async_pending存放未能及時(shí)更新而被加入更新隊(duì)列的數(shù)據(jù)。本地server在與remote server建立HTTP連接或者發(fā)送數(shù)據(jù)時(shí)超時(shí)導(dǎo)致更新失敗時(shí)，將把文件放入async_pending目錄。這種情況經(jīng)常發(fā)生在系統(tǒng)故障或者是高負(fù)荷的情況下。如果更新失敗，本次更新被加入隊(duì)列，然后由Updater繼續(xù)處理這些失敗的更新工作；account與container的db和object兩者的pending文件處理方式有所不同：db的pending文件在更新完其中的一項(xiàng)數(shù)據(jù)之后，刪除pending文件中的相應(yīng)的數(shù)據(jù)項(xiàng)，而object的數(shù)據(jù)在更新完成之后，移動(dòng)pending文件到目標(biāo)目錄。
• quarantined：quarantined路徑用于隔離發(fā)生損壞的數(shù)據(jù)。Auditor進(jìn)程會(huì)在本地服務(wù)器上每隔一段時(shí)間就掃描一次磁盤(pán)來(lái)檢測(cè)account、container、object的完整性。一旦發(fā)現(xiàn)不完整的數(shù)據(jù)，該文件就會(huì)被隔離，該目錄就稱為quarantined目錄。為了限制Auditor消耗過(guò)多的系統(tǒng)資源，其默認(rèn)掃描間隔是30秒，每秒最大的掃描文件數(shù)為20，最高速率為10Mb/s。account和container的Auditor的掃描間隔比object要長(zhǎng)得多。

圖5 隔離對(duì)象的處理流程

5?????? 小結(jié)

Swift犧牲一定程度的數(shù)據(jù)一致性，來(lái)達(dá)到高可用性和可伸縮性，支持多租戶模式、容器和對(duì)象讀寫(xiě)操作，適合解決互聯(lián)網(wǎng)的應(yīng)用場(chǎng)景下非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)問(wèn)題。

有理由相信，因?yàn)槠渫耆拈_(kāi)放性、廣泛的用戶群和社區(qū)貢獻(xiàn)者，Swift可能會(huì)成為云存儲(chǔ)的開(kāi)放標(biāo)準(zhǔn)，從而打破Amazon S3在市場(chǎng)上的壟斷地位，推動(dòng)云計(jì)算在朝著更加開(kāi)放和可互操作的方向前進(jìn)。

6?????? 參考資料

1) 《Openstack Swift 原理、架構(gòu)與 API 介紹》，http://www.kankanews.com/ICkengine/archives/66411.shtml

2) 《深入云存儲(chǔ)系統(tǒng)Swift核心組件：Ring實(shí)現(xiàn)原理剖析》，http://www.cnblogs.com/yuxc/archive/2012/06/22/2558312.html

3) 《深入云存儲(chǔ)系統(tǒng)Swift核心組件：Ring數(shù)據(jù)結(jié)構(gòu)及構(gòu)建、重平衡操作》，http://www.cnblogs.com/yuxc/archive/2012/06/28/2568584.html

4) 《深入云存儲(chǔ)系統(tǒng)Swift存儲(chǔ)節(jié)點(diǎn)：存儲(chǔ)實(shí)現(xiàn)分析》，http://www.cnblogs.com/yuxc/archive/2012/07/04/2575536.html

5) 《OpenStack對(duì)象存儲(chǔ)——Swift開(kāi)源云計(jì)算》，http://dev.yesky.com/244/33228744.shtml

6) 《討論：HDFS和OpenStack對(duì)象存儲(chǔ)的技術(shù)差異》，http://os.51cto.com/art/201202/314254.htm

轉(zhuǎn)載于:https://www.cnblogs.com/sdjnzqr/p/3909498.html

總結(jié)

以上是生活随笔為你收集整理的【转载】OpenStack Swift学习笔记的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。