Amazon 的 Dynamo 架構

不少核心服務.

先看一個示意圖:

從上圖可以看出，Amazon 的架構是完全的分布式，去中心化。存儲層也做到了分布式。

Dynamo 的可擴充性和可用性采用的都比較成熟的技術，資料分區并用改進的一緻性哈希(consistent hashing)方式進行複制，利用資料對象的版本化實作一緻性。複制時因為更新産生的一緻性問題的維護采取類似 quorum 的機制以及去中心化的複制同步協定。 Dynamo 是完全去中心化的系統，人工管理工作很小。

強調一下 Dynamo 的”額外”特點：

1) 總是可寫

2) 可以根據應用類型優化

Key: Key 唯一代表一個資料對象，對該資料對象的讀寫操通過 Key 來完成.

節點(node)：通常是一台自帶硬碟的主機。每個節點有三個 Java 寫的元件：請求協調器(request coordination)、成員與失敗檢測、本地持久引擎(local persistence engine)

執行個體(instance)；每個執行個體由一組節點組成，從應用的角度看，執行個體提供 IO 能力。一個執行個體上的節點可能位于不同的資料中心内, 這樣一個資料中心出問題也不會導緻資料丢失。

上面提到的本地持久引擎支援不同的存儲引擎。Dynamo 上最主要的引擎是 Berkeley Database Transactional Data Store(存儲處理數百K的對象更為适合），其他還有 BDB Java Edition、MySQL 以及 一緻性記憶體 Cache 等等。

第一個關鍵參數是 N，這個 N 指的是資料對象将被複制到 N 台主機上，N 在 Dynamo 執行個體級别配置，協調器将負責把資料複制到 N-1 個節點上。N 的典型值設定為 3.

複制中的一緻性，采用類似于 Quorum 系統的一緻性協定實作。這個協定有兩個關鍵值：R 與 W。R 代表一次成功的讀取操作中最小參與節點數量，W 代表一次成功的寫操作中最小參與節點數量。R + W>N ，則會産生類似 quorum 的效果。該模型中的讀(寫)延遲由最慢的 R(W)複制決定，為得到比較小的延遲，R 和 W 有的時候的和又設定比 N 小。

(N,R,W) 的值典型設定為 (3, 2 ,2),兼顧性能與可用性。R 和 W 直接影響性能、擴充性、一緻性，如果 W 設定 為 1，則一個執行個體中隻要有一個節點可用，也不會影響寫操作，如果 R 設定為 1 ，隻要有一個節點可用，也不會影響讀請求，R 和 W 值過小則影響一緻性，過大也不好，這兩個值要平衡。對于這套系統的典型的 SLA 要求 99.9% 的讀寫操作在 300ms 内完成。

–待續–

<a href="https://plus.google.com/105637293618598027400?rel=author">Google+</a>