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

1?????? 概述

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

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

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

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

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

Swift的主要特性如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

假設(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）理論，無法同時(shí)滿足3個(gè)方面，Swift放棄嚴(yán)格一致性（滿足ACID事務(wù)級別），而采用最終一致性模型（Eventual Consistency），來達(dá)到高可用性和無限水平擴(kuò)展能力。

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

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

Swift針對的是讀寫都比較頻繁的場景，所以采用了比較折中的策略，即寫操作需要滿足至少一半以上成功W>N/2，再保證讀操作與寫操作的副本集合至少產(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è)存儲節(jié)點(diǎn)發(fā)生損壞，就會有單點(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è)對象會存在3個(gè)副本，這些副本會被盡量存儲在不同區(qū)域的節(jié)點(diǎn)上；W=2表示至少需要更新2個(gè)副本才算寫成功。

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

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

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

圖3 Quorum協(xié)議示例

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

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

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

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

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

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

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

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

總的來說，Ring引入一致性哈希的原因是為了減少由于增加結(jié)點(diǎn)導(dǎo)致數(shù)據(jù)項(xiàng)移動的數(shù)量來提高單調(diào)性；引入partition的原因是為了減少由于節(jié)點(diǎn)數(shù)過少導(dǎo)致移動過多的數(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（賬戶/容器/對象）。每層節(jié)點(diǎn)數(shù)均沒有限制，可以任意擴(kuò)展。這里的賬戶和個(gè)人賬戶不是一個(gè)概念，可理解為租戶，用來做頂層的隔離機(jī)制，可以被多個(gè)個(gè)人賬戶所共同使用；容器類似文件夾，代表封裝一組對象；對象由元數(shù)據(jù)和數(shù)據(jù)兩部分組成。

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

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

圖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)部被稱為_replica2part2dev_id；
• Partition Shift Value，表示計(jì)算數(shù)據(jù)hash的移位量，在Ring類內(nèi)部稱為_part_shift。

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

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

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

存儲內(nèi)容一般放在/srv/node/sdb1之類的路徑下，其目錄結(jié)構(gòu)如下所示：accounts、async_pending、containers、objects、quarantined和tmp。其中accounts、containers、objects分別是賬號、容器、對象的存儲目錄，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記錄到來的同步數(shù)據(jù)項(xiàng)；表outgoing_sync表示推送出的同步數(shù)據(jù)項(xiàng)。
• containers：containers目錄結(jié)構(gòu)和生成過程與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)寫入數(shù)據(jù)前的臨時(shí)目錄。例如，client向server上傳某一文件，object server調(diào)用DiskFile類的mkstemp方法創(chuàng)建在路徑為path/device/tmp的目錄。在數(shù)據(jù)上傳完成之后，再調(diào)用put()方法，將數(shù)據(jù)移動到相應(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ù)在更新完成之后，移動pending文件到目標(biāo)目錄。
• quarantined：quarantined路徑用于隔離發(fā)生損壞的數(shù)據(jù)。Auditor進(jìn)程會在本地服務(wù)器上每隔一段時(shí)間就掃描一次磁盤來檢測account、container、object的完整性。一旦發(fā)現(xiàn)不完整的數(shù)據(jù)，該文件就會被隔離，該目錄就稱為quarantined目錄。為了限制Auditor消耗過多的系統(tǒng)資源，其默認(rèn)掃描間隔是30秒，每秒最大的掃描文件數(shù)為20，最高速率為10Mb/s。account和container的Auditor的掃描間隔比object要長得多。

圖5 隔離對象的處理流程

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

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

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

6?????? 參考資料

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

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

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

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

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

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

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

總結(jié)

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

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