我的Java路上那些事兒

在足球比賽里，一個球員在一場比賽中進(jìn)三個球，稱之為帽子戲法(Hat-trick)。在分布式數(shù)據(jù)系統(tǒng)中，也有一個帽子原理(CAP Theorem)，不過此帽子非彼帽子。CAP原理中，有三個要素：

• 一致性(Consistency)
• 可用性(Availability)
• 分區(qū)容忍性(Partition tolerance)

CAP原理指的是，這三個要素最多只能同時實(shí)現(xiàn)兩點(diǎn)，不可能三者兼顧。因此在進(jìn)行分布式架構(gòu)設(shè)計(jì)時，必須做出取舍。而對于分布式數(shù)據(jù)系統(tǒng)，分區(qū)容忍性是基本要求，否則就失去了價值。因此設(shè)計(jì)分布式數(shù)據(jù)系統(tǒng)，就是在一致性和可用性之間取一個平衡。對于大多數(shù)web應(yīng)用，其實(shí)并不需要強(qiáng)一致性，因此犧牲一致性而換取高可用性，是目前多數(shù)分布式數(shù)據(jù)庫產(chǎn)品的方向。

當(dāng)然，犧牲一致性，并不是完全不管數(shù)據(jù)的一致性，否則數(shù)據(jù)是混亂的，那么系統(tǒng)可用性再高分布式再好也沒有了價值。犧牲一致性，只是不再要求關(guān)系型數(shù)據(jù)庫中的強(qiáng)一致性，而是只要系統(tǒng)能達(dá)到最終一致性即可，考慮到客戶體驗(yàn)，這個最終一致的時間窗口，要盡可能的對用戶透明，也就是需要保障“用戶感知到的一致性”。通常是通過數(shù)據(jù)的多份異步復(fù)制來實(shí)現(xiàn)系統(tǒng)的高可用和數(shù)據(jù)的最終一致性的，“用戶感知到的一致性”的時間窗口則取決于數(shù)據(jù)復(fù)制到一致狀態(tài)的時間。

最終一致性(eventually consistent)

對于一致性，可以分為從客戶端和服務(wù)端兩個不同的視角。從客戶端來看，一致性主要指的是多并發(fā)訪問時更新過的數(shù)據(jù)如何獲取的問題。從服務(wù)端來看，則是更新如何復(fù)制分布到整個系統(tǒng)，以保證數(shù)據(jù)最終一致。一致性是因?yàn)橛胁l(fā)讀寫才有的問題，因此在理解一致性的問題時，一定要注意結(jié)合考慮并發(fā)讀寫的場景。

從客戶端角度，多進(jìn)程并發(fā)訪問時，更新過的數(shù)據(jù)在不同進(jìn)程如何獲取的不同策略，決定了不同的一致性。對于關(guān)系型數(shù)據(jù)庫，要求更新過的數(shù)據(jù)能被后續(xù)的訪問都能看到，這是強(qiáng)一致性。如果能容忍后續(xù)的部分或者全部訪問不到，則是弱一致性。如果經(jīng)過一段時間后要求能訪問到更新后的數(shù)據(jù)，則是最終一致性。

最終一致性根據(jù)更新數(shù)據(jù)后各進(jìn)程訪問到數(shù)據(jù)的時間和方式的不同，又可以區(qū)分為：

• 因果一致性。如果進(jìn)程A通知進(jìn)程B它已更新了一個數(shù)據(jù)項(xiàng)，那么進(jìn)程B的后續(xù)訪問將返回更新后的值，且一次寫入將保證取代前一次寫入。與進(jìn)程A無因果關(guān)系的進(jìn)程C的訪問遵守一般的最終一致性規(guī)則。
• “讀己之所寫（read-your-writes）”一致性。當(dāng)進(jìn)程A自己更新一個數(shù)據(jù)項(xiàng)之后，它總是訪問到更新過的值，絕不會看到舊值。這是因果一致性模型的一個特例。
• 會話（Session）一致性。這是上一個模型的實(shí)用版本，它把訪問存儲系統(tǒng)的進(jìn)程放到會話的上下文中。只要會話還存在，系統(tǒng)就保證“讀己之所寫”一致性。如果由于某些失敗情形令會話終止，就要建立新的會話，而且系統(tǒng)的保證不會延續(xù)到新的會話。
• 單調(diào)（Monotonic）讀一致性。如果進(jìn)程已經(jīng)看到過數(shù)據(jù)對象的某個值，那么任何后續(xù)訪問都不會返回在那個值之前的值。
• 單調(diào)寫一致性。系統(tǒng)保證來自同一個進(jìn)程的寫操作順序執(zhí)行。要是系統(tǒng)不能保證這種程度的一致性，就非常難以編程了。

上述最終一致性的不同方式可以進(jìn)行組合，例如單調(diào)讀一致性和讀己之所寫一致性就可以組合實(shí)現(xiàn)。并且從實(shí)踐的角度來看，這兩者的組合，讀取自己更新的數(shù)據(jù)，和一旦讀取到最新的版本不會再讀取舊版本，對于此架構(gòu)上的程序開發(fā)來說，會少很多額外的煩惱。

從服務(wù)端角度，如何盡快將更新后的數(shù)據(jù)分布到整個系統(tǒng)，降低達(dá)到最終一致性的時間窗口，是提高系統(tǒng)的可用度和用戶體驗(yàn)非常重要的方面。對于分布式數(shù)據(jù)系統(tǒng)：

• N — 數(shù)據(jù)復(fù)制的份數(shù)
• W — 更新數(shù)據(jù)是需要保證寫完成的節(jié)點(diǎn)數(shù)
• R — 讀取數(shù)據(jù)的時候需要讀取的節(jié)點(diǎn)數(shù)

如果W+R>N，寫的節(jié)點(diǎn)和讀的節(jié)點(diǎn)重疊，則是強(qiáng)一致性。例如對于典型的一主一備同步復(fù)制的關(guān)系型數(shù)據(jù)庫，N=2,W=2,R=1，則不管讀的是主庫還是備庫的數(shù)據(jù)，都是一致的。

如果W+R<=N，則是弱一致性。例如對于一主一備異步復(fù)制的關(guān)系型數(shù)據(jù)庫，N=2,W=1,R=1，則如果讀的是備庫，就可能無法讀取主庫已經(jīng)更新過的數(shù)據(jù)，所以是弱一致性。

對于分布式系統(tǒng)，為了保證高可用性，一般設(shè)置N>=3。不同的N,W,R組合，是在可用性和一致性之間取一個平衡，以適應(yīng)不同的應(yīng)用場景。

• 如果N=W,R=1，任何一個寫節(jié)點(diǎn)失效，都會導(dǎo)致寫失敗，因此可用性會降低，但是由于數(shù)據(jù)分布的N個節(jié)點(diǎn)是同步寫入的，因此可以保證強(qiáng)一致性。
• 如果N=R,W=1，只需要一個節(jié)點(diǎn)寫入成功即可，寫性能和可用性都比較高。但是讀取其他節(jié)點(diǎn)的進(jìn)程可能不能獲取更新后的數(shù)據(jù)，因此是弱一致性。這種情況下，如果W<(N+1)/2，并且寫入的節(jié)點(diǎn)不重疊的話，則會存在寫沖突