京東丁俊:京東分散式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資料結構、支援二級索引、支援事務三方面優化。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2153969/，如需轉載，請註明出處，否則將追究法律責任。