三个服务注册中心的区别（CAP理论）

学了Eureka、Zookeeper、Consul之后，在基本配置和使用上，是大同小异的。新建模块，修改pom.xml，加入相关依赖，编写application.yml配置文件，指明应用名称，注册中心地址，编写主启动类，编写配置类和业务类（service和controller），最后是测试。

CAP理论是分布式系统的

一个概念，C是Consistency（一致性）的首字母，A是Availability（可用性）的首字母，P是Partition tolerance（分区容错性）的首字母。任何一个分布式系统都不能同时满足CAP，只能满足其中的两个。因为在分布式系统中，分区容错性P是必须要保证的，那么A和C就二选一了。

为什么C和A不能同时存在？

如果要保证一致性，那么，在一个结点写操作的时候，其他结点必须是锁定读写的，只有完成了数据同步，才能放开读写，锁定期间，其他结点是不可用的。

如果要保证可用性，那么，在一个结点写操作的时候，其他结点就不能锁定，此时，可能还没有完成同步操作，于是，其他节点读取到的数据就是旧数据，无法保证一致性。

Zookeeper保证CP(一致性)

一致性的意思是：写操作后的读操作，必须返回该值。Zookeeper不能保证每次的请求可用性，比如在leader选举时候，集群就是不可用的。选举leader的时间为30-120s，这段时间Zookeeper集群都是不可用的。

Eureka保证AP（可用性）

可用性的意思是：集群中各个节点是平等的，如果有几个结点挂掉不影响正常结点的工作，剩余结点依旧可以提供服务，只要有一台Eureka还存着，就能保证注册服务的可用，不过，信息可能不是最新的。

组件名	语言	CAP	服务健康检查	对外暴露接口	Spring Cloud集成
Eureka	Java	AP	可配支持	HTTP	已集成
Zookeeper	Java	CP	支持	客户端	已集成
Consul	Go	CP	支持	HTTP/DNS	已集成