一：簡介
一、背景
1. Swift 最初是由 Rackspace 公司開發的高可用分布式對象存儲服務（Object Storage Service），并于 2010 年貢獻給 OpenStack 開源社群作為其最初的核心子項目之一，為其 Nova 子項目提供虛機鏡像存儲服務。Swift 構築在比較便宜的标準硬體存儲基礎設施之上，無需采用 RAID（磁盤備援陣列），通過在軟體層面引入一緻性散列技術和資料備援性，犧牲一定程度的資料一緻性來達到高可用性和可伸縮性，支援多租戶模式、容器和對象讀寫操作，适合解決網際網路的應用場景下非結構化資料存儲問題。
2. Swift 包括2個組成部分，一個是代理服務（proxy）,一個是存儲服務（storage）。
1. 代理服務是Swift内部存儲的拓撲邏輯，即一個具體檔案位于哪個存儲節點的哪個區上。它同時是一個web伺服器，通過http或https對外提供REST API服務。
2. 存儲服務是負責檔案存儲的服務，由3個元件組成：account-server、container-server、object-server。其中object-server負責具體的檔案存儲，container-server包含到每個object的索引，account-server包含到每個container 的索引。
二、原理
1. 一緻性散列（Consistent Hashing)：Swift 是基于一緻性散列技術，通過計算可将對象均勻分布到虛拟空間的虛拟節點上，在增加或删除節點時可大大減少需移動的資料量；虛拟空間大小通常采用 2 的 n 次幂，便于進行高效的移位操作；然後通過獨特的資料結構 Ring（環）再将虛拟節點映射到實際的實體儲存設備上，完成尋址過程。
1. 平衡性：平衡性是指哈希的結果能夠盡可能的分布到所有的緩沖中去，這樣可以使得所有緩沖空間能夠都得到利用。為了更好的滿足平衡性，引入了虛拟節點概念，虛拟節點是實際節點在hash空間的複制品，一個實際節點對應若幹個虛拟節點，這個對應的個數也稱為複制個數，虛拟節點在hash空間以hash值排列。
2. 單調性：單調性是指如果已經有些内容通過Hash分派到相應的緩沖中，又有新的緩沖加入到系統中，哈希的結果應能夠保證原有已配置設定的内容可以被映射到原有或者新的緩沖中區，而不會被映射到舊的或者其他緩沖區。
3. 分散性：在分布式環境中，用戶端可能看不到所有的緩沖，而隻能看到其中一部分。當終端希望通過哈希過程将内容映射到緩沖上時，由于不同的用戶端所看到的緩沖範圍可能不同，進而導緻得到的Hash結果不一緻，導緻結果相同的内容被映射到不用的緩沖區中。這種情況應該被避免，因為這将會導緻相同的内容将會被映射到不同緩沖區中，降低了系統的存儲效率。
4. 負載：負載時對分散性要求的另一個次元。既然相同的内容可能被映射到不同的緩沖中去，那麼對于同一個緩沖而言，就有可能被不同的使用者映射不同的内容。與分散性一樣，這種情況應該被避免。
5. 如圖所示，以逆時針方向遞增的散列空間有 4 個位元組長共 32 位，整數範圍是[0~232-1]；将散列結果右移 m 位，可産生 232-m個虛拟節點，例如 m=29 時可産生 8 個虛拟節點。在實際部署的時候需要經過仔細計算得到合适的虛拟節點數，以達到存儲空間和工作負載之間的平衡。
2. 資料一緻性模型（Consistency Model）
1. 按照 Eric Brewer 的 CAP（Consistency，Availability，Partition Tolerance）理論，無法同時滿足 3 個方面，Swift 放棄嚴格一緻性（滿足 ACID 事務級别），而采用最終一緻性模型（Eventual Consistency），來達到高可用性和無限水準擴充能力。為了實作這一目标，Swift 采用 Quorum 仲裁協定(Quorum 有法定投票人數的含義)：
1. 定義：N：資料的副本總數；W：寫操作被确認接受的副本數量；R：讀操作的副本數量
2. 強一緻性：R+W>N，以保證對副本的讀寫操作會産生交集，進而保證可以讀取到最新版本；如果 W=N，R=1，則需要全部更新，适合大量讀少量寫操作場景下的強一緻性；如果 R=N，W=1，則隻更新一個副本，通過讀取全部副本來得到最新版本，适合大量寫少量讀場景下的強一緻性。
3. 弱一緻性：R+W<=N，如果讀寫操作的副本集合不産生交集，就可能會讀到髒資料；适合對一緻性要求比較低的場景。
2. Swift 針對的是讀寫都比較頻繁的場景，是以采用了比較折中的政策，即寫操作需要滿足至少一半以上成功 W >N/2，再保證讀操作與寫操作的副本集合至少産生一個交集，即 R+W>N。Swift 預設配置是 N=3，W=2>N/2，R=1 或 2，即每個對象會存在 3 個副本，這些副本會盡量被存儲在不同區域的節點上；W=2 表示至少需要更新 2 個副本才算寫成功；當 R=1 時意味着某一個讀操作成功便立刻傳回，此種情況下可能會讀取到舊版本（弱一緻性模型）；當 R=2 時，需要通過在讀操作請求頭中增加 x-newest=true 參數來同時讀取 2 個副本的中繼資料資訊，然後比較時間戳來确定哪個是最新版本（強一緻性模型）；如果資料出現了不一緻，背景服務程序會在一定時間視窗内通過檢測和複制協定來完成資料同步，進而保證達到最終一緻性。如圖 2 所示：
3. 環的資料結構
1. 環是為了将虛拟節點（分區）映射到一組實體儲存設備上，并提供一定的備援度而設計的，其資料結構由以下資訊組成：
1. 儲存設備清單、裝置資訊包括唯一辨別号（id）、區域号（zone）、權重（weight）、IP 位址（ip）、端口（port）、裝置名稱（device）、中繼資料（meta）。
2. 分區到裝置映射關系（replica2part2dev_id 數組)。
3. 計算分區号的位移(part_shift 整數，即圖 1 中的 m)。
2. 使用對象的層次結構 account/container/object 作為鍵，使用 MD5 雜湊演算法得到一個散列值，對該散列值的前 4 個位元組進行右移操作得到分區索引号，移動位數由上面的 part_shift 設定指定；按照分區索引号在分區到裝置映射表（replica2part2dev_id）裡查找該對象所在分區的對應的所有裝置編号，這些裝置會被盡量選擇部署在不同區域（Zone）内，區域隻是個抽象概念，它可以是某台機器，某個機架，甚至某個建築内的機群，以提供***别的備援性，建議至少部署 5 個區域；權重參數是個相對值，可以來根據磁盤的大小來調節，權重越大表示可配置設定的空間越多，可部署更多的分區。
4. 資料模型
1. Swift 采用層次資料模型，共設三層邏輯結構：Account/Container/Object（即賬戶/容器/對象)，每層節點數均沒有限制，可以任意擴充。
2. 賬戶和個人賬戶不是一個概念，可了解為租戶，用來做頂層的隔離機制，可以被多個個人賬戶所共同使用；
3. 容器代表封裝一組對象，類似檔案夾或目錄；葉子節點代表對象，由中繼資料和内容兩部分組成，如圖所示：
三、特性
1. 大量對象的存儲（Storage of large number of objects）。
2. 大對象的存儲（Storage of large sized objects）。
3. 資料備援（Data Redundancy）。
4. 檔案能力——存儲大資料集（Archival capabilities - Work with large datasets）。
5. 虛拟機和雲應用的資料容器（Data container for virtual machines and cloud apps）。
6. 流媒體的能力（Media Streaming capabilities）。
7. 對象存儲安全（Secure storage of objects）。
8. 備份和檔案（Backup and archival）。
9. 極高的擴充性（Extreme scalability）
二：架構
一、核心架構
二、元件詳解
1. 代理服務（Proxy Server）：對外提供對象服務 API，會根據環的資訊來查找服務位址并轉發使用者請求至相應的賬戶、容器或者對象服務；由于采用無狀态的 REST 請求協定，可以進行橫向擴充來均衡負載。
2. 認證服務（Authentication Server）：驗證通路使用者的身份資訊，并獲得一個對象通路令牌（Token），在一定的時間内會一直有效；驗證通路令牌的有效性并緩存下來直至過期時間。
3. 緩存服務（Cache Server）：緩存的内容包括對象服務令牌，賬戶和容器的存在資訊，但不會緩存對象本身的資料；緩存服務可采用 Memcached 叢集，Swift 會使用一緻性雜湊演算法來配置設定緩存位址。
4. 賬戶服務（Account Server）：提供賬戶中繼資料和統計資訊，并維護所含容器清單的服務，每個賬戶的資訊被存儲在一個 SQLite 資料庫中。
5. 容器服務（Container Server）：提供容器中繼資料和統計資訊，并維護所含對象清單的服務，每個容器的資訊也存儲在一個 SQLite 資料庫中。
6. 對象服務（Object Server）：提供對象中繼資料和内容服務，每個對象的内容會以檔案的形式存儲在檔案系統中，中繼資料會作為檔案屬性來存儲，建議采用支援擴充屬性的 XFS 檔案系統。
7. 複制服務（Replicator）：會檢測本地分區副本和遠端副本是否一緻，具體是通過對比散列檔案和進階水印來完成，發現不一緻時會采用推式（Push）更新遠端副本，例如對象複制服務會使用遠端檔案拷貝工具 rsync 來同步；另外一個任務是確定被标記删除的對象從檔案系統中移除。
8. 更新服務（Updater）：當對象由于高負載的原因而無法立即更新時，任務将會被序列化到在本地檔案系統中進行排隊，以便服務恢複後進行異步更新；例如成功建立對象後容器伺服器沒有及時更新對象清單，這個時候容器的更新操作就會進入排隊中，更新服務會在系統恢複正常後掃描隊列并進行相應的更新處理。
9. 審計服務（Auditor）：檢查對象，容器和賬戶的完整性，如果發現比特級的錯誤，檔案将被隔離，并複制其他的副本以覆寫本地損壞的副本；其他類型的錯誤會被記錄到日志中。
10. 賬戶清理服務（Account Reaper）：移除被标記為删除的賬戶，删除其所包含的所有容器和對象。
三、Swift對CAP的支援程度
1. CAP概述：美國著名科學家，Berkerly大學Brewer教授提出的一個分布式系統不能同時滿足一緻性，可用性和分區容錯性這三個需求，最多隻能同時滿足兩個。重要屬性：
1. 一緻性(Consistency)：任何一個讀操作總是能讀取到之前完成的寫操作結果，也就是在分布式環境中，多點的資料是一緻的。
2. 可用性(Availability)：每一個操作總是能夠在确定的時間内傳回，也就是系統随時都是可用的。
3. 分區可容忍性(Tolerance of network Partition)：在出現網絡分區（比如斷網）的情況下，分離的系統也能正常運作。
2. Swift對CAP的支援
1. Consistency：Swift的一緻性歸為弱一緻性模型。Swift 由 updater 保證最終一緻性，auditor 保證存儲對象的完整性。Swift 隻能保證資料的最終一緻性，即，如果upload(update也是一種upload)一個object,從其他用戶端GET這個object，不一定是最新的。
2. Availability：基于python對hash的 原生支援，swift中廣泛使用了hash算法。比如均衡ring中partition的分布，object update備份政策。sqlite控制account/container/object的相關資訊，簡化了維護成本。
三：常用操作