CAP理論

Brewer教授指出了著名的CAP理論，後來Seth Gilbert 和 Nancy

lynch兩人證明了CAP理論的正確性。CAP（Consistency,Availability,partition

tolerance)理論告訴我們，一個分散式系統不可能滿足一致性，可用性和分區容錯性這三個需求，最多只能同時滿足兩個（至於CAP理論的證明，可以

參考附屬檔案的論文）。

在CAP理論的指導下，架構師或者開發者應該清楚，您當前架構和設計的系統真正的需求是什麼？您的系統到底是關注的是可用性還是一致性的需求。

2000年，Eric
brewer教授指出了著名的CAP理論，後來SethGilbert和Nancy
lynch兩人證明了CAP理論的正確性。CAP（Consistency,Availability,partition
tolerance)理論告訴我們，一個分散式系統不可能滿足一致性，可用性和分區容錯性這三個需求，最多只能同時滿足兩個（至於CAP理論的證明，可以
參考附屬檔案的論文）。
在CAP理論的指導下，架構師或者開發者應該清楚，您當前架構和設計的系統真正的需求是什麼？您的系統到底是關注的是可用性還是一致性的需求。如果您的系
統關注的是一致性，那么您就需要處理因為系統不可用而導致的寫操作失敗的情況，而如果您關注的是可用性，那么您應該知道系統的read操作可能不能精確的
讀取到write操作寫入的最新值。因此系統的關注點不同，相應的採用的策略也是不一樣的，只有真正的理解了系統的需求，才有可能利用好CAP理論。2一致性
說起一致性，我們有兩種視角去看待它，第一種是客戶或者開發者視角，此種情況下，客戶或者開發者更加關註：如何觀察到系統的更新，另外一種視覺是伺服器端
視覺，此種情況下，主要關註：更新操作如何flowthrough系統以及系統對更新操作提供什麼樣子的一致性保證。下面就分別從這兩種角度去看看一致性：2.1客戶端一致性為了更好的描述客戶端一致性，我們通過以下的場景來進行，這個場景中包括三個組成部分：存儲系統存儲系統可以理解為一個黑盒子，它為我們提供了可用性和持久性的保證。ProcessAProcessA主要實現從存儲系統write和read操作ProcessB和ProcessCProcessB和C是獨立於A，並且B和C也相互獨立的，它們同時也實現對存儲系統的write和read操作。下面以上面的場景來描述下不同程度的一致性：強一致性（即時一致性）假如A先寫入了一個值到存儲系統，存儲系統保證後續A,B,C的讀取操作都將返回最新值弱一致性假如A先寫入了一個值到存儲系統，存儲系統不能保證後續A,B,C的讀取操作能讀取到最新值。此種情況下有一個“不一致性視窗”的概念，它特指從A寫入值，到後續操作A,B,C讀取到最新值這一段時間。最終一致性最
終一致性是弱一致性的一種特例。假如A首先write了一個值到存儲系統，存儲系統保證如果在A,B,C後續讀取之前沒有其它寫操作更新同樣的值的話，最
終所有的讀取操作都會讀取到最A寫入的最新值。此種情況下，如果沒有失敗發生的話，“不一致性視窗”的大小依賴於以下的幾個因素：互動延遲，系統的負載，
以及複製技術中replica的個數（這個可以理解為master/salve模式中，salve的個數），最終一致性方面最出名的系統可以說是DNS系
統，當更新一個域名的IP以後，根據配置策略以及快取控制策略的不同，最終所有的客戶都會看到最新的值。其中最終一致性（Eventuallyconsistency)還有以下幾個變體，下面分別描述：causalconsistency（因果一致性）：如果ProcessA通知ProcessB它已經更新了數據，那么ProcessB的後續讀取操作則讀取到A寫入的最新值，而與A沒有因果關係的C則採用最終一致性的語義。Read-your-writes
consistency：如果ProcessA寫入了最新的值，那么Process
A的後續操作都會讀取到最新值。比如以本論壇為例，當某用戶發表一個帖子以後，該用戶可以立即看到自己發表的帖子，但是其它用戶可能要過一會才可以看到，
這就是典型的Read-your-writer-consistency。Sessionconsistency:此種一致性要求客戶端和存儲系統互動的整個會話階段保證Read-your-writesconsistency.Hibernate的session提供的一致性保證就屬於此種一致性。Monotonicreadconsistency：此種一致性要求如果ProcessA已經讀取了對象的某個值，那么後續操作將不會讀取到更早的值。Monotonicwriteconsistency：此種一致性保證系統會序列化執行一個Process中的所有寫操作。2.1伺服器端一致性在說伺服器端一致性要求，我們首先要明確幾個概念：N：節點的總個數W更新的時候需要確認已經被更新的節點的個數R：讀取數據的時候讀取數據的節點個數
如果W+R>N，那么分散式系統就會提供強一致性的保證，因為讀取數據的節點和被同步寫入的節點是有重疊的。在一個RDBMS的複製模型中
（Master/salve)，假如N=2,那么W=2,R=1此時是一種強一致性,但是這樣造成的問題就是可用性的減低，因為要想寫操作成功，必須要等
2個節點都完成以後才可以。
在分散式系統中，一般都要有容錯性，因此一般N都是大於3的，此時根據CAP理論，一致性，可用性和分區容錯性最多只能滿足兩個，那么我們就需要在一致性
和分區容錯性之間做一平衡，如果要高的一致性，那么就配置N=W，R=1,這個時候可用性就會大大降低。如果想要高的可用性，那么此時就需要放鬆一致性的
要求，此時可以配置W=1，這樣使得寫操作延遲最低，同時通過異步的機制更新剩餘的N-W個節點。當存儲系統保證最終一致性時，存儲系統的配置一般是W+R<=N,此時讀取和寫入操作是不重疊的，不一致性的視窗就依賴於存儲系統的異步實現方式，不一致性的視窗大小也就等於從更新開始到所有的節點都異步更新完成之間的時間。
無論是Read-your-writes-consistency,Sessionconsistency,Monotonicread
consistency,它們都通過黏貼（stickiness)客戶端到執行分散式請求的伺服器端來實現的，這種方式簡單是簡單，但是它使得負載均衡以
及分區容錯變的更加難於管理，有時候也可以通過客戶端來實現Read-your-writes-consistency和Monotonicread
consistency,此時需要對寫的操作的數據加版本號，這樣客戶端就可以遺棄版本號小於最近看到的版本號的數據。
在系統開發過程中，根據CAP理論，可用性和一致性在一個大型分區容錯的系統中只能滿足一個，因此為了高可用性，我們必須放低一致性的要求，但是不同的系
統保證的一致性還是有差別的，這就要求開發者要清楚自己用的系統提供什麼樣子的最終一致性的保證，一個非常流行的例子就是web套用系統，在大多數的
web套用系統中都有“用戶可感知一致性”的概念，這也就是說最終一致性中的“一致性視窗"大小要小於用戶下一次的請求，在下次讀取操作來之前，數據可以
在存儲的各個節點之間複製。還比如假如存儲系統提供了read-your-write-consistency一致性，那么當一個用戶寫操作完成以後可以
立馬看到自己的更新，但是其它的用戶要過一會才可以看到更新。