概要
在分布式系统中，以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和zoomkeeper1 之后，服务b可以在集合中获取服务a的地址，并且可以从任何节点获取服务a的服务地址。
数据库提交两个阶段。 在第一个阶段，事务协调员向事务中涉及的所有数据库请求“提交前”(precommit )此操作，以反映是否可以提交。 在第2阶段，事务协调员必须向每个数据库发送数据。 如果其中一个数据库拒绝此提交，则所有数据库操作的数据都将回滚。
在Kafka集群(对于ack=all配置)和Kafka消息集群中，如果生产者生成消息，而采用ack=all配置，则消息将成功写入分区及其所有分区副本此时，消费者从集群获取的数据全部一致。