ZooKeeper、Eureka、Consul、Nacos的选型对比

服务注册中心选型对比.png

1.趋势

zookeeper和eureka，consul用的没那么多，nacos现在用的越来越多，以后也会是一个大的趋势，但是现在可能还没那么的普及

2.CAP理论

CAP原则又称CAP定理，指的是在一个分布式系统中，[一致性]、[可用性]、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

分区容错性：指的分布式系统中的某个节点或者网络分区出现了故障的时候，整个系统仍然能对外提供满足一致性和可用性的服务。也就是说部分故障不影响整体使用。

可用性： 一直可以正常的做读写操作。简单而言就是客户端一直可以正常访问并得到系统的正常响应。用户角度来看就是不会出现系统操作失败或者访问超时等问题。

一致性：在分布式系统完成某写操作后任何读操作，都应该获取到该写操作写入的那个最新的值。相当于要求分布式系统中的各节点时时刻刻保持数据的一致性。

3.zookeeper原理

zookeeper的原理，leader+follower，leader写，同步到follower，follower可以读，保证顺序一致性，就是基本尽量保证到数据一致的，主动推送，典型的CP，leader崩溃的时候，为了保证数据一致性，尽量不要读到不一致的数据，此时要重新选举leader以及做数据同步，此时集群会短暂的不可用，CP

4.服务注册中心选型

• 服务注册中心选型对比的时候，其他的分布式系统选型的时候，一般要满足cp或者ap
• P简单来说就是任何分布式系统一般都会满足，他就是分区容错性；CP，C，一致性，尽可能的去保证你读取到的数据是一致的，牺牲掉一个A，可用性，一旦leader崩溃，zk可能会有一个短时间内，几十s有可能，集群不可用，此时需要重新选举一个leader，然后再做数据同步，保证数据一致性之后再开放让你来读取

5.eureka的原理

eureka的原理，peer-to-peer，大家都能写也都能读，每个节点都要同步给其他节点，但是是异步复制的，所以随时读任何一个节点，可能读到的数据都不一样，任何一个节点宕机，其他节点正常工作，可用性超高，但是数据一致性不行，AP

5.Nacos和Consul

Consul也是基于raft算法的CP模型
Nacos也是基于raft算法的CP模型，同时也支持配置成类似eureka的AP

总结

其实CP或者AP也都行，CP就是偶尔可能短时间不可用，AP就是可能数据不一致，两个都有问题，但是在生产环境下，无论CP还是AP其实都用的很多

但是未来还是建议大家用nacos，因为nacos的功能最为完善，包括了雪崩保护、自动注销实例、监听支持、多数据中心、跨注册中心同步、spring cloud集成、dubbo集成、k8s集成，这些都支持，其他的几个技术基本都支持部分罢了