Zookeeper與Eureka的區別

想要了解Zk與eureka的區別首先要知道CAP定理

 

CAP定理

 

 

Mysql強一致性（數據唯一出處），設計數據庫設計的三范式

（表必須有主鍵；表不能有重復的列；列不能是加工而成）

主流數據庫表的設計方式：反三范式，冗余設計（性能高，缺點：數據多處，同步數據時間差，短暫時間數據不一致。）

 

最終一致性，允許短暫時間內數據可以不一致，但過了這個時間閥值必須數據是一致。

 

可用性，zk主從設計，如果zk節點有一半節點宕機或者有節點正在選舉，此時zk集群不可用！

Eureka，p2p點對點設計，每個點的信息都可以用戶接入，每個點如果信息變化，它內部會自動同步所有的數據。Eureka即使所有的節點都宕機，

仍然能提供服務。EurekaClient客戶端，緩存所有的數據信息，也能找到服務提供者。

 

為什么不用zookeeper做注冊中心 在使用dubbo時，一般都結合zk（作為注冊中心）來使用。那為什么SpringCloud中使用Eureka，而不是zk呢？

我們來比較一下，在CAP理論中，zk更看重C和P，即一致性和分區容錯性。但Eureka更在意的是A和P，A為高可用。zk中有master和follower區別，

當進入選舉模式時，就無法正常對外提供服務。但Eureka中，集群是對等的，地位是相同的，雖不能保證一致性，但至少可以提供注冊服務。

根據不同的業務場景，各有取舍吧。ZooKeeper 基於CP設計，側重一致性而Eureka基於AP設計，側重可用性

 

Eureka只有一個8761的注冊中心，那么如何避免單點問題呢？

我們可以采用集群的方式來解決。 比如現在有三台機器：Server1、Server2和Server3.在高可用方案中，三台機器要兩兩注冊。

比如S1要向S2、S3分別進行注冊，目前他無法實現注冊的傳遞性。 這樣一來，如果Server1宕機，我們還可以繼續從Server2和3中獲取服務。