本文已参与 「掘力星计划」 ，赢取创作大礼包，挑战创作激励金。
CAP是什么?
C (Consistency) 一致性
A (Availability) 可用性
P (Partition tolerance) 分区容错性
在分布式系统中最多只能保证上面3个特点中的两个同时满足：
CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差。
CP：满足一致性，分区容错的系统，通常性能不是特别高。
AP：满足可用性，分区容错的系统，通常可能对一致性要求低一些。
各种组件如何取舍？
Zookeeper保证的是CP
zookeeper通过ZAB协议（过半机制）保证了数据的强一致性，其主要分为两个方面：
1）leader选举原理（myid，zxid）
2）集群消息广播（类似2PC-两阶段提交，无需全部节点ack，过半即发起commit）
leader选举耗时较长，此时集群不可用，所以zk难易保证集群的可用性。
当作为注册中心时，需要保证的是服务的可用性，确保服务能够正确的注册和发现，而dubbo通过本地缓存的方式解决zk选举时集群不可用的问题。
Eureka保证的是AP
eureka提供集群模式，且eureka client会将从eureka server拉取的服务注册信息拉取到本地缓存中，挂机后仍然保证服务可用，实现了高可用。
其在集群时，采用对等复制，会在同步数据过程中导致各节点的数据不一致；另外其内部的三层缓存机制也会导致客户端和server端的注册信息不相同，也不能保证数据一致性。
由于心跳机制的存在，会对存在差异的数据进行补偿，达到最终一致性。
eureka作为注册中心，主要保证服务可用性，可容忍服务调用时不是最新的服务。
Redis对CAP的取舍
redis是单worker的，所以其能保证原子性，单机时是强一致性的。
redis提供两种持久化机制，AOF和RDB：
AOF增量日志，耗费性能。但能保证数据一致性。
RDB快照，丢失数据。难以保证数据一致性。
两者结合使用，在RDB基础上进行AOF，能在保证一定性能基础上，实现数据的一致性。
后来为了增加可用性，增加了主从，哨兵，集群模式。
主从模式下存在数据同步的过程，如果同步过程中有节点挂掉，很难保证主从节点的数据一致。
哨兵模式在主从基础上增加了sentinel节点，用于监控主从节点状态，当master宕机了，进行投票选举出新的master，解决主从模式下master宕机集群不可用。仍然很难保证主从数据的一致性。
集群模式是将多个节点的服务，使用一致性哈希（哈希环），分为2^32-1个哈希槽，其实是为了解决单点数据过多的问题，对数据分片；这种模式下可以保证数据一致性，但是当节点宕机会造成部分数据不可用，仍然需要对每个节点做主从，同样存在主从数据不一致的风险。
综上可以看出：
CAP难以全部实现，需要高可用的话必然难以要求数据强一致性，此时保证AP，可通过其他补偿方式实现最终一致性。
对于要求强一致性的节点可以使用单机或分片集群，此时保证CP。
nacos既支持AP，也支持CP
在Nacos中如果是临时节点就会使用AP协议，如果不是临时节点就会走CP。在注册中心中所有的实例其实默认都是临时节点。
在Nacos中为了实现AP，自己定制了一套Distro协议。
