CAP理論是討論分布式系統設計優劣時的老生常談，最近學習極客時間上周志明的軟件架構課，對幾個之前以為通透了的理論進行了重新理解與消化，并對過去的錯誤考慮進行了勘誤，有必要重新梳理下。

CAP理論是我接觸分布式設計過程中最初遇到的理論之一，最初去了解相關理論的出發點是為了做職級晉升答辯。不同于日常業務開發的關注點為系統的快速設計與落地，答辯更關注對具體問題的思考是否足夠科學，推理是否縝密，能否契合具體的業務場景，用相對靜態的理論來承接場景。可以說一開始是很不適應的，又經過了1、2年，走到了另一個極端，各種名詞不離口（可用性、一致性、性能、安全性、ACID、BASE、魯棒），但并沒有真正的指導開發，也就是說一套做一套，更甚者說了不做，先做再往理論上靠的懶惰行為也有。19、20年以來逐漸找到了以解決問題為導向，行動符合科學理論的感覺，也就是摸索知行合一。

CAP（帽子）理論，2000年eric brewer提出，2002年由2位數學家證實的理論，即沒有任何分布式存儲系統可以同時滿足一致性、可用性與分區容錯性，而分區容錯性不可避免，設計者需要在一致性與可用性上做好取舍。

可以說任何真理都是相對真理，都要被前提條件約束，而這個約束條件越寬松，那么理論能覆蓋的范圍也就越大，從某種意義上理論的科學價值也更高些。CAP理論生效的大前提是：分布式數據共享系統，解決的問題是：在上述前提下，發生網絡分區時，設計者如何進行取舍（trade off)。

3個字母分別代表：一致性（consistency），可用性（Availability），分區容錯性（Partition Tolerant）。一般到這個時候都要講一下這仨屬性分別是什么，而通常錯誤也會出現在對這3個名詞的定義邊界上。

首先說P：分區容錯性是指在一個分布式系統（一定有2個或以上的node）中，node間因為要通過網絡通信，因此一定會出現node間無法通信的情況，而在以上情況下：a. 系統要可以繼續提供服務；b. 當網絡恢復時，系統也能夠優雅恢復；從當前開發經驗上可以很快得出結論，P在分布式系統里是一定會出現的：網絡鏈路不可靠，node本身也會出現故障，導致從系統層面上看，node之間的網絡通信不可達；

然后說A：在cap理論里的A指的是，在網絡分區發生時，所有的數據節點是否都能提供讀、寫服務，并保證在一個承諾的時間內返回。這里的誤區就是，一說cp模型系統，是不是就可以接受單節點掛掉不可用，實際上cap理論里討論的可用性，并不是我們常見的，站在分布式系統外，觀測整個系統主動停機+被動停機時間的可用性。這個可用性，只關注在發生網絡分區時，我們是否保證每個節點仍舊參與系統功能的讀寫上；

最后說C：這個一致性與ACID里追求的強一致性顯然不是一個東西（所以說命名害死人），cap中的一致性也考慮的是在網絡分區發生時，是否保證集群中每個節點都返回系統中最新成功寫入的數據。個人理解就是，選擇保證返回最實時寫入的數據，而不采用歷史副本。

 

所以從這個角度看，cap理論只能解釋相對小的case，比如某個多node部署的中間件。關注在分區發生時，各節點是直接返回歷史副本保證可用性，還是需要等待集群各節點協商達成一致后再返回數據（通常是選主：paxos，raft）；如果是純吞吐型系統，就別提cap了（比如nginx dns lb集群）；在整個大的框架中談論cap，也并不合適（因為大型系統的復雜度高，在設計過程中會同時應用cp、ap的方案，全局談cap是沒意義的）。

 

因此盤一下常見的cp中間件：zk，etcd，特點是節點存儲的數據在各個節點上讀取一致，在網絡分區情況下，產生腦裂+重新選舉，這時只有持有集群一半以上的子網才能提供服務，其他node無法提供服務。也就是寧可讓客戶端等，也不能給予非當前生效數據；ca考量的中間件多，整體體現為流量思維：MySQL的主從，redis的主從，Kafka等，在高流量系統的中間件中，通常采用歷史數據副本的方式，應對網絡分區->恢復的過程，保持所有node都可用，調用的client端就不會有感知。

額外提一嘴實現ca的系統，這種設計也可以說有，但不在分布式架構討論的范疇里。服務完全共享通信內存，就可以不考慮分區問題，但這也將系統退化為了單點。

 

總結看，cap理論是分布式存儲系統在網絡分區發生時，進行一致性與可用性tradeoff的考量，可以說并不是放在分布式設計世界里到處都能應用的理論。我們經常做的cp、ap選擇，是從業務實際需求出發，沒有單純的優劣可言。而單/部分節點宕機情況下服務的可用性是那種方案下都應保障的， 不要放在cap理論框架下討論。文章條理性不強，但大抵能講明白這個單純的理論，那就有一定的意義吧。