文章目錄

• • 一.簡介
  • 二.CAP指標
  • • 2.1 一致性
    • 2.2 可用性
    • 2.3 分區容錯
  • 三.CAP不可能三角
  • 四.CAP理論實例
  • 五.小結

一.簡介

CAP 理論是一個很好的思考框架，它對分布式系統的特性做了高度抽象，比如抽象成了一致性、可用性和分區容錯性，并對特性間的沖突（也就是 CAP 不可能三角）做了總結。一旦掌握它，你就像擁有了引路人，自然而然就能根據業務場景的特點進行權衡，設計出適合的分區容錯一致性模型。

二.CAP指標

CAP理論對分布式系統特性做了高度抽象，形成三個指標：

• 一致性（Consistency）
• 可用性（Availability）
• 分區容錯性（Partition Tolerance）

2.1 一致性

一致性說的是客戶端的每次讀操作，不管訪問哪個節點，要么讀到的都是同一份最新寫入的數據，要么讀取失敗。

示例

2 個節點的 KV 存儲，原始的 KV 記錄為“X = 1”。

緊接著，客戶端向節點1發送寫請求“SET X=2”。

如果節點 1 收到寫請求后，只將節點 1 的 X 值更新為 2，然后返回成功給客戶端。

那么，此時如果客戶端訪問節點 2 執行讀操作，就無法讀到最新寫入的 X 值，這就不滿足一致性了。

如果節點 1 收到寫請求后，通過節點間的通訊，同時將節點 1 和節點 2 的 X 值都更新為 2，然后返回成功給客戶端。

那么在完成寫請求后，不管客戶端訪問哪個節點，讀取到的都是同一份最新寫入的數據，這就叫一致性。

一致性這個指標，描述的是分布式系統非常重要的一個特性，強調的是數據正確。也就是說，對客戶端而言，每次讀都能讀取到最新寫入的數據。

2.2 可用性

可用性說的是任何來自客戶端的請求，不管訪問哪個非故障節點，都能得到響應數據，但不保證是同一份最新數據。你也可以把可用性看作是分布式系統對訪問本系統的客戶端的另外一種承諾：我盡力給你返回數據，不會不響應你，但是我不保證每個節點給你的數據都是最新的。這個指標強調的是服務可用，但不保證數據正確。

2.3 分區容錯

不過集群畢竟不是單機，當發生分區故障的時候，有時不能僅僅因為節點間出現了通訊問題，無法響應最新寫入的數據，之后在客戶端查詢數據時，就一直返回給客戶端出錯信息。

示例

業務集群中的一些關鍵系統，比如名字路由系統（基于 Raft 算法的強一致性系統），如果僅僅因為發生了分區故障，無法響應最新數據（比如不滿足“大多數”，沒有了領導者），為了不破壞一致性，那么客戶端查詢相關路由信息時，系統就一直返回給客戶端出錯信息，此時相關的業務都將因為獲取不到指定路由信息而不可用、癱瘓，這可以說是災難性的故障了。

三.CAP不可能三角

CAP 不可能三角說的是對于一個分布式系統而言，一致性（Consistency）、可用性（Availability）、分區容錯性（Partition Tolerance）3 個指標不可兼得，只能在 3 個指標中選擇 2 個。

CAP 不能三角最初是埃里克·布魯爾（Eric Brewer）基于自己的工程實踐，提出的一個猜想，后被賽斯·吉爾伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）證明，證明過程可以參考論文《Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services》，你記住結論就好了。不過，為了幫你閱讀論文，我補充一點：

• 基于證明嚴謹性的考慮，賽斯·吉爾伯特（Seth Gilbert）和南?！ち制?#xff08;Nancy Lynch）對指標的含義做了預設和限制，比如，將一致性限制為原子一致性。

四.CAP理論實例

開源版的 InfluxDB，缺乏集群能力和可用性，而且，InfluxDB 是由 META 節點和 DATA 節點 2 個邏輯單元組成，這 2 個節點的功能和數據特點不同，需要我們分別為它們設計分區容錯一致性模型。

設計

• 作為分布式系統，分區容錯性是必須要實現的，不能因為節點間出現了分區故障，而出現整個系統不工作的情況。
• 考慮到 META 節點保存的是系統運行的關鍵元信息，比如數據庫名、表名、保留策略信息等，所以必須實現一致性。也就是說，每次讀，都要能讀取到最新數據，這樣才能避免因為查詢不到指定的元信息，時序數據記錄寫入失敗或者系統沒辦法正常運行。比如，創建了數據庫 telegraf 之后，如果系統不能立刻讀取到這條新的元信息，那么相關的時序數據記錄，就會因為找不到指定數據庫信息而寫入失敗，所以，我選擇 CAP 理論中的 C 和 P，采用 CP 架構。
• DATA 節點保存的是具體的時序數據記錄，比如一條記錄 CPU 負載的時序數據，“cpu_usage,host=server01,location=cn-sz user=23.0,system=57.0”。雖然這些數據不是系統運行相關的元信息，但服務會被訪問頻繁，水平擴展、性能、可用性等是關鍵，所以，我選擇了 CAP 理論中的 A 和 P，采用 AP 架構。

五.小結

• CA 模型，在分布式系統中不存在。因為舍棄 P，意味著舍棄分布式系統，就比如單機版關系型數據庫 MySQL，如果 MySQL 要考慮主備或集群部署時，它必須考慮 P。
• CP 模型，采用 CP 模型的分布式系統，舍棄了可用性，一定會讀到最新數據，不會讀到舊數據。一旦因為消息丟失、延遲過高發生了網絡分區，就影響用戶的體驗和業務的可用性（比如基于 Raft 的強一致性系統，此時可能無法執行讀操作和寫操作）。典型的應用是 Etcd，Consul 和 Hbase。
• AP 模型，采用 AP 模型的分布式系統，舍棄了一致性，實現了服務的高可用。用戶訪問系統的時候，都能得到響應數據，不會出現響應錯誤，但會讀到舊數據。典型應用就比如 Cassandra 和 DynamoDB。

參考

《分布式協議與算法實戰》

總結

以上是生活随笔為你收集整理的CAP理论总结的全部內容，希望文章能夠幫你解決所遇到的問題。

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