一，CAP理论

CAP是Consistency，Availability，Partitiion tolerance三个词的缩写

• C：一致性
• A：可用性 
• P：分区容错性

结合电商系统中的=一些业务场景来理解CAP

整体流程如下：

• 用户对进行下单操作，订单服务将信息写主数据库
• 主数据库向订单微服务响应成功
• 订单微服务向从数据库读取信息

一，Consistency一致

 一致性：指的是当数据和服务发布在多个集群节点上，对任意节点上的数据进行写操作，任意节点都能读到数据的最新状态

上图中，订单信息的读写要满足一致性就需要实现如下要求：

1. 订单服务写入主数据库成功，则向从数据库查询新数据也成功
2. 订单服务写入主数据库失败，则向从数据库查询新数据也失败

如何实现一致性：

1. 写入主数据库后将数据同步到从数据库中
2. 写入主数据库后，在向从数据库同步期间要将从数据库锁定，待同步完成后再释放锁，以免在新数据写入成功后，向从数据库查询到旧数据

分布式一致性的特点：

• 由于存在数据同步的过程，写操作的响应会有一定的延迟
• 为了保证数据一致性会对只要暂时锁定，待数据同步完成释放锁定的资源
• 如果请求数据同步失败节点则会返回错误信息，一定不会返回旧数据

二，Availability可用性

可用性：指任何一致性操作都可以得到执行，不能出现服务超时或响应错误，任何时候都要提供服务

上图中，订单信息读写满足可用性就是要实现如下要求：

1. 从数据库收到数据查询的请求则立即能够响应数据查询结果
2. 从数据库不允许出现响应超时或响应错误等情况

如何实现可用性：

1. 写入主数据库后要数据同步到从数据库
2. 由于要保证从数据库的可用性，不可将从数据库中的资源进行锁定
3. 即使数据还没有同步过来，从数据库也要返回查询的数据，怕是旧数据，如果连旧数据也没有则可以按照约定返回一个默认信息，但不能返回错误或响应超时

分布式可用性的特点：所有请求都要响应，且不会出现响应超时或响应错误

三，Partitiion tolerance分区容错性

通常分布式系统的各个节点部署在不同的子网，这就是网格分区，不可避免的会出现网络问题而导致节点之间的通信失败，此时仍然可对外提供服务，这就叫分区容错性

上图中，订单信息读写满足可用性就是要实现如下要求：

1. 主数据库向从数据库同步数据失败不影响读写操作
2. 其中一个节点挂掉不影响另一个节点对外提供服务

如何实现分区容错性：

1. 尽量使用异步取代同步操作，例如：使用异步方式将数据从主数据库同步到从数据库，这样节点之间能有效的实现松耦合
2. 添加从数据库节点，其中一个从节点挂掉其他从节点提供服务

分区容错性是分布式系统具备的基本能力，只要是发布式系统就必须有这一能力

二，CAP的组合方式

在所有分布式场景中不会同时具备CAP三个特性，因为在具备P的前提下C和A不能共存

本图分区容错的含义是：

1. 主数据库提供网络向从数据库同步数据，可以认为主数据库部署在不同的分区，彼此通过网络进行交互
2. 当主数据库和从数据库之间的网络通信出现问题不会影响它们对外提供服务
3. 其中一个节点挂掉不影响另一个节点对外提供服务

  如果要实现C则必须保证数据一致性：在数据同步的时候为防止向从数据库查询不一致的数据需要将从数据库数据进行锁定，待同步完成后才进行释放，如果同步失败从数据库要返回错误信息或超时信息(在同步锁定的时候数据不可用)

  如果要实现A则必须保证数据可用性：不管任何时候都可以向从数据库查询数据，而不会响应超时或返回错误信息

A和C往往是矛盾的，数据一致性有锁定的过程，而锁定时是不可用的，可用性没有锁而一致性没有保障

CAP的组合方式：

1，AP：放弃一致性，追求分区容错性和可用性，这是很多分布式系统设计时的选择

例如：商品管理，完全可以实现AP，前提是只要用户可以接受查询的数据在一定时间内不是最新数据。

通常实现AP都会保证最终一致性，后面的BASE理论就是根据AP拓展的，一些业务场景，比如：订单退款，今日退款成功，明日账户到帐，只要用户可以接受在一定时间内到账即可

2，CP：放弃可用性，追求一致性和分区容错性，如Zookeeper其实就是追求强一致性，又比如：跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成

3，CA：放弃分区容错性，即不进行分区，不考虑由于网络不通或节点挂掉的问题，则可以实现一致性和可用性，

没有分区容错性那么系统就不是一个标准分布式系统，最常见的关系性数据库就满足CA(单体架构)

 

三，BASE理论

 CAP中一个分布式最多只能满足一致性，可用性，分区容错性这三项中的两项，其中AP在实际应用中较多，AP即舍弃了一致性，保留了可用性和分区容错性，但在实际的生产过程中一致性是必须要保证的，这时就有了BASE

  BASE理论是对CAP中AP的一个补充，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内不一致，但最终必须达到一致，满足BASE理论的事务叫做"柔性事务"

BASE核心概念：

1. 基本可用(Basically Available)：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能，如：电商网站交易付款出现问题，商品仍然可用浏览
2. 软状态(Soft state)：由于不要求强一致性，所以BASE允许系统存在一个中间状态(也叫软状态)，这个状态不影响系统可用性，如：订单的"支付中"，待数据最终一致后状态改为"成功"
3. 最终一致性：最终一致性是指经过一段时间后，所有节点数据都会达到一致，如订单的"支付中"状态，最终为"支付成功"或"支付失败"，使订单状态与实际交易结果达成一致，但需要一定时间的延迟和等待