分布式键值系统Amazon Dynamo简介
分布式鍵值系統Amazon Dynamo簡介
- Dynamo采用的技術
- 虛擬節點
- Gossip協議
- NRW
- Vector Clock
- 讀寫流程
- 參考鏈接
Dynamo采用的技術
| 數據分布 | 改進的一致性哈希(DHT),采用了虛擬節點技術 |
| 復制協議 | 復制寫協議(Replicated-write protocal,NRW參數可調) |
| 數據沖突處理 | 向量時鐘 |
| 臨時故障處理 | 數據回傳機制(Hinted handoff) |
| 永久故障的恢復 | Merkle哈希樹,簡單講就是二叉樹的復制 |
| 成員資格及錯誤檢測 | 基于Gossip的成員資格和錯誤檢測協議 |
虛擬節點
虛擬節點的分配有如下兩種方式:
- 該方法可以保證負載分配的比較平均,但是這個方法的問題是可控性較差,新節點加入、離開系統時,急群眾的原有節點都需要掃描所有的數據從而找出新節點的書絕,Merkle樹也要全部更新;另外增量歸檔、備份變得幾乎不可能。
- 將數據的哈希空間等分為Q=N?SQ=N*SQ=N?S份(N=機器個數,S=每臺機器的虛擬節點數),然后每臺機器隨機選擇S個分割點作為Token,每臺機器對各個數據范圍分別維護一顆Merkle樹。新節點的加入和離開只需要對涉及到的部分進行數據同步。
Gossip協議
執行過程:
Gossip 過程是由種子節點發起,當一個種子節點有狀態需要更新到網絡中的其他節點時,它會隨機的選擇周圍幾個節點散播消息,收到消息的節點也會重復該過程,直至最終網絡中所有的節點都收到了消息。這個過程可能需要一定的時間,由于不能保證某個時刻所有節點都收到消息,但是理論上最終所有節點都會收到消息,因此它是一個最終一致性協議。
Dynamo通過Gossip干了如下幾件事情:
NRW
類似Quorum中的W+R>NW+R>NW+R>N,只不過這三個參數的取值可以根據實際的需求調整,并不一定要滿足大于。由此導致的問題是,在Dynamo這樣的P2P集群中,由于每個節點存儲的集群信息有所不同,可能出現同一條記錄被多個節點同時更新的情況,無法保證多節點之間的更新順序。因此Dynamo引入了向量時鐘(Vector Clock)的技術手段嘗試解決沖突。
NRW對節點失效的保證性也和一般的一致性協議如Raft、paxos不同。W+R>NW+R>NW+R>N僅保證了當存在不超過一臺機器故障時,至少能夠讀到一份有效數據。
NRW還導致了一個問題,假設N=3,W=2,R=2,如果部分寫操作已經返回客戶端成功了但是沒用完全同步到所有的副本,會導致三個副本之間的數據都不一致。因此要Dynamo啟動修復任務,該任務會合并各個副本中的數據并更新過期的副本,從而使得副本間保持一致。
Vector Clock
每個節點對每個對象的操作用向量時鐘[nodes, counter]表示,出現沖突之后需要解決,最常見的沖突解決方式有兩種:
Dynamo只能保證最終一致性,如果多個節點之間的更新順序不一致,客戶端可能讀不到期望結的結果。多客戶端并發操作也很難預測操作結果。
Dynamo最大的問題應該就是,犧牲了一致性,但是沒有換來什么好處。
讀寫流程
Amazon Dynamo采用P2P架構,因此各Replica間不存在主節點,讀寫操作的時候:
參考鏈接
- 《大規模分布式存儲系統 原理解析與架構實戰》 楊傳輝
總結
以上是生活随笔為你收集整理的分布式键值系统Amazon Dynamo简介的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: zookeeper客户端库curator
- 下一篇: 分布式表格系统Google Bigtab