CAP理论

CAP理论

CAP即：

• Consistency（一致性）
• Availability（可用性）
• Partition tolerance（分区容忍性）

这三个性质对应了分布式系统的三个指标：而CAP理论说的就是：一个分布式系统，不可能同时做到这三点。

①**一致性：**对于客户端的每次读操作，要么读到的是最新的数据，要么读取失败。换句话说，一致性是站在分布式系统的角度，对访问本系统的客户端的一种承诺：要么我给您返回一个错误，要么我给你返回绝对一致的最新数据，不难看出，其强调的是数据正确。

②**可用性：**任何客户端的请求都能得到响应数据，不会出现响应错误。换句话说，可用性是站在分布式系统的角度，对访问本系统的客户的另一种承诺：我一定会给您返回数据，不会给你返回错误，但不保证数据最新，强调的是不出错。

③**分区容忍性：**由于分布式系统通过网络进行通信，网络是不可靠的。当任意数量的消息丢失或延迟到达时，系统仍会继续提供服务，不会挂掉。换句话说，分区容忍性是站在分布式系统的角度，对访问本系统的客户端的再一种承诺：我会一直运行，不管我的内部出现何种数据同步问题，强调的是不挂掉。

对于一个分布式系统而言，P是前提，必须保证，因为只要有网络交互就一定会有延迟和数据丢失，这种状况我们必须接受，必须保证系统不能挂掉。所以只剩下C、A可以选择。要么保证数据一致性（保证数据绝对正确），要么保证可用性（保证系统不出错）。

当选择了C（一致性）时，如果由于网络分区而无法保证特定信息是最新的，则系统将返回错误或超时。

当选择了A（可用性）时，系统将始终处理客户端的查询并尝试返回最新的可用的信息版本，即使由于网络分区而无法保证其是最新的。

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

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

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

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

分布式事务中基于分布式 消息的最终一致性方案对事务的处理，就是选择 AP 而牺牲 C 的例子。 这个方案中，在应用节点之间引入了消息中间件，不同节点之间通过消息中间件进行交互， 比如主应用节点要执行修改数据的事务，只需要将信息推送到消息中间件，即可执行本地的 事务，而不需要备应用节点同意修改数据才能真正执行本地事务，备应用节点可以从消息中 间件获取数据。

在分布式系统中，现在的网络基础设施无法做到始终保持稳定，网络分区(网络不连通)难 以避免。牺牲分区容错性P，就相当于放弃使用分布式系统。既然分布式系统不能采用这种策略，那单点系统毫无疑问就需要满足 CA 特性了。比如关系型数据库 DBMS(比如 MySQL、Oracle)部署在单台机器上，因为不存在网络通信问 题，所以保证 CA 就可以了。

如果一个分布式场景需要很强的数据一致性，或者该场景可以容忍系统长时间无响应的情况 下，保 CP 弃 A 这个策略就比较适合。 一个保证 CP 而舍弃 A 的分布式系统，一旦发生网络分区会导致数据无法同步情况，就要 牺牲系统的可用性，降低用户体验，直到节点数据达到一致后再响应用户。

保证 CP 的系统有很多，典型的有 Redis、HBase、ZooKeeper 等。

ZooKeeper 集群包含多个节点(Server)，这些节点会通过分布式选举算法选出一个 Leader 节点。在 ZooKeeper 中选举 Leader 节点采用的是 ZAB 算法。

在 ZooKeeper 集群中，Leader 节点之外的节点被称为 Follower 节点，Leader 节点会专 门负责处理用户的写请求： 具体示意图如下所示： 当用户向节点发送写请求时，如果请求的节点刚好是 Leader，那就直接处理该请求；如果请求的是 Follower 节点，那该节点会将请求转给 Leader，然后 Leader 会先向所 有的 Follower 发出一个 Proposal，等超过一半的节点同意后，Leader 才会提交这次写 操作，从而保证了数据的强一致性。

比如当出现网络分区时，如果其中一个分区的节点数大于集群总节点数的一半，那么这个分区可 以再选出一个 Leader，仍然对用户提供服务，但在选出 Leader 之前，不能正常为用户提 供服务；如果形成的分区中，没有一个分区的节点数大于集群总节点数的一半，那么系统不 能正常为用户提供服务，必须待网络恢复后，才能正常提供服务。

这种设计方式保证了分区容错性，但牺牲了一定的系统可用性。

如果一个分布式场景需要很高的可用性，或者说在网络状况不太好的情况下，该场景允许数 据暂时不一致，那这种情况下就可以牺牲一定的一致性了。 网络分区出现后，各个节点之间数据无法马上同步，为了保证高可用，分布式系统需要即刻 响应用户的请求。但，此时可能某些节点还没有拿到最新数据，只能将本地旧的数据返回给 用户，从而导致数据不一致的情况。 适合保证 AP 放弃 C 的场景有很多。比如，很多查询网站、电商系统中的商品查询等，用 户体验非常重要，所以大多会保证系统的可用性，而牺牲一定的数据一致性。

采用保 AP弃C的系统也有很多，比如 Eureka、Cassandra。
CAP 中的 C 强调的是数据的一致性，也就是集群中节点之间通过复制技术保证每个节点上的数据在同一时刻是相同的。 ACID 中的 C 强调的是事务执行前后，数据的完整性保持一致或满足完整性约束。也就是不管在什么时候，不管并发事务有多少，事务在分布式系统中的状态始终保持一致。

CAP 中的 A 指的是可用性(Availability)，也就是系统提供的服务一直处于可用状态， 即对于用户的请求可即时响应。 ACID 中的 A 指的是原子性(Atomicity)，强调的是事务要么执行成功，要么执行失败。