微信搜一搜

架構師修行之路

菜菜哥，幫忙解決一個問題

是不是面試又被虐了？

是的呢，這次面試官問我什么是CAP？

這個可就說來話長了......

01

PART

CAP

說到CAP，首先不能不說分布式系統，前面幾篇也說過，分布式系統的出現，很大的一個原因是要解決單機系統的瓶頸問題，但是工作模式上還需要保證系統的可用性，一致性，性能等。一個分布式系統，網絡不可靠的特性必然存在，這就導致了分布式系統比單機系統要面對更多的不確定因素的挑戰。

CAP是針對分布式系統提出的一個重要理論，在很多開發者眼里被視為金律。CAP理論是對分布式系統特點的一個高度抽象，也是我們設計一個分布式系統很好的參考框架。在CAP理論提出初期，有很多人提出各種質疑，后來CAP之父又再次給CAP理論做出了重要修正。

很多架構師在設計系統的時候都以CAP理論為重要參考依據，其中CAP不可能三角是最重要的指導思想。CAP把一個分布式系統抽象為三個固有屬性：

1. 一致性（Consistency）:客戶端無論訪問系統的哪個節點，要么讀到的數據都是最新的，要么讀取失敗。這本質上是說分布式系統的所有節點上的數據都是實時同步的，一致性強調的是數據正確性。

2. 可用性（Availability）：當系統內任意一個節點發生了故障，非故障的節點仍然能響應客戶端的請求，無論這個響應返回的是最新數據還是舊數據。這個特性可以看做是對客戶端的一個保證：無論何時，我都能給你響應。

3. 分區容錯性（Partition Tolerance）：即使系統內部某個節點有消息丟失或者高延遲，系統仍然能持續提供服務。這個指標強調的是對分布式系統的容錯能力。

分布式系統是由通過網絡通信的多個節點組成，因為系統需要持續對外提供服務，所以分區容錯性（P）是分布式系統必須要保證的。三角理論這個時候就尷尬到只需要從一致性和可用性這兩個指標中選擇一個，所以有人根據這個特點提出：

基于CAP理論的分布式系統，分區容錯是固有而且必須要保證的一個指標，設計分布式系統要根據業務的場景來選擇一致性還是可用性。

02

PART

使用CAP理論設計系統

當我們在設計一個分布式系統的時候，由于分區容錯性必須要保證，所以就演化成了是選擇AP，還是選擇CP指標。

當我們選擇了CP(一致性)的時候，客戶端的每次請求一定會讀取到最新的數據，但是因為消息丟失，節點通信高延遲等原因，被讀取的節點中的數據不一定是最新數據，所以為了保證一致性，這個時候返回給客戶端的是出錯信息，換句話說，這個節點在這個時候是不可用的。

當我們選擇了AP（可用性）的時候，為了始終響應客戶端的請求，哪怕節點上的信息不是最新數據也要給客戶端響應，這個時候客戶端得到的可能是過時的數據。

真實的線上系統環境中，其實還存在另外一個場景：隨著節點的不斷增加，嚴格的一致性會導致系統的響應時間變慢，系統資源消耗的增加，這個時候為了維護強一致性的成本可能要超出我們的預期，在這種情況下，我們就只剩下了一種選擇：更多的選擇可用性，放棄強一致性，采用最終一致性。

退一步說，在分布式系統節點不是很多的情況下，CAP三個指標在一定程度上是可以同時能夠保證的。但是針對分布式數據庫事務領域，后來的專家已經證實并不適用于CAP。

舉一個很簡單的例子：如果要設計一套分布式的日志收集系統改如何選擇呢？俗話說脫離業務的架構就是耍流氓，具體的系統設計還要看每個業務的場景。日志收集的分布式系統很典型的一個特點是：讀少寫多，數據重要性級別低，數據量大，可以容忍部分數據丟失。這樣的場景下，我們可以優先選擇AP，能持續的提供服務比數據一致性要重要很多。

再舉一個簡單例子：每個公司有自己的配置中心，配置中心中可能會存儲分布式系統重要的配置信息，比如：每個節點的IP和端口信息等。在這樣的系統中，客戶端每次讀取配置中心的信息要求必須為最新數據，如果不是最新數據會發生業務錯誤信息，比如一個分布式系統中A節點掛掉了，配置中心中所有的節點數據必須要保證一致（刪除A節點信息），不然的話，客戶端還能讀到A節點的信息，然后去訪問A節點會發生業務異常的。

03

PART

BASE理論

由于CAP原則在只能在AP和CP之間二選一，而且在選擇強一致性的同時會大大犧牲性能，這對于并發和響應時間都有要求的系統都是難以接受的。于是eBay公司嘗試選擇了不同的方案，提出了一套名為BASE的理論。

BASE理論基本思想是犧牲了數據一致性來滿足系統的可用性，在系統發生故障或者部分數據不一致的時候，扔能提供系統“主要可用”。

BASE：全稱：Basically Available(基本可用)，Soft state（軟狀態）,和 Eventually consistent（最終一致性）三個短語的縮寫

BASE理論是對CAP理論的一個延伸，或者說是對AP模型的一個延伸，它是對互聯網大規模分布式系統的一個總結，強調的是可用性。

Basically Available(基本可用)

基本可用不同的系統有不同的解釋，但是總體思想是保證系統大部分可用。

在一個分片的分布式存儲系統中，假設有10個節點來存儲數據，假設其中兩個節點發生故障，那么其他8個節點仍然能提供服務，既：系統的80%仍然可用。

我們平時用的流量削峰策略，其實本質上也是要保證系統的主要可用。服務降級，服務熔斷也是通過犧牲一部分系統的可用性來保證核心功能可用。

以上所說都說明了一個事實：基本可用本質上是一種妥協，在節點出現故障的時候通過犧牲非核心功能的可用性，來保證核心功能的可用性。

Soft state（軟狀態）

對于服務端的系統來說，每個節點或者服務都可以設計為有狀態（stateful）和無狀態（stateless），這在根本上決定了一個分布式系統是否具有良好的擴展性，故障恢復等高級特性。對于完全無狀態的服務來說，具有更好的水平擴展性，而對于有狀態的服務來說，如果要實現水平擴展，可能涉及到狀態的遷移等過程，比較復雜。

基于有狀態和無狀態的思想，BASE理論提出一個介于中間的狀態：soft state：服務端會維護數據的狀態，但是有一個期限，過了這個期限，服務端將會丟棄這些狀態信息，恢復正常的狀態。

Eventually consistent（最終一致性）

最終一致性是指系統在經過一段時間內，每個節點的數據會達到一個一致的狀態，換句話說，它是必須經過一段時間才能達到強一致性的過程。

由于強一致性的缺陷，現在幾乎所有的互聯網系統都是基于最終一致性來設計架構，當然如果最終一致性不滿足業務場景的情況下，才會使用犧牲性能和可用性來采用強一致性。比如在支付的場景中，必須要采用強一致性來設計系統，不然這個鍋是程序員背不起的。

至于如何實現最終一致性，有很多的解決方案，目前最常用的是利用MQ消息來實現，前提是你的MQ需要保證不丟失消息。舉個很簡單的例子：一個典型的電商場景，商品管理系統和訂單系統是兩個物理上隔離的兩個系統，可以看做是兩個微服務，當一個訂單支付成功之后，商品管理系統需要把對應的商品減少庫存，這個過程可以采用最終一致性來設計。當訂單支付成功，發一個mq消息，當商品管理系統接收到這個消息，會把對應商品的庫存扣掉。

04

PART

寫在最后

CAP理論是分布式設計中一個重要的參考指標，但是這個理論并非放之四海而皆準的思想，它的適用場景僅僅在非數據庫系統的原子讀寫。在互聯網高速發展的今天，分布式系統早已不是之前的簡單系統了，架構師在設計系統中還需要考慮安全性，擴展性，自動化等諸多因素，所以現在做程序員多累呀！！

BASE理論繞過了難以實現的分布式強一致性，采用一種權衡的策略來達到業務要求。BASE理論主要針對數據分片場景，讓不同的數據分布在不同的節點，以提升系統的可用性。

END

●程序員修神之路--為什么我會了SOA，你們還要逼我學微服務？

●程序員過關斬將--數據庫的樂觀鎖和悲觀鎖并非真實的鎖

●程序員修神之路--設計一套RPC框架并非易事

●程序員過關斬將--要想獲取我的用戶信息，就得按照規矩來

●程序員過關斬將--更加優雅的Token認證方式JWT

●程序員過關斬將--cookie和session的關系其實很簡單

●程序員修神之路--用NOSql給高并發系統加速

●程序員修神之路--高并發系統設計負載均衡架構

●程序員過關斬將--你為什么還在用存儲過程？

●程序員修神之路--問世間異步為何物？

●程序員修神之路--提高網站的吞吐

長按添加菜菜好友

關注后回復：“大禮包”和“福利”，領取驚喜

點分享

點點贊

點在看

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的程序员修神之路--晦涩难懂的CAP，是否完全正确？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。