分布式系統CAP定理中的P原理是什么

這篇文章主要介紹“分布式系統CAP定理中的P原理是什么”，在日常操作中，相信很多人在分布式系統CAP定理中的P原理是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”分布式系統CAP定理中的P原理是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

什么是 CAP 定理（CAP theorem）

在理論計算機科學中，CAP 定理（CAP theorem），又被稱作布魯爾定理（Brewer's theorem），它指出對于一個分布式計算系統來說，不可能同時滿足以下三點：

• 一致性（Consistency） （等同于所有節點訪問同一份最新的數據副本）

• 可用性（Availability）（每次請求都能獲取到非錯的響應——但是不保證獲取的數據為最新數據）

• 分區容錯性（Partition tolerance）（以實際效果而言，分區相當于對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在 C 和 A 之間做出選擇。）

分區容錯性（Partition tolerance）

理解 CAP 理論的最簡單方式是想象兩個節點分處分區兩側。允許至少一個節點更新狀態會導致數據不一致，即喪失了 C 性質。如果為了保證數據一致性，將分區一側的節點設置為不可用，那么又喪失了 A 性質。除非兩個節點可以互相通信，才能既保證 C 又保證 A，這又會導致喪失 P 性質。

• P 指的是分區容錯性，分區現象產生后需要容錯，容錯是指在 A 與 C 之間選擇。如果分布式系統沒有分區現象（沒有出現不一致不可用情況） 本身就沒有分區 ，既然沒有分區則就更沒有分區容錯性 P。

• 無論我設計的系統是 AP 還是 CP 系統如果沒有出現不一致不可用。 則該系統就處于 CA 狀態

• P 的體現前提是得有分區情況存在

文章來源：維基百科 CAP 定理

幾個常用的 CAP 框架對比

Eureka

Eureka 保證了可用性，實現最終一致性。

Eureka 所有節點都是平等的所有數據都是相同的，且 Eureka 可以相互交叉注冊。 Eureka client 使用內置輪詢負載均衡器去注冊，有一個檢測間隔時間，如果在一定時間內沒有收到心跳，才會移除該節點注冊信息；如果客戶端發現當前 Eureka 不可用，會切換到其他的節點，如果所有的 Eureka 都跪了，Eureka client 會使用最后一次數據作為本地緩存；所以以上的每種設計都是他不具備一致性的特性。

注意：因為 EurekaAP 的特性和請求間隔同步機制，在服務更新時候一般會手動通過 Eureka 的 api 把當前服務狀態設置為offline，并等待 2 個同步間隔后重新啟動，這樣就能保證服務更新節點對整體系統的影響

Zookeeper

強一致性

Zookeeper 在選舉 leader 時會停止服務，只有成功選舉 leader 成功后才能提供服務，選舉時間較長；內部使用 paxos 選舉投票機制，只有獲取半數以上的投票才能成為 leader，否則重新投票，所以部署的時候最好集群節點不小于 3 的奇數個（但是誰能保證跪掉后節點也是奇數個呢）；Zookeeper 健康檢查一般是使用 tcp 長鏈接，在內部網絡抖動時或者對應節點阻塞時候都會變成不可用，這里還是比較危險的；

Consul

和 Zookeeper 一樣數據 CP

Consul 注冊時候只有過半的節點都寫入成功才認為注冊成功；leader 掛掉時，重新選舉期間整個 Consul 不可用,保證了強一致性但犧牲了可用性 有很多 blog 說 Consul 屬于 ap，官方已經確認他為 CP 機制。

到此，關于“分布式系統CAP定理中的P原理是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！