深入理解CAP理论和适用场景

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

异步复制，当数据写入操作成功后，当数据成功复制到主副本时，甚至还没复制时，写操作就返回成功状态。这样，异步复制的性别比较好，但是，当主备出现故障时可能出现数据丢失。

一致性：数据复制的时候，按照强一致性的方式进行数据复制。保证了在读操作总是能够读取到之前写入的数据，无论从那个主数据或者副本数据。

可用性：数据写入成功后，正在进行数据复制时，任何一个副本节点发生异常也不会影响此次写入操作。可以理解为，此时数据的复制采用的是弱一致性，数据的读写操作在单台机器发生故障的情况下仍然可以正常执行。

分区容错性：在服务实例发生异常时，分布式系统仍然能够满足一致性和可用性。

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

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

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

数据库两阶段提交，第一阶段，事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交。第二阶段，事务协调器要求每个数据库提交数据。如果有任何一个数据库否决此次提交，那么所有数据库操作的数据都会回滚。

Kafka集群（ack=all的配置时），Kafka消息集群中，生产者生成消息时，采用ack=all的配置时，消息成功写入分区，以及其所有分区副本后才算写入成功。此时，消费者从集群中获取的数据都是一致的。