前言
CAP和BASE算是耳熟能詳的名字了吧，本篇文章中，想結合自己已有的億點點實踐經歷，談談自身的理解。
CAP
CAP的英文名和中文名如下：
- Consistency：一致性
- Availability：可用性
- Partition Tolerance：分區容錯性（分區容忍性）
![在這裏插入圖片描述]()
一致性
場景
個人覺得在不同的場景下，關於一致性的理解是各種各樣的。在數據操作方面的一致性，可以理解爲數據的變化情況和單線程的場景下的變化情況應該保持一致。如：網上電影售票時，不能出現一張票賣給了多個人，即出現漏減的情況。
在事務方面的一致性（即ACID中的C）可以理解爲“目標”上的一致性，譬如，一次A轉賬給B100元的過程，目標是A的賬戶扣100，B的賬戶增100，這個“目標”要麼達成，要麼不達成，不能只完成一半。（爲了防止扁桃體同學擡槓，這裏強調不是在事務過程中）是不是覺得很像原子性，當然了，原子性只是保證事務一致性的手段之一。
在數據存儲方面（這裏指數據分佈在服務器集羣中），一致性可以指數據在多臺服務器上分佈協調，如一致性哈希算法就可以解決這個問題，也可以多個指同步數據的副本的數據一致，例如我們的elasticsearch，在客戶端發起數據更新請求後，可以讓所有副本分片同步更新後才讓協調節點返回成功。
分類
儘管不同場景下的一致性理解稍微有些不同，但它卻有着與之對應的模型。這裏只說了比較爛大街的強一致性、弱一致性、最終一致性。
對了，這裏還要再扯一下，一致性實現的算法很多，像很多人張口就來什麼Paxos、Raft什麼的。其實，這些個算法從英文翻譯過來時，叫做共識算法比較好理解一些。這些個算法，大都假設存在拜占庭問題，在此背景下，讓分佈式下的多個節點的投票可以達成共識。
而我們這裏通常所說的一致性，大都指這麼個情況，爲了保證容錯性，我們通常會用多個副本來同步主節點的數據，如何讓數據在副本和主節點上保持一致性的問題。
-
強一致性（線性一致性）
CAP中的C就是強一致性，按百科的描述就是，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的數據副本）。在實際運用中，關於強一致性的實現一般都很難真正的實現。這也不難解釋，有些中間件會在主節點選舉時，容易造成腦裂問題。而強一致性的情況下，是不應該出現這個問題的。 -
弱一致性
分佈式下，弱一致性指產生數據後，不需要所有節點就立刻都看到，但不同不同的節點看到這些新數據時需要按照它們處理時的順序。譬如A、B、C三個節點，A上產生新數據，依次同步到B、C，不能說同步給B時，還沒到C，C就能看到了。 -
最終一致性
這個下面分析base時說。
可用性
可用性指在集羣中一部分節點故障後，集羣整體是否還能響應客戶端的讀寫請求能力。（對數據更新具備高可用性）。
可用性，範圍說小一點，譬如只單節點可用性，我們可以考慮是否可以啓動多個服務，掛載不同的磁盤，進行僞負載均衡，防止某個盤掛了，服務就不可用了。當訪問的數量量上來後，這是我們就需要考慮集羣的方案了。這時，用戶的訪問量由多臺集羣進行負載，考慮到訪問量還是可能超過集羣限制，我們又得增加一些限流或者熔斷措施。考慮到某個服務掛了之後，程序需要自動切換到另一臺服務，此時就引入服務註冊與發現中心。
分區容錯性
分區容錯性可以理解爲當存在網絡分區時（另個子系統之間的網絡不可達），系統仍可繼續運行的能力。在分區恢復後，保證分區容限的分佈式系統還可以從分區正常恢復。
看了一些文章，目前分區容錯性也可以理解爲系統對節點動態加入和離開的處理能力，因爲節點的加入和離開可以認爲是集羣內部的網絡分區。
BASE
BASE比CAP放寬了條件，放棄了CAP理論的C（強一致性），強調最終一致性。基本可用來表明可用性。
BASE：全稱：
- Basically Available(基本可用)
- Soft state（軟狀態）
- Eventually consistent（最終一致性）
基本可用
基本可用是指分佈式系統在出現不可預知的故障的時候，允許系損失部分可用性。最常見的，雙11淘寶在遇到大流量的購買操作後，此時，用戶繼續購買時，會跳轉到一個引導頁。從而保證其他服務的正常運行。
軟狀態
軟狀態表示即使沒有輸入，系統的狀態也可能隨時間變化。這個軟狀態又指中間狀態，數據同步過程可以存在一定的延遲。譬如我們Kafka中的ISR伸縮，它表示follower副本同步leader節點需要的延時差，這個是允許存在的。
最終一致性
最終一致性強調的是系統中所有的數據副本，在經過一段時間的同步後（軟狀態），最終能夠達到一個一致的狀態。
總結
個人認爲，BASE是CAP的一個拓展，結合實際運用場景，放寬了條件。其中，CAP的C指待的是強一致性，而BASE的E指的是最終一致性。CAP的A只的是可用性，而BASE的B強調的是基本可用。
另外，CAP的精髓在於一個分佈式系統不可能同時滿足這三點，一致性、可用性、分區容錯性。如果強調CA（一致性和可用區），需要犧牲P（分區容錯性）
CA
基於CA的設計不能滿足P，由於C追求強一致性，一般就沒有了多個數據副本了，只有一個的數據副本滿足了強一致的需求，最常見於單節點系統，此時遇到不可預知的錯誤，服務器它完犢子了，哦吼，系統不能訪問了，不具備分區容錯性。
CP
基於CP的設計（zookeeper，話說zookeeper的一致性應該是弱一致性，不能歸類爲CAP中的C纔對，非要歸類，也應該是Eventually consistent），犧牲了A（可用性）。在分區出現故障後，不斷通過重試來恢復，這個期間的可用性無法滿足。
AP
基於AP的設計（Eureka），犧牲了C（一致性）。分區（P）越來越多，可以理解爲備胎越來越多，爲了不給他們湊在一起打麻將的機會，我們需要犧牲掉C（一致性），即信息在多個分區間的同步具有延時性的特點。