從分佈式一致性談到CAP理論、BASE理論

問題的提出

在計算機科學領域，分佈式一致性是一個至關重要且被普遍探索與論證問題，首先來看三種業務場景。

一、火車站售票

假如說咱們的終端用戶是一位常常坐火車的旅行家，一般他是去車站的售票處購買車票，而後拿着車票去檢票口，再坐上火車，開始一段美好的旅行----一切彷佛都是那麼和諧。想象一下，若是他選擇的目的地是杭州，而某一趟開往杭州的火車只剩下最後一張車票，可能在同一時刻，不一樣售票窗口的另外一位乘客也購買了同一張車票。假如說售票系統沒有進行一致性的保障，兩人都購票成功了。而在檢票口檢票的時候，其中一位乘客會被告知他的車票無效----固然，現代的中國鐵路售票系統已經不多出現這樣的問題了。但在這個例子中咱們能夠看出，終端用戶對於系統的需求很是簡單：

"請售票給我，若是沒有餘票了，請在售票的時候就告訴我票是無效的"

這就對購票系統提出了嚴格的一致性要求----系統的數據（本例中指的就是那趟開往杭州的火車的餘票數）不管在哪一個售票窗口，每時每刻都必須是準確無誤的！

二、銀行轉帳

假如咱們的終端用戶是一位剛畢業的大學生，一般在拿到第一個月工資的時候，都會選擇向家裏匯款。當他來到銀行櫃檯，完成轉帳操做後，銀行的櫃檯服務員會友善地提醒他："您的轉帳將在N個工做往後到帳！"。此時這名畢業生有必定的沮喪，會對那名櫃檯服務員叮囑："好吧，多久不要緊，錢不要少就行了！"----這也成爲了幾乎全部用戶對於現代銀行系統最基本的需求

三、網上購物

假如說咱們的終端用戶是一位網購達人，當他看見一件庫存量爲5的心儀商品，會迅速地確認購買，寫下收貨地址，而後下單----然而，在下單的那個瞬間，系統可能會告知該用戶："庫存量不足！"。此時絕大部分消費者都會抱怨本身動做太慢，使得心愛的商品被其餘人搶走了。

但其實有過網購系統開發經驗的工程師必定明白，在商品詳情頁上顯示的那個庫存量，一般不是該商品的真實庫存量，只有在真正下單購買的時候，系統纔會檢查該商品的真實庫存量。可是，誰在乎呢？

 

問題的解讀

對於上面三個例子，相信你們必定看出來了，咱們的終端用戶在使用不一樣的計算機產品時對於數據一致性的需求是不同的：

一、有些系統，既要快速地響應用戶，同時還要保證系統的數據對於任意客戶端都是真實可靠的，就像火車站售票系統

二、有些系統，須要爲用戶保證絕對可靠的數據安全，雖然在數據一致性上存在延時，但最終務必保證嚴格的一致性，就像銀行的轉帳系統

三、有些系統，雖然向用戶展現了一些能夠說是"錯誤"的數據，可是在整個系統使用過程當中，必定會在某一個流程上對系統數據進行準確無誤的檢查，從而避免用戶發生沒必要要的損失，就像網購系統

 

分佈一致性的提出

在分佈式系統中要解決的一個重要問題就是數據的複製。在咱們的平常開發經驗中，相信不少開發人員都遇到過這樣的問題：假設客戶端C1將系統中的一個值K由V1更新爲V2，但客戶端C2沒法當即讀取到K的最新值，須要在一段時間以後才能讀取到。這很正常，由於數據庫複製之間存在延時。

分佈式系統對於數據的複製需求通常都來自於如下兩個緣由：

一、爲了增長系統的可用性，以防止單點故障引發的系統不可用

二、提升系統的總體性能，經過負載均衡技術，可以讓分佈在不一樣地方的數據副本都可以爲用戶提供服務

數據複製在可用性和性能方面給分佈式系統帶來的巨大好處是不言而喻的，然而數據複製所帶來的一致性挑戰，也是每個系統研發人員不得不面對的。

所謂分佈一致性問題，是指在分佈式環境中引入數據複製機制以後，不一樣數據節點之間可能出現的，並沒有法依靠計算機應用程序自身解決的數據不一致的狀況。簡單講，數據一致性就是指在對一個副本數據進行更新的時候，必須確保也可以更新其餘的副本，不然不一樣副本之間的數據將不一致。

那麼如何解決這個問題？一種思路是"既然是因爲延時動做引發的問題，那我能夠將寫入的動做阻塞，直到數據複製完成後，才完成寫入動做"。沒錯，這彷佛能解決問題，並且有一些系統的架構也確實直接使用了這個思路。但這個思路在解決一致性問題的同時，又帶來了新的問題：寫入的性能。若是你的應用場景有很是多的寫請求，那麼使用這個思路以後，後續的寫請求都將會阻塞在前一個請求的寫操做上，致使系統總體性能急劇降低。

總得來講，咱們沒法找到一種可以知足分佈式系統全部系統屬性的分佈式一致性解決方案。所以，如何既保證數據的一致性，同時又不影響系統運行的性能，是每個分佈式系統都須要重點考慮和權衡的。因而，一致性級別由此誕生：

一、強一致性

這種一致性級別是最符合用戶直覺的，它要求系統寫入什麼，讀出來的也會是什麼，用戶體驗好，但實現起來每每對系統的性能影響大

二、弱一致性

這種一致性級別約束了系統在寫入成功後，不承諾當即能夠讀到寫入的值，也不久承諾多久以後數據可以達到一致，但會盡量地保證到某個時間級別（好比秒級別）後，數據可以達到一致狀態

三、最終一致性

最終一致性是弱一致性的一個特例，系統會保證在必定時間內，可以達到一個數據一致的狀態。這裏之因此將最終一致性單獨提出來，是由於它是弱一致性中很是推崇的一種一致性模型，也是業界在大型分佈式系統的數據一致性上比較推崇的模型

 

分佈式環境的各類問題

分佈式系統體系結構從其出現之初就伴隨着諸多的難題和挑戰：

一、通訊異常

從集中式向分佈式演變的過程當中，必然引入網絡因素，因爲網絡自己的不可靠性，所以也引入了額外的問題。分佈式系統須要在各個節點之間進行網絡通訊，所以每次網絡通訊都會伴隨着網絡不可用的風險，網絡光纖、路由器或是DNS等硬件設備或是系統不可用都會致使最終分佈式系統沒法順利完成一次網絡通訊。另外，即便分佈式系統各個節點之間的網絡通訊可以正常進行，其延時也會大於單機操做。一般咱們認爲現代計算機體系結構中，單機內存訪問的延時在納秒數量級（一般是10ns），而正常的一次網絡通訊的延遲在0.1~1ms左右（至關於內存訪問延時的105倍），如此巨大的延時差異，也會影響到消息的收發過程，所以消息丟失和消息延遲變得很是廣泛

二、網絡分區

當網絡因爲發生異常狀況，致使分佈式系統中部分節點之間的網絡延時不斷增大，最終致使組成分佈式系統的全部節點中，只有部分節點之間可以正常通訊，而另外一些節點則不能----咱們將這個現象稱爲網絡分區。當網絡分區出現時，分佈式系統會出現局部小集羣，在極端狀況下，這些局部小集羣會獨立完成本來須要整個分佈式系統才能完成的功能，包括對數據的事物處理，這就對分佈式一致性提出了很是大的挑戰

三、三態

上面兩點，咱們已經瞭解到在分佈式環境下，網絡可能會出現各式各樣的問題，所以分佈式系統的每一次請求與響應，存在特有的三態概念，即成功、失敗、超時。在傳統的單機系統中，應用程序在調用一個函數以後，可以獲得一個很是明確的響應：成功或失敗。而在分佈式系統中，因爲網絡是不可靠的，雖然在絕大部分狀況下，網絡通訊也可以接受到成功或失敗的響應，當時當網絡出現異常的狀況下，就可能會出現超時現象，一般有如下兩種狀況：

（1）因爲網絡緣由，該請求並無被成功地發送到接收方，而是在發送過程當中就發生了消息丟失現象

（2）該請求成功地被接收方接收後，進行了處理，可是在將響應反饋給發送方的過程當中，發生了消息丟失現象

當出現這樣的超時現象時，網絡通訊的發起方是沒法肯定當前請求是否被成功處理的

四、節點故障

節點故障則是分佈式環境下另外一個比較常見的問題，指的是組成分佈式系統的服務器節點出現的宕機或"僵死"現象，一般根據經驗來講，每一個節點都有可能出現故障，而且天天都在發生

 

分佈式事物

隨着分佈式計算的發展，事物在分佈式計算領域也獲得了普遍的應用。在單機數據庫中，咱們很容易可以實現一套知足ACID特性的事物處理系統，但在分佈式數據庫中，數據分散在各臺不一樣的機器上，如何對這些數據進行分佈式的事物處理具備很是大的挑戰。

分佈式事物是指事物的參與者、支持事物的服務器、資源服務器以及事物管理器分別位於分佈式系統的不一樣節點上，一般一個分佈式事物中會涉及對多個數據源或業務系統的操做。

能夠設想一個最典型的分佈式事物場景：一個跨銀行的轉帳操做涉及調用兩個異地的銀行服務，其中一個是本地銀行提供的取款服務，另外一個則是目標銀行提供的存款服務，這兩個服務自己是無狀態而且相互獨立的，共同構成了一個完整的分佈式事物。若是從本地銀行取款成功，可是由於某種緣由存款服務失敗了，那麼就必須回滾到取款以前的狀態，不然用戶可能會發現本身的錢不知去向了。

從這個例子能夠看到，一個分佈式事務能夠看作是多個分佈式的操做序列組成的，例如上面例子的取款服務和存款服務，一般能夠把這一系列分佈式的操做序列稱爲子事物。所以，分佈式事務也能夠被定義爲一種嵌套型的事物，同時也就具備了ACID事物特性。但因爲在分佈式事務中，各個子事物的執行是分佈式的，所以要實現一種可以保證ACID特性的分佈式事物處理系統就顯得格外複雜。

 

CAP理論

一個經典的分佈式系統理論。CAP理論告訴咱們：一個分佈式系統不可能同時知足一致性（C：Consistency）、可用性（A：Availability）和分區容錯性（P：Partition tolerance）這三個基本需求，最多隻能同時知足其中兩項。

一、一致性

在分佈式環境下，一致性是指數據在多個副本之間可否保持一致的特性。在一致性的需求下，當一個系統在數據一致的狀態下執行更新操做後，應該保證系統的數據仍然處於一直的狀態。

對於一個將數據副本分佈在不一樣分佈式節點上的系統來講，若是對第一個節點的數據進行了更新操做而且更新成功後，卻沒有使得第二個節點上的數據獲得相應的更新，因而在對第二個節點的數據進行讀取操做時，獲取的依然是老數據（或稱爲髒數據），這就是典型的分佈式數據不一致的狀況。在分佈式系統中，若是可以作到針對一個數據項的更新操做執行成功後，全部的用戶均可以讀取到其最新的值，那麼這樣的系統就被認爲具備強一致性

二、可用性

可用性是指系統提供的服務必須一直處於可用的狀態，對於用戶的每個操做請求老是可以在有限的時間內返回結果。這裏的重點是"有限時間內"和"返回結果"。

"有限時間內"是指，對於用戶的一個操做請求，系統必須可以在指定的時間內返回對應的處理結果，若是超過了這個時間範圍，那麼系統就被認爲是不可用的。另外，"有限的時間內"是指系統設計之初就設計好的運行指標，一般不一樣系統之間有很大的不一樣，不管如何，對於用戶請求，系統必須存在一個合理的響應時間，不然用戶便會對系統感到失望。

"返回結果"是可用性的另外一個很是重要的指標，它要求系統在完成對用戶請求的處理後，返回一個正常的響應結果。正常的響應結果一般可以明確地反映出隊請求的處理結果，即成功或失敗，而不是一個讓用戶感到困惑的返回結果。

三、分區容錯性

分區容錯性約束了一個分佈式系統具備以下特性：分佈式系統在遇到任何網絡分區故障的時候，仍然須要可以保證對外提供知足一致性和可用性的服務，除非是整個網絡環境都發生了故障。

網絡分區是指在分佈式系統中，不一樣的節點分佈在不一樣的子網絡（機房或異地網絡）中，因爲一些特殊的緣由致使這些子網絡出現網絡不連通的情況，但各個子網絡的內部網絡是正常的，從而致使整個系統的網絡環境被切分紅了若干個孤立的區域。須要注意的是，組成一個分佈式系統的每一個節點的加入與退出均可以看做是一個特殊的網絡分區。

既然一個分佈式系統沒法同時知足一致性、可用性、分區容錯性三個特色，因此咱們就須要拋棄同樣：

用一張表格說明一下：

選    擇	說    明
CA	放棄分區容錯性，增強一致性和可用性，其實就是傳統的單機數據庫的選擇
AP	放棄一致性（這裏說的一致性是強一致性），追求分區容錯性和可用性，這是不少分佈式系統設計時的選擇，例如不少NoSQL系統就是如此
CP	放棄可用性，追求一致性和分區容錯性，基本不會選擇，網絡問題會直接讓整個系統不可用

須要明確的一點是，對於一個分佈式系統而言，分區容錯性是一個最基本的要求。由於既然是一個分佈式系統，那麼分佈式系統中的組件必然須要被部署到不一樣的節點，不然也就無所謂分佈式系統了，所以必然出現子網絡。而對於分佈式系統而言，網絡問題又是一個一定會出現的異常狀況，所以分區容錯性也就成爲了一個分佈式系統必然須要面對和解決的問題。所以系統架構師每每須要把精力花在如何根據業務特色在C（一致性）和A（可用性）之間尋求平衡。

 

BASE理論

BASE是Basically Available（基本可用）、Soft state（軟狀態）和Eventually consistent（最終一致性）三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分佈式實踐的總結，是基於CAP定理逐步演化而來的。BASE理論的核心思想是：即便沒法作到強一致性，但每一個應用均可以根據自身業務特色，採用適當的方式來使系統達到最終一致性。接下來看一下BASE中的三要素：

一、基本可用

基本可用是指分佈式系統在出現不可預知故障的時候，容許損失部分可用性----注意，這毫不等價於系統不可用。好比：

（1）響應時間上的損失。正常狀況下，一個在線搜索引擎須要在0.5秒以內返回給用戶相應的查詢結果，但因爲出現故障，查詢結果的響應時間增長了1~2秒

（2）系統功能上的損失：正常狀況下，在一個電子商務網站上進行購物的時候，消費者幾乎可以順利完成每一筆訂單，可是在一些節日大促購物高峯的時候，因爲消費者的購物行爲激增，爲了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面

二、軟狀態

軟狀態指容許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的總體可用性，即容許系統在不一樣節點的數據副本之間進行數據同步的過程存在延時

三、最終一致性

最終一致性強調的是全部的數據副本，在通過一段時間的同步以後，最終都可以達到一個一致的狀態。所以，最終一致性的本質是須要系統保證最終數據可以達到一致，而不須要實時保證系統數據的強一致性。

總的來講，BASE理論面向的是大型高可用可擴展的分佈式系統，和傳統的事物ACID特性是相反的，它徹底不一樣於ACID的強一致性模型，而是經過犧牲強一致性來得到可用性，並容許數據在一段時間內是不一致的，但最終達到一致狀態。但同時，在實際的分佈式場景中，不一樣業務單元和組件對數據一致性的要求是不一樣的，所以在具體的分佈式系統架構設計過程當中，ACID特性和BASE理論每每又會結合在一塊兒。