分布式CAP理论：为什么CAP理论中的三个指标不能同时满足呢？
文章目錄
- 前言
- 分布式系統(tǒng)的特點
- 分布式系統(tǒng)技術(shù)是用來解決什么問題的呢？
- CAP代表什么含義
- 一致性（Consistency）
- 可用性（Availability）
- 分區(qū)容錯性（Partition Tolerance）
- CAP理論的證明
- CAP理論的應(yīng)用
- CP和AP架構(gòu)的取舍
- CP架構(gòu)：放棄可用性，追求一致性和分區(qū)容錯性
- AP架構(gòu)：放棄強(qiáng)一致性，追求分區(qū)容錯性和可用性
- 結(jié)語
前言
為什么CAP理論中的三個指標(biāo)不能同時滿足呢？春暖花開、鳥語花香，莫要虛度這明媚的春天，一起學(xué)一學(xué)分布式CAP理論吧~本文主要會對以下問題進(jìn)行介紹：
- 分布式系統(tǒng)有什么特點？
- CAP理論的含義是什么？
- 為什么CAP三者不能同時滿足？
- CAP理論怎么應(yīng)用？
（若文章有不正之處，或難以理解的地方，請多多諒解，歡迎指正）
分布式系統(tǒng)的特點
對于分布式系統(tǒng)最簡單的理解，就是一組計算機(jī)工作，但最終以一臺計算機(jī)的用戶身份顯示。簡單說，就是由多個不同業(yè)務(wù)的子系統(tǒng)，共同組成在用戶眼中就是一個系統(tǒng)的模式。但這些機(jī)器具有共享狀態(tài)，并不會因其中一個系統(tǒng)節(jié)點故障而影響整個系統(tǒng)。
分布式系統(tǒng)技術(shù)是用來解決什么問題的呢？
分布式系統(tǒng)技術(shù)是用來解決集中式架構(gòu)的性能瓶頸問題，其核心是可擴(kuò)展性。舉個簡單的栗子：
假如有個大學(xué)生想做一個XX校園系統(tǒng)，這時他需要對于系統(tǒng)的數(shù)據(jù)存儲配置只有一個數(shù)據(jù)庫，也就是說，服務(wù)器與數(shù)據(jù)庫之間的交互是實時且一對一的：
然而這個XX校園系統(tǒng)在版本更新的路上披荊斬棘，從雞肋Demo系統(tǒng)升級到全省高校都在使用的校園系統(tǒng)，這時如果還將數(shù)據(jù)放在同一個數(shù)據(jù)庫或者數(shù)據(jù)表中，會在查詢過程中消耗過多的時間，使得響應(yīng)時間過長，導(dǎo)致用戶體驗不良，所以進(jìn)行了分庫操作：
假如依照用戶的名稱來進(jìn)行分庫，服務(wù)器需要通過代理服務(wù)器選定訪問數(shù)據(jù)庫。在這里，就需要兩個系統(tǒng)來進(jìn)行向數(shù)據(jù)庫請求數(shù)據(jù)的操作。
所以，分布式系統(tǒng)是通過對服務(wù)、存儲的擴(kuò)展，來提高系統(tǒng)的處理能力。通過對多臺服務(wù)器協(xié)同工作，來完成單臺服務(wù)器無法處理的任務(wù)，如高并發(fā)或大數(shù)據(jù)量的任務(wù)。
因為分布式系統(tǒng)的復(fù)雜性，也可能會出現(xiàn)結(jié)點之間通信失敗，網(wǎng)絡(luò)分區(qū)失敗、數(shù)據(jù)不一致等問題。所以分布式系統(tǒng)也可能出現(xiàn)對單點故障、無狀態(tài)的需要。
-
單點故障
一般在系統(tǒng)中某個組件一旦失效，整個系統(tǒng)就無法工作了，為了避免這種情況，往往會將單點故障作為分布式系統(tǒng)的設(shè)計目標(biāo)之一，因為單點故障，意味著單點不影響整體。
-
無狀態(tài)
服務(wù)的無狀態(tài)，是為了滿足部分機(jī)器宕機(jī)也不影響全部，可用于隨時進(jìn)行擴(kuò)展的需求。
那么在設(shè)計分布式系統(tǒng)時需要什么理論作為指導(dǎo)思想呢？這時，讓我們掌聲歡迎CAP理論出場！
CAP代表什么含義
CAP分別是指一致性（Consistency）、可用性（Availablity）、分區(qū)容忍性（Partition Tolerance），一般分布式系統(tǒng)只能滿足其三項中的兩項。
一致性（Consistency）
一致性是指“所有節(jié)點同時看到相同的數(shù)據(jù)”，也就是說在更新操作成功并返回到客戶端后，所有節(jié)點在同一時間的數(shù)據(jù)完全一致，所有節(jié)點所擁有的數(shù)據(jù)都是最新版本。
可用性（Availability）
可用性指的是“任何時候，讀寫都是成功的”，即服務(wù)一直可用，而且響應(yīng)時間在正常范圍內(nèi)。比如系統(tǒng)穩(wěn)定性到了3個9、4個9，即99.9%、99.99%。
這里的N個9對應(yīng)的就是對可用性的一種描述，叫做SLA，即服務(wù)水平協(xié)議。
分區(qū)容錯性（Partition Tolerance）
分區(qū)容錯性是指“當(dāng)部分結(jié)點出現(xiàn)消息丟失，或分區(qū)故障時，分布式系統(tǒng)仍然能夠繼續(xù)運(yùn)行”，即系統(tǒng)容忍網(wǎng)絡(luò)出現(xiàn)分區(qū)，且在遇到某個結(jié)點或網(wǎng)絡(luò)分區(qū)之間出現(xiàn)不可達(dá)的情況下，仍然能夠?qū)ν馓峁M足一致性和可用性的服務(wù)。
在分布式系統(tǒng)中，P的滿足是基本要素，一般是在CP或AP中進(jìn)行選擇，實現(xiàn)更好的C或者提升A的性能。
那么CAP理論中的一致性、可用性和分區(qū)容忍性不能同時滿足呢？
CAP理論的證明
為什么CAP不能同時滿足呢？
下面可以通過反證法來證明。
假如有一個實際場景，CAP三者都可以同時滿足。由于允許P的存在，則一定存在服務(wù)器（Server）之間的丟包，如此則不能保證C。
所以這里，可以對CAP的定義有更加明確的聲明：
-
一致性（Consistence）
一致性被稱為原子對象，任何的讀寫都應(yīng)該看起來像是“原子”的，或串行的。
寫入數(shù)據(jù)庫后讀取數(shù)據(jù)，一定能讀到前面寫的內(nèi)容，所有的讀寫請求都像是全局排序依次進(jìn)行。
-
可用性（Availability）
對任何非失敗節(jié)點都應(yīng)該在有限的時間內(nèi)給出請求的回應(yīng)（請求的可中止性）。
-
分區(qū)容錯性（Partition Tolerance）
允許節(jié)點之間丟失任意多的消息，當(dāng)網(wǎng)絡(luò)分區(qū)發(fā)生時，節(jié)點之間的消息可能會完全丟失。
CAP理論的應(yīng)用
CP和AP架構(gòu)的取舍
其實在實際工程中，可用性和一致性并不是完全對立的，我們往往關(guān)注的是如何在保持相對一致性的前提下，提高系統(tǒng)的可用性。
至于是使用CP或者AP架構(gòu)，則取決于業(yè)務(wù)對一致性的要求。
CP架構(gòu)：放棄可用性，追求一致性和分區(qū)容錯性
舉個栗子，ZooKeeper就是采用了CP一致性。
ZooKeeper是一個分布式的服務(wù)框架，主要用來解決分布式集群中應(yīng)用系統(tǒng)的協(xié)調(diào)和移置性問題。在ZooKeeper中，對應(yīng)每一個事務(wù)操作請求，ZooKeeper都會為其分配一個全局唯一的事務(wù)ID，每個事務(wù)ID對應(yīng)一次更新操作，從這些事務(wù)ID中可以間接識別出ZooKeeper處理這些事務(wù)操作請求的全局順序。
AP架構(gòu)：放棄強(qiáng)一致性，追求分區(qū)容錯性和可用性
舉個栗子，Eureka就采用了AP可用性。
Eureka是Spring Cloud微服務(wù)技術(shù)棧中的服務(wù)發(fā)現(xiàn)組件。
Eureka的各個節(jié)點都是平等的，幾個節(jié)點掛掉不影響正常節(jié)點的工作。剩余節(jié)點依然可以提供注冊和查詢服務(wù)，只要有一臺Eureka在，就能保證注冊服務(wù)可用。只不過查看的信息可能不是最新版本，不保證一致性。
總結(jié)
以上是生活随笔為你收集整理的分布式CAP理论：为什么CAP理论中的三个指标不能同时满足呢？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 数字签名、数字证书、对称加密算法、非对称
- 下一篇： 什么是51%算力攻击？——区块链系列学习