前言

昨天(傳送門
提到如果今天有5個replicas，
搭配 W+W > N 與 W+R > N 我們再搭配timestamp可以讀到最新的結果。

1. 寫入除了因為挑選 W 的replica來寫入外
2. 也有可能某些replica server在寫入時是故障狀態，所以也沒有機會寫入新資料

因此最終，如上圖，系統仍必須同步所有的replicas成同一個版本資料結果，也就是v2。

這部分可以怎麼做呢?

Read-Repair and Anti-Entropy

Read-Repair

先回到昨天最後一個讀的例子

(右圖) 如果 W + R > N，R >= 3，規定R=3，會發現他一樣至少會讀到一個被複寫過的replica R3，而透過timestamp t2 來找到最新的值v2。

而 Read-Repair 的方法就是當client(或是client與系統之間的proxy)讀取資料時，除了選出最新的的資料所為read結果外。還將最新結果在暗中寫回那些版本不是最新的replicas中，讓系統最中可以同步所有的資料結果。 如下圖 (取自《Designing Data-Intensive Application》):

replica 3 因為故障的關係沒有寫入新資料，當 user 2345 讀取時，除了從replica 1&2 拿到最新資料外還同時將結果寫回replica 3來同步結果。

Anti-Entropy

除了上述這種邊讀取邊同步的方法，當然還可以有另外一種更簡單直觀的方式。
那就是整個系統有一個獨立的process的不斷檢查每個replicas的資料版本，並同步成最新的。

如果系統的應用情境偏向頻繁讀取操作的，就可以使用Read-Repair。反之，Anti-Entropy可以讓系統即使讀取不頻繁仍能保持最終同步。

Sloppy Quorum & Hinted Handoff

同步的方法講完了，現在再把視角拉遠來看。
採用上述的 W+W > N 與 W+R > N 我們稱為 Strict Quorum。
但是如果你是一路追這系列到這篇的一定知道，這怎麼想Availability一定很低啊。如果今天很多replicas都暫時死掉了或是斷線了，導致client沒辦法連到W/R個replicas，那豈不是這服務對client就暫時不能用了，因為Network Partition導致Consistency不能保證所以回覆Error給Client？

於是DynamoDB說，為了Availability，我們改變W/R的限制，用Consistency來換取Availability。

再往下前，我們要修正一下前面的變數。DB儲存數據通常是用Sharding儲存的，比方說分成3份，我們說 n=3 存在replica R1, R2, R3。但是系統可能有超過n個replica server，我們說m=5個replica servers。
因此前面的W+W > N 與 W+R > N，這個N更常指涉的是Sharding存在replica servers數量，而不是全部的。

假設今天client存在DynamoDB的資料被複製成3份存在R1,R2,R3 (n=3)，那當然未來讀寫也應該針對R1,R2,R3這3個replica servers。
如果好巧不巧其中一個replica server死掉了，這時怎麼處理呢?

Sloppy Quorum
此時因為N=3，W/R=2，理論上應該要從R1、R2與R3，3個取2個做讀寫。Sloppy Quorum允許W/R=2的兩個replica servers不一定要從原先的N個servers做選擇。當R3可能暫時故障時，此時系統可以先寫入R4或是R5，同時標記這個資料應該是要被寫入R3的。

Hinted Handoff:
當R3從故障中恢復時，系統會再將此資料寫回R3以保證R1,R2,R3的資料是一致的，此作法稱為 Hinted Handoff

總結

可以看到改為 Sloppy Quorum DynamoDB裡的replica servers不一定都是處在最新的資料狀態，仍能提供使用者讀寫的服務，來達到雲端服務該有的Availability。

1. Write: 利用 Sloppy Quorum + Hinted Handoff => Alaways Writable
2. Read: DynamoDB 在使用Eventual Consistency時，本來就是一定可以Read，只是不一定是最新資料，透過Quorum System可以提高讀到新資料的機率，也會利用Read-Repair同步系統的write的舊資料

我們再重新看一下DynamoDB的文件，會開始對裡面關於一致性的議題、讀寫的問題有點感覺了

if your application requires strongly consistent reads, it must perform all of its strongly consistent reads and writes in the same Region. DynamoDB does not support strongly consistent reads across Regions. Therefore, if you write to one Region and read from another Region, the read response might include stale data that doesn't reflect the results of recently completed writes in the other Region.

接下來還會接觸的主題
DyanmoDB如何處理Conflict Writes - Logical/Vector Clock
DynamoDB與P2P或是OpenStack Swift如何做資料的Partitioning - Consistenct Hashing (E.g. CHORD)

漸漸的我們已經學了一些分散式系統常用的理論與技術，拼圖漸漸拼上