什么是CAP？适用的场景有哪些？

概述

在分布式系统中，围绕着CAP理论，主要关注点就是复制，一致性，容错性。

复制

为了保证系统的高可用和高可靠性，通过复制的方式，让数据在系统中存储多个副本。以服务实例多副本为例，当一个服务发生异常时，客户端就直接调用其他正常的副本。如下：

 服务A有两个副本，分别为副本1和副本2。当客户端调用服务A时，如果服务A发生异常无法调用，此时，客户端调用副本1或者副本2，这样就保证了系统的高可用。

可以就这么认为，每个服务实例发生异常是无法避免的。例如，因为内存错误，第三方中间件挂掉了，甚至服务器停电等原因造成服务器宕机。或者，因为消息丢失，消息乱序，或者网络包数据错误造成网络异常等等。

一致性

在数据的复制中，由于存在多个数据副本，就会存在主数据与副本数据一致性的问题。在同一份数据的副本中，一般有一个副本为主副本，其他的备副本。在数据的复制过程中，复制的方式分为两种分别如下：

• 强同步复制，数据的写操作需要同步到主副本和所有的备副本，并且全部写入成功后，才返回成功状态。这样，当系统出现异常时，切换到其他任何一个备份副本时，数据是一致的。但是，强同步复制性能不好，而且可用性比较差。如果，在复制过程中，如果某个备份节点出现故障，这时，会阻塞数据的正常写服务。
• 异步复制，当数据写入操作成功后，当数据成功复制到主副本时，甚至还没复制时，写操作就返回成功状态。这样，异步复制的性别比较好，但是，当主备出现故障时可能出现数据丢失。

容错性

分布式系统中，集群的规模越大发生错误的概率就也大。一般，分布式系统发生异常时，都能够自动容错，保证系统的高可用。

CAP理论

CAP理论是Eric Brewer教授提出的，分别是一致性（Consistency），可用性（Availability），分区容错性（Tolerance of network Partition），三者不能同时满足。CAP三者可以按照如下的方式来理解：

• 一致性：数据复制的时候，按照强一致性的方式进行数据复制。保证了在读操作总是能够读取到之前写入的数据，无论从那个主数据或者副本数据。
• 可用性：数据写入成功后，正在进行数据复制时，任何一个副本节点发生异常也不会影响此次写入操作。可以理解为，此时数据的复制采用的是弱一致性，数据的读写操作在单台集器发生故障的情况下仍然可以正常执行。
• 分区容错性：在服务实例发生异常时，分布式系统任然能够满足一致性和可用性。

在分布式系统中，是必须要求系统能够自动容错的，所以，必须满足分区容错性。因此，一致性和可用性就需要根据系统需求二选一了。

CAP使用场景

AP模式

• eureka服务注册与发现中心集群，在集群中，新增一个eureka实例时，集群中的实例是相互复制其注册的服务实例数据。示例如下：

如图，在服务B向Eureka2注册成功后，此时，Eureka2还没向Eureka3复制成功就挂掉了，此时，在Eureka的服务注册与发现中心集群中造成了数据不一致。当服务A通过服务注册于发现中心集群通过Eureka3来拿服务B的地址时，就无法拿到。

• mysql数据集群与redis集群，由于mysql和redis的数据复制都是采用的异步复制，所以mysql数据集群与redis集群都属于AP类型，在集群中获取数据时，会存在数据不一致的情况。

CP模式

• zoomkeeper服务注册与发现中心集，在集群中，包含一个Leader节点，其余全部为Follower 节点。Leader节点负责读和写操作，Follower 节点只负责读操作。当客户端向集群发出写请求时，写请求会转发到Leader节点，Leader写操作完成后，采用广播的形式，向其余Follower 节点复制数据，Follower节点也写成功，返回给客户端成功。流程如图：

如图，在服务A向zoomkeeper集群注册时，写请求会被转发到Leader节点(zoomkeeper1)，此时，Leader节点写入成功后，会通知 zoomkeeper2和zoomkeeper3节点进行复制，并且复制成功了才会向服务A返回注册成功的状态。此后，服务B通过集合获取服务A的地址，无论从哪个节点都能获取服务A的服务地址。

• 数据库两阶段提交，第一阶段，事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交。第二阶段，事务协调器要求每个数据库提交数据。如果有任何一个数据库否决此次提交，那么所有数据库操作的数据都会回滚。
• Kafka集群（ack=all的配置时），Kafka消息集群中，生产者生成消息时，采用ack=all的配置时，消息成功写入分区，以及其所有分区副本后才算写入成功。此时，消费者从集群中获取的数据都是一致的。