Eureka 与 Zookeeper的区别
集群方面
- Eureka: Eureka是一个注册中心,如果搭建集群的话,没有主从之分,eureka会把自己注册到其他的eureka-server身上。
- Zookeeper：一个注册中心，一个zookeeper集群在同一个时刻只有一个Leader，其他都是Follower或者Observer，并且当主服务器宕机之后，需要有一段时间（可能是30s）的时间进行选举一个新的Leader出来，这段选举的时间是不可用的。
原理方面
- Eureka: 每一个微服务启动后想Eureka-server注册，Eureka-server会将注册信息向其他Eureka-server进行同步，当服务消费这调用服务提供者时，则向服务注册中新获取服务提供者地址，然后会将服务提供者地址缓存到本地，下次进行调用的时候，直接从本地缓存中读取，并且服务提供者会周期性（默认30S）向Eureka-server发送心跳，以证明该服务可用，如果eureka-server在一定时间（默认90s）未收到客户端的心跳，则认为宕机，会注销该服务实例。
- Zookeeper: 用于服务治理，每启动一个服务，就会到zookeeper注册一个临时节点。每次当有服务宕机，由于时临时节点，此节点会礼纪被删除，并且通知已经订阅该服务的微服务更新服务列表。每当有新的服务，会在对应的目录下创建临时的子节点，并通知已经订阅该服务的微服务更新服务列表。
CAP方面
- Consistency: 一致性
- Availability: 可用性
- Partition Tolerance: 分区容错性
目前这三个指标不可能同时做到。这个结论就叫CAP定理。
分区容错
大多数的分布式系统都分布在多个服务器下的子网络。每个子网络就叫做一个区（partition）。
比如一台服务器放在北京，另外一台服务器放在东京，这就是两个区，他们之间的通信可能失败，可以理解为分区容错。
上图，server1跟server是两台跨区的服务器，server1向server2发送一条消息，server2可能无法收到。所以一般来说，分区容错是无法避免的，因此CAP的P总是成立的。
Consistency
Consistency 一致性，理解为 当有一个写操作之后的读操作，就必须返回该值，假如server1中有一个变量i = 1，client向server1发起了一个写操作 i = 2 ，那么client读到的就是i = 2。
但是 用户可能从server2中发起读操作，由于server2的值没有发生变化，因此返回的i=1，所以server1跟server2读取的值不一致，这就不满足一致性。
所以为了让server1跟server2返回的值一致，我们需要在往server1执行写操作的时候，让server1给server2发送一条消息，让server2的i = 2。
Availability
可用性，意思就是server收到用户的请求，服务器就必须给出回应，不管是哪台服务器，只要收到，不管这个时候是i=1还是i=2 ,都要回应给客户，否则就不满足可用性。
Consistency 和 Availability 矛盾
当我们为了要保证一致性的时候，server1跟server2就必须数据同步，在同步的过程中，server2就必须有一个锁定的时间，只要同步完数据之后，才能重新放开读写操作，这个时候满足了一致性，但是却不满足可用性。所以C跟A只能选择一个。
Eureka与Zookeeper的CAP
Eureka 在设计的时候遵循的是AP原则，因为各个节点都是平等的，当搭建了eureka集群之后，就算有宕机了eureka，服务依然可以注册到剩余的eureka。只要有一台eureka还在，就能保证注册时可用的，保证了可用性。但是查询到的信息不一定是最新的，不保证强一致。
Zookeeper在设计的遵循的是CP原则，当master节点故障的时候，剩余的节点会重新选举一个master出来，而选举过程中整个zookeeper集群是不可以用的，因此做不到高可用。