在雲時代，各個雲廠商普遍使用塊的對象存儲來進行各種檔案對象，比如圖檔或者視訊等。大家比較熟悉的可能有Amazon S3，Facebook的f4，推特的Blobstore等。
今天蟲蟲給大家介紹一個開源的，同時也是一個大廠的分布式對象存儲産品， LinkedIn的Ambry存儲系統。
概述
Ambry設計的目标是使用全局分布式存儲和計算資源，提供高吞吐量、低延遲的塊存儲操作。Ambry在LinkedIn 内部使用，支撐擁有數億使用者的業務超過120 TB共享。為了達到這個規模，團隊必須解決幾個挑戰，包括對象大小的廣泛差異、快速增長和不可預測的讀取工作負載等。
高可用性和水準可擴充性
Ambry 是一個高可用并且最終一緻的系統。在大多數情況下，寫入會寫入本地資料中心，然後異步複制到其他資料中心。這確定在網絡分區下，寫入本地資料中心仍然可用。此外，當一台機器在本地不可用時，Ambry會選擇同一資料中心内另一台機器上的另一個副本來讀取或寫入資料。對于讀取，當資料不存在于本地資料中心時，它會将請求代理到具有blob的資料中心。當然，所有這些都是可配置的。
低營運開銷
Ambry 的一個關鍵設計目标是使叢集的操作變得非常容易。該系統是完全去中心化的，并配備了管理叢集所需的所有工具。此外，大部分操作将在軟體内自動進行，以確定維護叢集所需的手動工作量非常少。
低MTTR（平均修複時間）
這對于分布式系統來說非常重要。機器停機、磁盤故障、伺服器崩潰和 GC 停止程序。所有這些故障在分布式系統中都是完全可以接受的故障。然而，關鍵是要在很短的時間内解決問題。在所有情況下，系統在維修期間都可以使用。 但是，保持較低的MTTR仍然很重要。
雙交叉DC
預設情況下，Ambry 支援主動主動設定。這意味着對象可以寫入任何資料中心的同一分區，也可以從任何其他資料中心讀取。這通常不是許多系統提供的通用功能。Ambry 通過複制以及在需要時将請求代理到遠端資料中心來實作這一點。
适用于大型和小型媒體對象
大多數媒體流量由數萬億個小對象和數十億個大對象組成。系統需要為這種混合工作負載正常運作。在Ambry中實作這一點的方式是将所有對象的寫入合并到一個順序日志中。這確定所有寫入都是批處理并異步重新整理，并且磁盤上的碎片非常少。
成本效益
最後，任何對象存儲都需要長期存儲媒體和資料類型。 随着時間的推移，較舊的資料會變冷并且讀取QPS非常低。此外，對象通常很大并且占用大量空間。 設計應該能夠啟用JBOD，支援硬碟并将空間放大保持在最低限度。
架構
Blob和分區
Ambry 的核心抽象是blob塊，一種用于存儲資料的不可變結構。每個blob都配置設定給磁盤上的一個分區并通過blob ID進行引用。系統的使用者通過執行put, get 和delete操作。
資料分區設計可以自由擴充——當使用者向系統添加更多資料時，它可以添加更多分區。預設情況下，新分區是可讀寫的 （意味着它同時接受 put, get，和 delete流量）。當分區接近容量時，它會轉換為隻讀，這意味着它不再支援通過以下方式存儲新的blob put操作。系統的流量往往以更新的内容為目标，進而給讀寫分區帶來更高的負載。
為了提供對blob 的可擴充讀寫通路，Ambry使用了三個進階元件：叢集管理器（Cluster Managers）、前端層（Frontend Layer）和 資料節點（Datanodes）。
叢集管理器
叢集管理器決定如何跨地理分布式資料中心将資料存儲在系統中，以及存儲叢集的狀态,狀态主要存儲在Zookeeper中。例如，它們存儲Ambry部署的邏輯布局，包括分區可讀寫還是隻讀，以及分區在資料中心磁盤上的位置。
前端層
前端層由無狀态伺服器組成，每個伺服器都從叢集管理器中提取配置。這些伺服器主要響應使用者請求，它們的無狀态特性簡化了擴充——可以将任意數量的新伺服器添加到前端層以響應不斷增加的負載。除了處理請求，前端層還執行安全檢查并将資料記錄到LinkedIn的變更資料捕獲系統更改資料捕獲或事件源 是一種記錄狀态更改的方式，供下遊服務出于任意目的使用/重放，例如複制到輔助資料源。
通過前端層結合，将請求路由到資料節點，例如：提供的狀态将叢集管理器 與處理進階功能的路由庫相
從多個分區中擷取大型“分塊”檔案并組合結果（每個分塊都配置設定有一個 ID，并映射到存儲在分區中的唯一辨別的blob）。
擷取某些分區時對資料節點進行故障檢測。
遵循重試政策以在失敗時擷取資料。
資料節點
Datanodes通過使用幾個性能增強功能來實作對存儲在記憶體（或磁盤中的内容的低延遲通路。為了能夠快速通路blob，資料節點存儲一個索引，将blob ID 映射到它們在存儲媒體中的偏移量。當有操作更新blob的狀态時，資料節點更新此索引。當響應傳入查詢時，datanodes根據該索引來查找blob的狀态。
為了最大化存儲在磁盤緩存中的blob數量，Ambry還優化了索引本身的存儲方式，将索引中較舊的條目分頁到磁盤等。系統還引入SSTables，Cassandra來存儲和壓縮索引。Datanodes還依賴于其他技巧，例如零複制操作這限制了不必要的記憶體操作。 .
基本操作
從用戶端接收到操作時目前端層，伺服器的路由庫幫助聯系正确的分區：
在put操作中，分區是随機選擇的（出于資料平衡的目的），在get/delete 操作中，分區是從blob id 中提取的。
為了put操作，Ambry可以配置為同步複制（確定 blob 在傳回之前出現在多個資料節點上），或異步複制-同步複制可防止資料丢失，但會在寫入路徑上引入更高的延遲。
如果在異步配置中設定，分區交換日志的副本存儲blob及其在存儲中的偏移量。 核對這些日志之後，彼此之間再同步傳遞blob。
性能評測
根據評測報告本文評估了兩個主要領域：吞吐量和延遲 ，以及地理分布式操作。
為了測試系統的吞吐量和延遲（對于大規模面向使用者的低成本服務至關重要），不同大小對象的讀寫流量發送到Ambry。該系統能夠為較大對象的讀/寫提供接近等效的性能，但在許多小的讀/寫操作中達到較低的性能限制。
為了評估地理分布式操作和複制，本文測量了它所需的帶寬和時間，發現兩者幾乎可以忽略不計：
在85%的情況下，複制滞後是不存在的。
複制blo的帶寬很小 (10MB/s)，但資料中心間通信的帶寬更高。
結論
與其他對象存儲，Ambry作為開源的實作，其設計使用全局分布式存儲和計算資源，提供高吞吐量、低延遲的塊存儲操作。可是實作大規模系統下的存儲系統，包括對象大小的廣泛差異、快速增長和不可預測的讀取等特殊情況子啊工作負載。