分佈式系統CAP和Base

一、分佈式系統

1.1 簡介

    由多臺計算機和通訊的軟件組件經過計算機網絡鏈接（本地網絡或廣域網）組成。分佈式系統是創建在網絡之上的軟件系統。正是由於軟件的特性，因此分佈式系統具備高度的內聚性和透明性。所以，網絡和分佈式系統之間的區別更多的在於高層軟件（特別是操做系統），而不是硬件。分佈式系統能夠應用在在不一樣的平臺上如：Pc、工做站、局域網和廣域網上等。

1.2 分佈式系統和集羣

    分佈式：每一個服務節點上面部署不一樣的服務模塊（工程），他們之間經過Rpc/Rmi之間通訊和調用，對外提供服務和組內協做。

    集羣：不一樣的多臺服務器上面部署相同的服務模塊，經過分佈式調度軟件進行統一的調度，對外提供服務和訪問。

二、CAP和Base

2.1 CAP理論

    CAP指的是：一致性（C）Consistency、可用性（A）Avaliability、分區容錯性（P）Partition tolerance。這是分佈式系統中著名的CAP定理。這三個特性在任何分佈式系統中不能同時知足，最多同時知足兩個。

2.1.1 一致性

   即更新操做成功並返回客戶端完成後，全部節點在同一時間的數據徹底一致。

2.1.2 可用性

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

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

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

2.1.3 分區容錯性

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

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

2.1.4 取捨

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

用一張表格說明一下：

選    擇	說    明
CA	若是但願可以避免系統出現分區容錯性問題，一種較爲簡單的作法是將全部的數據（或者僅僅是哪些與事 務相關的數據）都放在一個分佈式節點上。這樣作雖然沒法100%保證系統不會出錯，但至少不會碰到由 於網絡分區帶來的負面影響。但同時須要注意的是，放棄P的同時也就意味着放棄了系統的可擴展性
AP	這裏所說的放棄一致性，實際上指的是放棄數據的強一致性，而保留數據的最終一致性。這樣的系統沒法 保證數據保持實時的一致性，可是可以承諾的是，數據最終會達到一個一致的狀態。
CP	一旦系統遇到網絡分區或其餘故障或爲了保證一致性時，放棄可用性，那麼受到影響的服務須要等待必定 的時間，所以在等待期間系統沒法對外提供正常的服務，即不可用

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

 

2.1.5 示例：

2.1.5.1 CA

      假設DB的更新操做是同時寫北京和廣州的DB都成功才返回成功
      在沒有出現網絡故障的時候，知足CA原則，C 即個人任何一個寫入，更新操做成功並返回客戶端完成後,分佈式的全部節點在同一時間的數據徹底一致， A 即個人讀寫操做都可以成功，可是當出現網絡故障時，我不能同時保證CA，即P條件沒法知足

 2.1.5.2 AP 

      假設DB的更新操做是隻寫本地機房成功就返回，經過binlog/oplog回放方式同步至側邊機房
      這種操做保證了在出現網絡故障時,雙邊機房都是能夠提供服務的，且讀寫操做都能成功，意味着他知足了AP ，可是它不知足C，由於更新操做返回成功後，雙邊機房的DB看到的數據會存在短暫不一致，且在網絡故障時，不一致的時間差會很大（僅能保證最終一致性）

2.1.5.3 CP
      假設DB的更新操做是同時寫北京和廣州的DB都成功才返回成功且網絡故障時提供降級服務
      降級服務，如中止寫入，只提供讀取功能，這樣能保證數據是一致的，且網絡故障時能提供服務，知足CP原則，可是他沒法知足可用性原則

2.2 BASE理論

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

2.2.1 基本可用

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

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

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

 

2.2.2 軟狀態

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

2.2.3 最終一致性

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

2.2.3 總結

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