百度云Atlas key-value系統設計
MSST 2015的論文（ 論文在這里 ， PPT在這里 ）介紹百度云使用的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已刪除。
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刪除掉。