京東丁俊:京東分布式K-V存儲設計與挑戰

  大多數企業夢寐以求的存儲系統是什么樣的呢?當圖片、文章甚至視頻需要存儲時，你希望既不丟失還要提供高速讀寫的能力;當磁盤壞了，你的數據依然還在;當用戶訪問量成倍增長，讀寫能力依然保持高速。當大促來臨，用戶體驗依然無差。這一切都是京東分布式K-V存儲的設計原動力，京東商城-基礎架構部丁俊在SACC大會《數據庫架構設計與實踐》現場分享了京東分布式K-V存儲的設計與挑戰。

　　京東分布式存儲兩大產品是非持久化存儲JIMDB與持久化存儲FBASE。其中，JIMDB兼容REDIS協議，在線彈性伸縮的，數據全部保存在內存的K-V存儲系統;FBASE支持多協議，支持范圍查找的持久化K-V存儲系統。對一些對讀寫性能要求較高的場景，性能自然優先于數據可靠性，JIMDB是合適的選擇;對數據可靠性要求高，數據量大，數據冷熱分布明顯的場景，選擇FBASE是明智的。

　　丁俊表示，整個設計過程面臨著諸多挑戰，比如故障檢測與恢復、在線擴容、高可用以及升級等，JIMDB的故障檢測與恢復容易出現基數大、故障次數多，人工響應慢和誤判等問題，出現這種問題的原因可能是部分網絡故障或者服務程序繁忙造成響應慢。主要的解決方案是將故障檢測程序獨立部署，分散在不同機架上;投票決定，存活狀態一票否決;一個機房部署多組，每組負責部分實例;宿主機agent輔助檢測確認。

　　隨著近兩年京東618、雙11大促的火熱，業務增長遠超預期，資源緊缺成為一種常態，這種情況下就需要考慮在線擴容的問題了。丁俊表示，擴容觸發條件是單個分片內存占用大小和進出流量(CPU使用率)，而單個分片的大小主要考慮擴容過程的持續時間和CPU與內存的使用率。

　　在擴容之前，最好提前把將要變更的拓撲信息下發給客戶端，客戶端捕捉到特定異常后使用臨時拓撲，擴容完成后臨時拓撲變更為正式拓撲，這三步可以保證平滑擴容。但要注意數據遷移的最小單位為槽，單shard需要控制大小，避免遷移數據多時間長。

　　對于多副本異步復制，副本部署要求是跨物理機、跨機房、同城跨機房以及異地數據中心。至于JIMDB異地災備，可直接部署slave，內存緩沖區;經過synclog模塊，異地機房只是一個遠程副本;集群間有復制關系。

　　如果需要升級，丁俊表示，內存中的數據需要做遷移，按照shard滾動升級，新版本的容器創建在同一臺宿主機上，遷移完成后客戶端捕捉到數據已遷移的異常，會使用新的拓撲。

　　至于持久化存儲Fbase，KEY全局有序排列，支持多種復制模式，支持schema，支持模板列，插入時可以自動添加列，存儲層LSM-Tree(Log-Structured Merge Tree)。適用場景是按key訪問，或者單個partition內范圍掃描。缺點是不能全局范圍掃描，讀取必須帶有partition key，

　　兼容redis協議、partition second index等特性的Table，一個partition對應一個dataserver，有容量限制，需要提前規劃。緩存有塊緩存和KEY緩存兩種方式，按照hash規則進行分區的，需要開啟KEY級別的緩存。

　　新一輪的電商狂歡節又要來臨，京東分布式K-V存儲系統可準備好了嗎?丁俊表示，未來的K-V存儲將主要從redis數據結構、支持二級索引、支持事務三方面優化。