論文鏈接：
http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
Dynamo數據庫提供了一個key-value的高可用性的數據庫。它更是直接啓發了Cassandra數據庫的存儲模式。總結來說，這個數據庫的目的是爲了高可用和可拓展，爲了這兩個目標，它採用了最終一致性的模型。這篇總結很簡略地描述了Dynamo在設計時候考慮的重點和對應的技術選擇。
首先，什麼是Dynamo數據庫？這個數據庫的目的是什麼？
這個是數據庫是Amazon爲了實現高可用和可拓展而開發的，是一個key-value數據庫。加入我們要設計這個數據庫，從哪裏入手呢？
如何在集羣中分發數據和如何備份數據？
在去中心化的集羣裏分發數據，採用一致性哈希算法。而備份數據，也是在一致性哈希算法的基礎上採用多個節點存儲。
接下來，如何副本之間的一致性？
Dynamo爲了維護高可用（尤其是“寫”可用）採取了最終一致性的模型。如何讀？如何寫？ 這個要用到經典的三元組 (N, R, W)，分別代表副本數目，讀成功所需最少返回書，寫成功需要最少執行數。而既然允許不一致的存在，必然要找到解決的辦法，所以
如何解決副本之間不一致？
試想一下，遇到網絡分區，不同分區的寫操作如何保證？讀數據時遇到不同的數據如何取捨？爲了解決這些不一致，Dynamo採用了Vector Clock來處理不一致。
正常的情況都考慮完了，我們知道了怎麼存儲數據，怎麼備份數據，怎麼解決數據不一致，假設系統出現錯誤，該怎麼辦呢？
如何錯誤探測？
簡單一點說，Dynamo使用gossip協議，利用心跳機制來進行錯誤探測。
節點暫時失效怎麼辦？
Hinted handoff來解決。比如A出現故障，先把A的數據“暫存”到其他節點X並且告訴X: “這些數據是A的”。X會在之後的過程中定期掃描這個區域，一旦發現A“復活”了，馬上把數據換回去。
節點永久失效怎麼辦？
用anti-entropy協議來解決。
一下是關於論文的總結：
1 誕生的背景
亞馬遜的業務要求有兩個重點：
-
Reliability: outage是不可忍受的（用戶體驗）
-
Scalable：數據量巨大，增長迅速 （數據增長）
在這個基礎之上，亞馬遜需要開發一個新的數據庫模型，用來增強可用性（尤其是“寫”的可用用）和可拓展性。
在亞馬遜的業務裏，有許多主鍵訪問（primary-key access）的數據，比如購物車，seesion management等等。Dynamo也正是針對這些數據，設計出了key-value的數據庫存儲模式（沒有向傳統數據庫那樣提供複雜的查詢和事務）。
2 Dynamo的技術選擇
很總結的說，Dynamo應用如下技術：
-
Data is partitioned and replicated using consistent hashing
-
Consistency is facilitated by object versioning
-
The consistency among replicas during updates is maintained by a quorum-like technique and a
-
Dynamo employs a gossip based distributed failure detection and membership protocol
簡單來說, consistent hashing分配數據，數據版本號進行一致性管理，quorum-like用來進行數據更新，gossip協議用來錯誤探測和membership。
Dynamo設計的初衷就是爲了那些不需要複雜查詢的key-value型數據。因此Dynamo的設計沒有考慮ACID中的“C”和“I”，所以並沒有對transaction的支持。總的來說，在Dynamo的設計過程中，需要考慮許多問題，比如：
-
Partitioning
-
Load balancing
-
Membership
-
Failure detection
-
Failure recovery
-
Replica synchronization
-
Overload handling
-
State transfer
-
Concurrency and job scheduling
-
Request marshalling
-
Request routing
-
System monitoring
-
Alarming
-
Configuration management
而這篇論文中討論的問題是:
i) Partitioning algorithm：使用virtual consistent hashing
ii) Replication：在consistent hashing之後的N-1個節點裏保存副本
iii) Data versioning: 對一個object的不同副本使用vector clocks。如果 Va （casually <） Vb, 那麼可以直接覆蓋，如果不存在Casually關係，只能合併vector clocks，讓sematic來處理。
iv) Get and Put：Dynamo使用的是與Cassandra相同的機制，一個client先找到一個coordinator，由這個coordinator來負責發送讀寫請求。
同時注意（W，R, N）三元組的搭配
Put:
1. Coordinator generates vector clock and new version
2. Send it to other nodes
Get:
1 Gather versions
2 處理版本不一致的情況，進行處理，並且回寫
v) Handling Failures: Hinted Handoff
在處理暫時的錯誤時（比方說A暫時不可達或者網絡問題），系統會把副本暫時拷貝到D的一個區域內，並且標明這是A的副本。這個區域裏專門存放這個hinted replica。定期掃描這個區域，一旦A恢復馬上把這個副本給A送回去。
vi) Handling permanent failures: Replica synchronization
還是存在一種情況是，hinted replica還沒被送回去就掛了，因此係統使用了另一種協議：anti-entropy protocol來保持副本同步（利用Merkel Tree）。
vii) Membership and failure detection
利用gossip協議
viii) add/remove nodes
採用一致性hashing，比如向AB之間添加了接待X，之後的節點會在確認之後刪除原本他們負責的部分。
ix) Implementation：
每個節點有三個主要的模塊：request coordination, membership and failure detection, a local persistence engine.
Local Persistence engine 可以使用了MySQL等數據庫，request coordination建立在一個事件驅動的編程上，具體是使用JAVA NIO實現的。