從15年3月接觸Ceph分佈式存儲系統，至今已經5年了；因爲工作的需要，對Ceph的主要模塊進行了較深入的學習，也在Ceph代碼層面做了些許改進，以滿足業務需要（我們主要使用M版本）。最近得閒，將過往的一些學習心得、改進以及優化思路記錄下了，希望能對後來者有所幫助。
這是第三篇：Ceph中IO的一致性
不僅僅是Ceph，所有的分佈式存儲系統都會涉及到多個層面的數據一致性，具體到Ceph層面，我們從如下幾個方面來說明：
- 網絡一致性
- 不同對象間的一致性
- 相同對象的併發一致性
- 副本間的一致性
網絡一致性
這裏的網絡一致性是指：Ceph網絡消息層面的順序性；Ceph通過tid將客戶端回話（Session）與發送的消息關聯起來，這樣收到應答後就知道是哪個請求的應答；
總結：通過tid來標識客戶端請求
不同對象間的一致性
Ceph採用Crush一致性僞隨機算法將對象分配存儲到不同的PG中，在OSD層面，採用ShardedOpWQ隊列及其關聯的OSDShard結構暫存IO請求，各IO請求根據PG id取模暫存到相應的OSDShard中，顯然相同PG的不同請求映射到同一個OSDShard；之後OSD通過ShardedThreadPool線程池來處理隊列中的請求，各線程根據OSDShard個數取模處理不同的OSDShard中的IO請求，因此不同的PG中的請求可以並行處理，而同一個PG中的對象串行處理，因爲OSD在處理PG時會持有PG鎖直到IO的元數據提交。
總結：不同PG中的不同對象的請求可以並行處理
相同對象的併發一致性
前面一節中提到，OSD在處理某PG的IO請求過程中，會持有該PG鎖直到該IO的元數據提交，因此同一個PG中的對象請求是串行執行的，同一個對象的IO很自然就是串行執行的了，具體點：在bluestore接收到來自OSD的IO請求事務後，會爲該事務分配一個OpSequencer（請求序列號），並與新生成的bluestore 事務關聯，這樣同一個對象的不同請求按照請求序列號排序執行。
總結：PG中同一個對象的請求串行執行
副本間的一致性
Ceph是強一致性分佈式對象存儲系統，需要等所有的副本都完成IO後纔會給客戶端返回應答。 那麼在異常情況下，是怎麼處理的呢？
- 如果IO過程中，主副本沒有在規定的時間內收到副本應答，那麼主OSD會先發起heartbeat，通過心跳確認副本失聯後，主OSD會將 副本OSD down的信息同步給MON，而後主OSD會發起Peering，在peering前，主OSD會將未完成的IO請求requeue，副本選好後，主OSD會重新發起IO。
- 如果IO過程中，主副本掛了，副本也會檢測到主副本down，然後會有peering，（某個副本被臨時選爲主副本）requeue IO請求，然後重新發起IO。
- 如果是客戶端在發送IO請求前主OSD掛了，那麼等peering完成後，客戶端會重新獲取OSDMap，再次發送請求。
總結：Ceph是強一致的，副本故障後都會將IO requeue，然後重新執行