Zookeeper与Eureka的区别

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中获取服务。