CAP定义

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

• C（一致性）：所有的节点上的数据时刻保持同步.
• A（可用性）：每个请求都能接受到一个响应，无论响应成功或失败.
• P（分区容错）：系统应该能持续提供服务，即使系统内部有消息丢失（分区）.

CAP理解

如果我们事先保证了分区容错性，也意味着若某个节点故障了，用户还是可以继续访问。这时用户在访问过程中就会出现一致性和可用性不能同时满足的情况

1.）假设分布式系统有G1，G2两个节点，初始值都是v0。现在有一个client向系统写入了值v1，这里假设直接写的是节点G1。写完之后client再去读取这个值，这时读到了G2节点,

由于G2节点与G1节点失去连接，这时G1节点上的数据还未同步到G2节点，因此客户端读取到的是修改之前的值v0。 这就出现了不满足一致性的情况了。相当于满足了可用性，失去了一致性.

2.）如果系统保证了强的一致性，那么在client 写完G1节点后, 而G1向G2节点同步数据出现了问题，这时如果client再去读取G2节点的数据时，client就会一直处于等待状态，因为系统内各节点

数据为同步上，需要等同步上才能使用。这就相当于满足了一致性，而失去了可用性.

场景选择

由于CAP三者不可兼得，该如何取舍：

(1) CA: 优先保证一致性和可用性，放弃分区容错。 这也意味着放弃系统的扩展性，系统不再是分布式的，有违设计的初衷。

(2) CP: 优先保证一致性和分区容错性，放弃可用性。在数据一致性要求比较高的场合(譬如:zookeeper,Hbase) 是比较常见的做法，一旦发生网络故障或者消息丢失，就会牺牲用户体验，等恢复之后用户才逐渐能访问。

(3) AP: 优先保证可用性和分区容错性，放弃一致性。Eureka 就是这种架构。跟CP一样，放弃一致性不是说一致性就不保证了，而是逐渐地变得一致。