CAP理論及Consul,Zookeeper,Eureka的異同點
阿新 • • 發佈:2020-10-13
1. Consul,Zookeeper,Eureka的異同點
名字 | 語言 | CAP | 服務健康檢查 | 對外暴露介面 | boot整合 |
---|---|---|---|---|---|
Eureka | Java | AP(保證高可用) | 可配支援 | HTTP | 是 |
Consul | Go | CP(保證資料一致) | 支援 | HTTP/DNS | 是 |
Zookeeper | Java | CP(保證資料一致) | 支援 | 客戶端 | 是 |
-
CAP
- C:COnsistency(強一致性)
- A:Availability(可用性)
- P:Partition tolerance(分割槽容錯性)
-
CAO理論關注粒度是資料,而不是整體系統設計的
- 核心理論
- 一個分散式系統不可能同時很好的滿足一致性,可用性,分割槽容錯性這三個需求
- 根據CAP原理將NoSql資料庫分為滿足CA原則,CP原則,AP原則的三大類
- CA——單點叢集,滿足一致性,可用性的系統;擴充套件性不高
- CP——滿足一致性,分割槽容錯性的系統;效能不高
- AP——滿足可用性,分割槽容錯性的系統;對一致性要求低
- 核心理論
-
例如:淘寶
- 淘寶京東:必須保證可用,必須是AP的,資料允許一定範圍內出錯,犧牲C資料一致來保證A可用;先保證系統不跨
-
AP架構
- 違背一致性C的要求,只滿足可用性和分割槽容錯,保證系統可用;AP
-
當沒有出現網路分割槽時,系統A與B資料一致,X=1
-
當系統A的X修改為2
-
出現網路分割槽後,A與B之間的資料同步失敗,系統B的X=1
-
當客戶端請求系統B時,為了保證可用性,此時系統B返回舊值
-
CP架構
- 違背可用性A的要求,只滿足一致性和分割槽容錯,CP架構
- 當沒有出現網路分割槽時,系統A與B資料一致,X=1
- 當系統A的X修改為2
- 出現網路分割槽後,A與B之間的資料同步失敗,系統B的X=1
- 當客戶端請求系統B時,為了保證一致性,此時系統B應該拒絕服務請求,返回錯誤碼或者錯誤資訊