Amazon 依靠在電子商務中積累的大量基礎性設施和各類先進技術，很早地進入了雲端計算領域，並在提供計算、儲存等服務方面處於領先地位。

Amazon 開發並提供了一系列雲端計算服務這些雲端計算服務共同構成了 Amazon Web Service

amazon 提供的服務主要包括:

• 彈性計算雲 EC2
• 簡單儲存服務 S3
• 簡單資料庫服務 Simple DB
• 簡單佇列服務 SQS
• 彈性 MapReduce 服務
• 內容推送服務 CloudFront
• 電子商務服務 DevPay
• FPS

這些服務涉及雲端計算的方方面面，使用者完全可以根據自己的需要選取一個或多個Amazon雲端計算服務。所有的這些服務都是按需獲取資源，具有極強的可擴充套件性和靈活性。

基礎儲存架構Dynamo

Amazon 作為目前世界上最主要的電子商務提供商之一，它的系統每天要接受全球數以百萬計的服務請求，髙效的平臺架構是保證其系統穩定性的根本。下圖是面向服務的Amazon平臺基本架構。

從圖中可以看出整個Amazon平臺的架構是完全的分散式、去中心化的，在Amazon的平臺中處於底層位置的儲存架構Dynamo也是如此。Amazon平臺中有很多服務對儲存的需求只是讀取、寫入，即滿足簡單的鍵/值（key/value)式儲存即可，例如：常用的購物車、資訊會話管理和推薦商品列表等，如果採取傳統的關係資料庫方式，則效率低下。針對這種需求，Dynamo應運而生，雖然Dynamo目前並不直接向公眾提供服務，但是大量的使用者服務資料被儲存在Dynamo中。可以說它為Amazon的電子商務平臺及其雲端計算服務提供了最基礎的支援

Dynamo概況

為了保證其穩定性，Amazon的系統採用完全的分散式、去中心化的架構

• 作為底層儲存架構的Dynamo也同樣採用了無中心的模式
• Dynamo只支援簡單的鍵/值（key/value）方式的資料儲存，不支援複雜的查詢
• Dynamo中儲存的是資料值的原始形式，即按位儲存，並不解析資料的具體內容

Dynamo架構的主要技術

Dynamo需要解決的主要問題及解決方案

Dynamo在設計時被定位為一個基於分散式儲存架構的，高可靠、高可用且具有良好容錯性的系統。下圖列舉了Dynamo設計時面臨的主要問題及所採取的解決方案。

Dynamo的儲存節點

Dynamo中的儲存節點呈無中心的環狀分佈。

兩個基本概念：

1. preference list （儲存與某個特定鍵值相對應的資料的節點列表）
2. coordinator （執行一次讀或寫操作的節點）

通常，coordinator 是 preference list 上的第一個節點；一般情況下， preference list 的長度是5，也就是說第一個節點是資料操作節點，後面4個是備份節點。

資料均衡分佈的問題

Dynamo採用了分散式的資料儲存架構，均衡的資料分佈可以保證負載平衡和系統良好的擴充套件性。

因此，如何保證各個節點上資料的均衡性是影響Dynamo效能的關鍵問題。

Dynamo中使用改進後的一致性雜湊演算法，並在此基礎上進行資料備份，以提高系統的可用性。

一致性雜湊演算法

一致性雜湊演算法是目前主流的分散式雜湊表（Distributed Hash Table，DHT）協議之一，於1997年由麻省理工學院提出。

一致性雜湊演算法通過修正簡單雜湊演算法，解決了網路中的熱點問題，使得DHT可以真正地應用於P2P環境中。

給定一個hash值空間，[0~2^32)，假設分佈在一個圓環上，對每個結點算出一個固定hash值，將結點置於環上，對新加入的物件的 key 算出hash值，假設落在節點1和節點2之間，那麼這個資料項< key，Value >就存在節點2開始的結點上。假定副本數為3，那麼就存在節點2和節點2後面兩個結點上面。

一致性雜湊演算法除了能夠保證雜湊運算結果充分分散到整個環上外，還能保證在新增或刪除裝置節點時只會影響到其在雜湊環中的前驅裝置節點，而不會對其他裝置節點產生影響。

一致性雜湊演算法可以大大降低在新增或刪除節點時引起的節點間的資料傳輸開銷

改進的一致性雜湊演算法

因為每臺機器的效能不一樣，所以我們為了能夠充分利用每臺機器的效能，我們需要改進一致性雜湊演算法。於是在Dynamo中引入了虛擬節點的概念

每個虛擬節點都隸屬於某一個實際的物理節點，一個物理節點根據其效能的差異被分為一個或多個虛擬節點。

各個虛擬節點的能力基本相當，並隨機分佈在雜湊環上。

Dynamo將整個雜湊環劃分成Q等份，每個等份稱為一個數據分割槽（Partition）

在儲存資料時，每個資料會被先分配到某個資料分割槽，再根據負責該資料分割槽的虛擬節點，最終確定其所儲存的物理節點。

資料分割槽的好處有：

1. 減小資料分佈不均衡的可能性
2. 新增或刪除裝置節點時引起較小的資料傳輸

資料備份

在Dynamo中，每個資料的副本備份儲存在雜湊環順時針方向上該資料所在虛擬節點的後繼節點中。

資料備份在儲存資料的同時進行，會使每次寫操作的延時變長。

Dynamo中對寫操作進行了優化，保證一個副本必須寫入硬碟，其他副本只要寫入節點的記憶體即返回寫成功。

每個虛擬節點上實際儲存了分配給它以及分配它的前N-1個前驅虛擬節點的資料。

資料衝突問題

分散式系統架構中通常考慮的三個因素：

1. 可靠性（Reliability）
2. 可用性（Availability）
3. 一致性（Consistency）

Dynamo選擇通過犧牲一致性來保證系統的可靠性和可用性 ，沒有採用強一致性模型 而採用了最終一致性模型。

由於Dynamo中可能出現同一個資料被多個節點同時更新的情況，且無法保證資料副本的更新順序，這有可能會導致資料衝突。

資料衝突問題如何解決？

Dynamo中採用了向量時鐘技術（Vector Clock）

Dynamo中的向量時鐘通過[node, counter]對來表示。其中 node 表示操作節點。 counter是其對應的計數器，初始值為 0 節點每進行一次更新操作則計數器加 1

如上圖所示，D3 和 D4 的操作有衝突，於是，我們會把 D3 和 D4 同時交給應用層，讓應用層來選擇合併策略

既然有版本衝突的問題，衝突版本的合併就只能交給上層應用來做，每次讀操作Dynamo將返回讀到的所有版本，若上層應用無法解決合併，那就只能選擇一個最新版本，從而丟失一部分資料，Dynamo論文只舉了購物車的例子，每個值為一個購物車物品集合，每次更新可以往購物車新增，刪除物品，衝突時合併購物車取並集。這樣新增到購物車的操作不會出問題，但是可能會導致刪除的物品重新出現。

成員資格及錯誤檢測

由於Dynamo採用了無中心的架構，每個成員節點都需要儲存其他節點的路由資訊。

為了保證每個節點都能擁有最新的成員節點資訊，Dynamo中採用了一種類似於Gossip（閒聊）協議的技術

Dynamo中還通過Gossip來實現錯誤檢測任何節點向其他節點發起通訊後，如果對方沒有迴應，則認為對方節點失效

為了避免新加入的節點之間不能及時發現其他節點的存在，Dynamo中設定了一些種子節點（Seed Node）。種子節點和所有的節點都有聯絡。當新節點加入時，它扮演一箇中介的角色，使新加入節點之間互相感知。

錯誤檢測的方法是：

• 自底向上每一層代表一次隨機通訊
• 第一層節點1將資訊交換給節點2
• 第二層節點1和2同時開始隨機選擇
• 其他節點交換資訊
• 直到N個節點全部傳遍

如下圖所示：

結論：

• Dynamo中的節點數不能太多
• Amazon採用了分層Dynamo結構來解決該問題

容錯機制

臨時故障處理機制

為了處理臨時失效的節點，Dynamo中採用了一種帶有監聽的資料回傳機制（Hinted Handoff）

當虛擬節點A失效後，會將資料臨時存放在節點D的臨時空間中，並在節點A重新可用後，由節點D將資料回傳給節點A。

永久性故障處理機制

Dynamo採用Merkle雜湊樹技術來加快檢測和減少資料傳輸量

每個虛擬節點儲存三顆Merkle樹，即每個鍵值區間建立一個Merkle樹。Dynamo中Merkle雜湊樹的葉子節點是儲存每個資料分割槽內所有資料對應的雜湊值，父節點是其所有子節點的雜湊值。下圖是兩棵不同的Merkle雜湊樹A和B。

系統比較兩棵同一鍵值區的Merkle雜湊樹時，首先査看根節點，如果相同則說明資料一致，不需要進行資料同步，否則需要繼續比較，直到雜湊值不同的葉子節點，快速定位差異。例如，上圖中A和B的根節點不同，說明需要進行資料同步。緊接著比較A和B的子節點，發現右子樹的根節點2≠5,繼續比較右予樹根節點的子節點，按同樣的步驟一直進行下去，發現需要同步的資料位置。Merkle樹最大特點是隻要比較某個子樹就可以完成資料同步檢測和定位，進而進行同步，大大減少了同步過程中所需傳輸資料量，提高了系統效率。