分布式初探——分布式系統的CAP理論
分布式系統當中有一個著名的CAP理論，它也是分布式系統理論的基礎。
CAP理論最早發表于2000年，由加州伯克利的教授首先在ACM PODC會議上提出猜想，兩年之後，被麻省理工學院的教授Seth Gilbert和Nancy Lynch從理論上證明。從此之後，它成了分布式系統領域的公認定理。
今天這篇文章就和大家聊聊這個大名鼎鼎的CAP理論。
CAP理論描述起來其實很簡單，它說的是一個分布式系統最多隻能滿足C（一緻性）、A（可用性）和P（分區性）這三者當中的兩個。我們先來看一下這三項分别代表了什麼。
Consistency 一緻性
分布式系統當中的一緻性指的是所有節點的資料一緻，或者說是所有副本的資料一緻。用英文描述是：All the nodes see the same data at the same time。它和資料庫事務中的一緻性是兩碼事，在我們之前的文章裡，曾經較長的描述過分布式系統中的各種一緻性模型，感興趣的同學可以點選這裡。
我們可以将一緻性一分為二，分别從用戶端和服務端進行探究。對于用戶端而言，并不關心後端的實作，也不關心後端的節點運作情況。唯一隻關心多次并發通路下都能獲得準确的符合預期的結果。比如使用者多次點選付款，也隻會付款一次，餘額無論什麼時候查詢都是當下最新的值。
而服務端關心的是會引發資料變更的請求過來，能夠及時準确地同步到所有的節點和副本，并且考慮可能會出現的網絡以及通信問題，保證極端情況下依舊不會産生錯誤。
在分布式系統當中，針對不同情況以及不同要求下的一緻性，設計了多種不同的模型。我們可以簡單做一個總結，将它們分為三類：
- 要求當下更新成功的資料立即生效，在後續的通路當中都能傳回最新的結果。這是強一緻性。
- 如果能容忍在更新發生之後，部分情況無法通路到最新資料，這是弱一緻性。
- 如果能容忍更新後一段時間内無法通路到最新資料，但最終可以保證結果準确，這是最終一緻性。
在CAP理論當中，我們說的無法同時滿足的一緻性指的是強一緻性。
Availability 可用性
可用性指的是：Reads and writes always succeed. 也就是說系統一直可用，而且服務一直保持正常。
一個高可用性的分布式系統，必須對使用者的每一個請求做出響應。不可以出現無法通路或者是響應逾時等影響使用者體驗的情況。在一個分布式系統當中，任何一個節點的不穩定，都有可能影響系統的可用性，比如資料庫伺服器、負載均衡，web伺服器承載等等。為了量化系統的可用性，我們通常使用系統停機時間這個名額。即在一年時間内，系統停機的總時長。
據說淘寶可以做到5個9，也就是99.999%的時間内可用。算下來全年系統停機的時間不會超過5分鐘，這是非常難以做到的。
Partition Tolerance 分區容錯性
分區容錯性指的是： System continues operating despire arbitrary message loss or failure of part of the system. 翻譯過來就是說系統在遇到一些節點或者網絡分區故障的時候，仍然能夠提供滿足一緻性和可用性的服務。
分區容錯性和拓展性息息相關，因為越大的分布式系統越有可能出現機器當機，網絡阻塞等情況。即使這些意外情況發生，系統仍然能保持穩定是系統拓展的前提。在分布式系統當中出現的問題可能性很多，既可能出現部分機器當機，也有可能出現内網阻隔，使得整個叢集被拆分成互相不能通信的幾個部分。分區容錯性需要保證即使這些情況發生，系統也一樣可以保證一緻性和可用性。
舉個例子，阿裡經常做機房斷電實驗，實驗的時候直接把一個機房的電源切斷，觀察這個時候系統是否仍然能夠保持穩定。
關于CAP這三個特性我們就介紹完了，接下來我們試着證明一下為什麼CAP不能同時滿足。
為了簡化證明的過程，我們假設整個叢集裡隻有兩個N1和N2兩個節點，如下圖：
N1和N2當中各自有一個應用程式AB和資料庫，當系統滿足一緻性的時候，我們認為N1和N2資料庫中的資料保持一緻。在滿足可用性的時候，我們認為無論使用者通路N1還是N2，都可以獲得正确的結果，在滿足分區容錯性的時候，我們認為無論N1還是N2當機或者是兩者的通信中斷，都不影響系統的運作。
我們假設一種極端情況，假設某個時刻N1和N2之間的網絡通信突然中斷了。如果系統滿足分區容錯性，那麼顯然可以支援這種異常。問題是在此前提下，一緻性和可用性是否可以做到不受影響呢？
我們做個假象實驗，如下圖，突然某一時刻N1和N2之間的關聯斷開：
有使用者向N1發送了請求更改了資料，将資料庫從V0更新成了V1。由于網絡斷開，是以N2資料庫依然是V0，如果這個時候有一個請求發給了N2，但是N2并沒有辦法可以直接給出最新的結果V1，這個時候該怎麼辦呢？
這個時候無法兩種方法，一種是将錯就錯，将錯誤的V0資料傳回給使用者。第二種是阻塞等待，等待網絡通信恢複，N2中的資料更新之後再傳回給使用者。顯然前者犧牲了一緻性，後者犧牲了可用性。
這個例子雖然簡單，但是說明的内容卻很重要。在分布式系統當中，CAP三個特性我們是無法同時滿足的，必然要舍棄一個。三者舍棄一個，顯然排列組合一共有三種可能。
1. 舍棄A，保留CP
一個系統保證了一緻性和分區容錯性，舍棄可用性。也就是說在極端情況下，允許出現系統無法通路的情況出現，這個時候往往會犧牲使用者體驗，讓使用者保持等待，一直到系統資料一緻了之後，再恢複服務。
對于有些系統而言，一緻性是安身立命之本，比如Hbase、Redis這種分布式存儲，資料一緻性是最基本的要求。不滿足一緻性的存儲顯然不會有使用者願意使用。
ZooKeeper也是一樣，任何時候通路ZK都可以獲得一緻性的結果。它的職責就是保證管轄下的服務保持同步和一緻，顯然不可能放棄一緻性。但是在極端情況下，ZK可能會丢棄調一些請求，消費者需要重新請求才能獲得結果。
2. 舍棄C，保留AP
這種是大部分的分布式系統的設計，保證高可用和分區容錯，但是會犧牲一緻性。比如淘寶購物以及12306購票等等，前面說過淘寶可以做到全年可用性5個9的超進階别，但是此時就無法保證資料一緻性了。
舉個例子，我們在12306買票的時候就經常會遇到。在我們點選購買的時候，系統并沒有提示沒票。等我們輸入了驗證碼，付款的時候才會告知，已經沒有票了。這就是因為我們在點選購買的時候，資料沒有達成一緻性，在付款校驗的時候才檢驗出餘票不足。這種設計會犧牲一些使用者體驗，但是可以保證高可用，讓使用者不至于無法通路或者是長時間等待，也算是一種取舍吧。
3. 舍棄P，保留CA