Amazon Dynamo閱讀筆記
論文主要內容
- 系統(tǒng)架構
- 系統(tǒng)接口
- 分區(qū)算法
- 復制
- 數(shù)據(jù)版本
- 系統(tǒng)接口的實現(xiàn)過程
- 提示交移（hinted handoff）
- membership and failure detection（經典理論）
- 節(jié)點的增刪
- 實現(xiàn)
- 經驗
- 如何平衡性能(performance)和持久性(durability)
- 如何保證負載的在每一個節(jié)點上的均勻分布
- 沖突的選擇：是在服務度解決沖突還是在客戶端解決沖突
SLA
在論文中邦投，有專門的一節(jié)來討論dynamo的SLA棚愤，所以仰猖，關于SLA值得記錄一下。關于服務質量的衡量指標，一般來說可以用平均數(shù)來表示拖吼，例如用300ms的平均響應時間來表示。而dynamo卻用了一個特別的衡量指標：99.9%的請求的響應時間少于300ms。注意忌愚，這跟用平均數(shù)有比較大的差別，因為用平均數(shù)却邓，即使你的平均數(shù)很低薄料，但也有可能有相當一部分請求的響應時間很高庄呈。
改進的一致性哈希算法
在傳統(tǒng)的一致性哈希算法上，服務節(jié)點跟哈希環(huán)上的點是一一對應的。這里會存在一個問題鹏漆，就是每一個節(jié)點的負載最后是不均勻的这难，而我們也無法進行調整枫甲。dynamo通過一個服務節(jié)點可以有多個哈希環(huán)上的虛擬節(jié)點的方法装黑，使得每一個服務節(jié)點的負載都是均勻的。并且假如發(fā)現(xiàn)了某一個節(jié)點的負載過高民傻，少分配虛擬節(jié)點給它便可以降低該服務節(jié)點的負載胶逢，從而實現(xiàn)了自動地負載均衡。
時鐘向量實現(xiàn)多版本數(shù)據(jù)
在CAP中饰潜，dynamo選擇了AP初坠，犧牲了C。因此彭雾，dynamo中得數(shù)據(jù)必然存在不一致性碟刺。為了在數(shù)據(jù)不一致的沖突，dynamo給每一個數(shù)據(jù)附加了一個時鐘向量來表示數(shù)據(jù)的版本薯酝。
hinted handoff
這是一個比較強悍的功能半沽。dynamo為了保證服務的可用性，當一個節(jié)點down之后吴菠，本來應該路由到該節(jié)點的寫依然可以被接受者填。這些寫請求會被路由到哈希環(huán)上的下一個可用節(jié)點，然后對落地的數(shù)據(jù)標上記號做葵，表示這個數(shù)據(jù)不是屬于本節(jié)點的占哟，而是屬于A節(jié)點的（打個比方）。然后當A節(jié)點恢復之后，數(shù)據(jù)又會被復制到A節(jié)點榨乎。
R + W > N
N指備份數(shù)怎燥；R、W分別表示讀和寫請求的成功數(shù)蜜暑。這條不等式的意思是我們可以配置不同的R铐姚、W、N來實現(xiàn)不同等級可用性和性能肛捍。
