MSST 2015的論文(論文在這里）介紹百度云使用的key-value存儲系統atlas的設計，思路相當贊。簡單總結一下，建議想深入學習的同學直接閱讀論文。

存儲場景

百度云94%的文件在[128KB-256KB]之間，所以atlas主要針對小文件存儲

百度云前面有CDN，到達atlas的請求基本都是隨機訪問，atlas是隨機訪問的存儲引擎，不支持range操作

總體架構

atlas主要由PIS和RBS兩個部分組成，下面將分別介紹

PIS存儲接口

atlas的PIS模塊(patch and index slice)直接面向用戶，與其他KV存儲引擎類似，暴露put/get/delete接口，不同的是atlas的key是規定長度128字節的GUID。

PIS以slot(slice)為單位進行數據管理，用戶的key-value會分散存儲到多個slot里，put時atlas的客戶端會根據key計算hash，并對slot數量取模，將key路由至某個slot，每個slot單獨進行數據管理。

PIS的primary副本接收到用戶的put請求，會將請求轉發至多個secondary副本，每個副本都將value追加至本地patch(類似于log文件)，并記錄key的value在patch里的位置信息(offset、length)，當patch到達64MB時，patch將不再寫入數據，PIS會產生一個新的patch文件用于寫，同時會將寫滿的patch以block的形式存儲到RBS里，patch存儲至RBS時，RBS會分配一個唯一的blockid，此時PIS將key==>(blockid、length、offset)的映射關系寫入index模塊(一個類似于 google leveldb的系統)。

PIS接收到get請求時，首先在patch里查找key是否存儲，如果存在則直接從patch讀取value，返回給用戶;如果key在 patch里不存在，則在index里查找，如果index里未找到，則說明atlas并沒有存儲這個key;如果在index里找到，則根據(blockid、length、offset)從RBS里讀取value，返回給用戶。

PIS處理delete請求與leveldb類似，會新寫入一條該key的記錄，標示為key已刪除。

#p#

RBS接口

RBS(raid-like block storage)提供block的讀寫刪接口，block長度固定為64MB，RBS里block只能整個寫入和刪除，但支持部分讀取。

RBS包含一個中心管理節點(master-slave結構)，以及一組存儲節點(part-server)，寫入block時，RBS不再使用傳統的多副本來保證數據可靠性，而是通過erasure-code來保證，極大的節省存儲成本。

64MB的block會被RBS的客戶端切分成8個8MB的part，通過8+4的erasure code計算出4個4MB的part，總共12個part;寫入時，首先從中心節點請求分配一個唯一的blockid，同時分配12個 part-server用于寫入12個part(實際上給了15個part-server信息，3個是備用的，如果存儲12個part時，有某些part 存儲失敗，直接使用備用的part-server，而不用重新向中心節點發送新的請求，減少了與中心節點的交互次數);當12個part存儲成功后，將 part與part-server的對應關系更新至中心節點。

當需要訪問某個block時，RBS客戶端向從中心管理節點查詢block所在的part-server，然后從part-server讀取數據;如果讀取的part-server當時處于故障狀態，會讀取block內其他至少8個part，來恢復該part-server里的數據。

刪除空間回收

PIS里index里的key==>(block, length, offset)信息、RBS里的block==>create-time信息會被推送到離線的hadoop集群，每天計算哪些block是比較老的 (比如2周以前創建的)，并且有效的使用空間低于某個閾值(比如80%)，這批block被認為是需要回收的，atlas將block里有效的數據(沒被刪除或覆蓋)重新寫入一份，即可將block刪除掉。

博文出處：http://blog.yunnotes.net/index.php/baidu-atlas-key-value-store/