註冊中心不同產品的對比
| 產品 | 使用語言 | CAP | 資料一致性 | 多資料中心 | Watch支援 | KV儲存 | 服務健康檢查 | 對外暴露介面 | Spring Cloud整合 |
|---|---|---|---|---|---|---|---|---|---|
| Eureka | java | AP | -- | -- | Long Polling | -- | 可配置支援 | HTTP | 已整合 |
| zookeeper | java | CP | ZAB(Paxos) | -- | 支援 | 支援 | 心跳 | 客戶端 | 已整合 |
| consul | go | CP | Raft | 支援(Gossip) | Long Polling | 支援 | 服務狀態、記憶體、磁碟等 | HTTP/DNS | 已整合 |
Eureka叢集模式，叢集內的每個機器地位是相等的，不存在主從，每個服務可以向任意一個Eureka例項進行服務註冊與發現，叢集中的每一個Eureka例項接收到寫請求之後都會自動同步給其他所有的Eureka例項
Eureka是對等模式，可能資料還沒同步完，然後就宕機了，此時還是可以從其他機器拉取註冊資訊，只是不保證是最新的註冊資訊，該過程服務可以向其他沒有宕機的節點進行註冊，爲了保證A而捨棄了C
Zookeeper 是有Leader+Follower兩種角色，只有Leader負責寫，也就是服務註冊，然後把資料同步給所有的Follower，進行讀操作時，也就是服務發現
由於Zookeeper是隻有Leader是進行寫操作的，如果leader掛了，需要重新選舉新的leader，此時叢集是不可用的，爲了保證C而捨棄了A
CAP原則
一致性C(Consistency) 在分散式系統中的所有資料備份，所有節點的資料一致，都是最新的資料
可用性A(Availability) 在叢集中任何一個節點掛了，其他節點可以繼續對外提供服務
分割槽容錯性P(Partition tolerance) 在分散式系統中每臺主機稱為一個分割槽，系統如果不能在時限內達成資料一致性或者無法及時響應客戶端請求，都意味著出現了分割槽的情況，此時就需要在C和A之間做出選擇，即為容錯性
CP:如果需要一致性，就會影響到可用性，一旦系統出現故障，就需要等待一段時間進行修復，在修復期間無法對外提供服務，資料同步會消耗時間，導致可用性降低
AP:如果需要可用性，只要有一個服務在，就能正常接受請求，只能放棄強一致性，採用最終一致性
CA:如果想要滿足一致性和可用性，那麼分割槽容錯性就難保證了，只能是單點
