CAP 

也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。

• 一致性（Consistency）：所有节点访问同一份最新的数据副本
• 可用性（Availability）：非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）
• 分区容错性（Partition Tolerance）：分布式系统出现网络分区的时候，仍然能够对外提供服务。
  • ps:“网络分区”即多个节点本来是网络互通，但某些节点因为故障导致无法连通，整个网络就分成了几块区域，即网络分区

CAP的选择

大部分针对CAP的描述，仅简单表述为：一致性、可用性、分区容忍性三者只能同时达到其中两个。实际这是错误的。

当发生网络分区的时候，如果我们要继续服务，那么一致性和可用性只能2选1。也就是说当网络分区之后P是前提。

简而言之：CAP理论中分区容错性P是一定要满足的，再次基础上满足可用性A或者一致性C。因此，分布式系统理论上不可能选择CA架构，只能选择CP或者AP架构。比如ZooKeeper、HBase就是CP架构，Cassandra、Eureka就是AP架构，Nacos不仅支持CP架构也支持AP架构。

为啥不可能选择CA架构呢？举个例子：若系统出现“分区”，系统中的某个节点在进行写操作。为了保证C，必须要禁止其他节点的读写操作，也就和A发生了冲突。如果为了保证A,其他节点的读写操作正常的话，那就和C发生冲突了。选择CP还是AP的关键在于当前的业务场景，没有定论，比如对于需要确保强一致性的场景如银行一般会选择保证CP。

另外，需要补充说明的一点是：如果网络分区正常的话（系统在绝大部分时候所处的状态），也就说不需要保证P的时候，C和A可以同时保证。