CAP理解及consul、eureka、nacos对⽐
CAP原则⼜称CAP定理，指的是在⼀个分布式系统中，⼀致性（Consistency）、可⽤性（Availability）、分区容错性（Partition tolerance）
eureka
eureka集群下每个节点之间（P2P）都会定时发送⼼跳，定时同步数据，并没有master/slave之分，因此每个注册到eureka下的实例都会定时同步ip等，服务之间的调⽤也是根据eureka拿到的缓存服务数据进⾏调⽤。但是，如果⼀台eureka服务g掉了，其他eureka在⼀定时间内未感知到这台eureka服务g了，各个服务之间还是可以正常调⽤。 Eureka的集群中，只要有⼀台Eureka还在，就能保证注册服务可⽤（保证可⽤性），只不过查到的信息可能不是最新的（不保证强⼀致性）。当数据出现不⼀致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可⽤性但牺牲了⼀致性。 除此之外，Eureka还有⼀种⾃我保护机制，如果在15分钟内超过85%的节点都没有正常的⼼跳，那么Eureka就认为客户端与注册中⼼出现了⽹络故障，此时会出现以下⼏种情况：
Eureka不再从注册表中移除因为长时间没有收到⼼跳⽽过期的服务； Eureka仍然能够接受新服务注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可⽤）； 当⽹络稳定时，当前实例新注册的信息会被同步到其它节点中； 因此，Eureka可以很好的应对因⽹络故障导致部分节点失去联系的情况，⽽不会像zookeeper那样使得整个注册服务瘫痪。Eureka保证⾼可⽤(A)和最终⼀致性：
服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功
当数据出现不⼀致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可⽤性但牺牲了⼀致性。Consul：
Consul 是 HashiCorp 公司推出的开源⼯具，⽤于实现分布式系统的服务发现与配置。Consul 使⽤ Go 语⾔编写，因此具有天然可移植性（⽀持Linux、windows和Mac OS X）。
Consul 内置了服务注册与发现框架、分布⼀致性协议实现、健康检查、Key/Value 存储、多数据中⼼⽅案，不再需要依赖其他⼯具（⽐如ZooKeeper 等），使⽤起来也较为简单。
Consul 遵循CAP原理中的CP原则，保证了强⼀致性和分区容错性，且使⽤的是Raft算法，⽐zookeeper使⽤的Paxos算法更加简单。虽然保证了强⼀致性，但是可⽤性就相应下降了，例如服务注册的时间会稍长⼀些，因为 Consul 的 raft 协议要求必须过半数的节点都写⼊成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可⽤。Consul强⼀致性(C)带来的是：
服务注册相⽐Eureka会稍慢⼀些。因为Consul的raft协议要求必须过半数的节点都写⼊成功才认为注册成功Leader挂掉时，重新选举期间整个consul不可⽤。保证了强⼀致性但牺牲了可⽤性。
Consul强⼀致性(C)带来的是：
服务注册相⽐Eureka会稍慢⼀些。因为Consul的raft协议要求必须过半数的节点都写⼊成功才认为注册成功 Leader挂掉时，重新选举期间整个consul不可⽤。保证了强⼀致性但牺牲了可⽤性。 Eureka保证⾼可⽤(A)和最终⼀致性：
服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功 当数据出现不⼀致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可⽤性但牺牲了⼀致性。 其他⽅⾯，eureka就是个servlet程序，跑在servlet容器中; Consul则是go编写⽽成。
Nacos
个⼈⽐较看好nacos，整合了配置中⼼和服务发现，和cloud，dubbo天然结合，代码也没啥侵⼊性 Nacos： Nacos是阿⾥开源的，Nacos⽀持基于 DNS 和基于 RPC 的服务发现。在Spring Cloud中使⽤Nacos，只需要先下载 Nacos 并启动 Nacos server，Nacos只需要简单的配置就可以完成服务的注册发现。
Nacos除了服务的注册发现之外，还⽀持动态配置服务。动态配置服务可以让您以中⼼化、外部化和动态化的⽅式管理所有环境的应⽤配置和服务配置。动态配置消除了配置变更时重新部署应⽤和服务的需要，让配置管理变得更加⾼效和敏捷。配置中⼼化管理让实现⽆状态服务变得更简单，让服务按需弹性扩展变得更容易。
⼀句话概括就是Nacos = Spring Cloud注册中⼼ + Spring Cloud配置中⼼。
总结：
C ⼀致性：注册⼀个服务，集群下多节点必须全部注册成功后才能进⾏访问和使⽤；master节点挂掉了需要等待重新选举成功后才能使⽤，选举期间服务不可⽤； (所有节点在同⼀时间具有相同的服务)
A 可⽤性：注册⼀个服务，只要有⼀个节点注册成功就可以对外提供访问；master节点挂了也可以正常使⽤； (保证每个请求不管成功或者失败都有响应)
P 容错性：把服务注册到每个节点，增强容错机制 (系统中任意信息的丢失或失败不会影响系统的继续运作)