彻底搞懂CAP理论（电商系统）

1、理解CAP

CAP是 Consistency、Availability、Partition tolerance三个词语的缩写，分别表示一致性、可用性、分区容忍性。

下边我们分别来解释：

为了方便对CAP理论的理解，我们结合电商系统中的一些业务场景来理解CAP。

如下图，是商品信息管理的执行流程：

整体执行流程如下：

1、商品服务请求主数据库写入商品信息（添加商品、修改商品、删除商品）

2、主数据库向商品服务响应写入成功。

3、商品服务请求从数据库读取商品信息。

C - Consistency：

一致性是指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意结点读取到的数据都是最新的状态。

上图中，商品信息的读写要满足一致性就是要实现如下目标：

1、商品服务写入主数据库成功，则向从数据库查询新数据也成功。

2、商品服务写入主数据库失败，则向从数据库查询新数据也失败。

如何实现一致性？

1、写入主数据库后要将数据同步到从数据库。

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

分布式系统一致性的特点：

1、由于存在数据同步的过程，写操作的响应会有一定的延迟。

2、为了保证数据一致性会对资源暂时锁定，待数据同步完成释放锁定资源。

3、如果请求数据同步失败的结点则会返回错误信息，一定不会返回旧数据。

A - Availability ：

可用性是指任何事务操作都可以得到响应结果，且不会出现响应超时或响应错误。

上图中，商品信息读取满足可用性就是要实现如下目标：

1、从数据库接收到数据查询的请求则立即能够响应数据查询结果。

2、从数据库不允许出现响应超时或响应错误。

如何实现可用性？

1、写入主数据库后要将数据同步到从数据库。

2、由于要保证从数据库的可用性，不可将从数据库中的资源进行锁定。

3、即时数据还没有同步过来，从数据库也要返回要查询的数据，哪怕是旧数据，如果连旧数据也没有则可以按照约定返回一个默认信息，但不能返回错误或响应超时。

分布式系统可用性的特点：

1、 所有请求都有响应，且不会出现响应超时或响应错误。

P - Partition tolerance ：

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

上图中，商品信息读写满足分区容忍性就是要实现如下目标：

1、主数据库向从数据库同步数据失败不影响读写操作。

2、其一个结点挂掉不影响另一个结点对外提供服务。

如何实现分区容忍性？

1、尽量使用异步取代同步操作，例如使用异步方式将数据从主数据库同步到从数据，这样结点之间能有效的实现松耦合。

2、添加从数据库结点，其中一个从结点挂掉其它从结点提供服务。

分布式分区容忍性的特点：

1、分区容忍性分是布式系统具备的基本能力。

2、CAP组合方式

1、上边商品管理的例子是否同时具备 CAP呢？

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

比如：

下图满足了P即表示实现分区容忍：

本图分区容忍的含义是：

1）主数据库通过网络向从数据同步数据，可以认为主从数据库部署在不同的分区，通过网络进行交互。

2）当主数据库和从数据库之间的网络出现问题不影响主数据库和从数据库对外提供服务。

3）其一个结点挂掉不影响另一个结点对外提供服务。

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

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

通过分析发现在满足P的前提下C和A存在矛盾性。

2、CAP有哪些组合方式呢？

所以在生产中对分布式事务处理时要根据需求来确定满足CAP的哪两个方面。

1）AP：

放弃一致性，追求分区容忍性和可用性。这是很多  分布式系统（分布式应用系统）设计时的选择。

例如1：商品管理（主备同步）

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

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

例子2：小米抢购手机

典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

例子3：跨行转账

下面是银行模拟转账业务，用户A（工商银行） 给 用户B（中国银行） 发起一笔转账业务 100元， 用户A调用

工商银行（ServiceA）-100元，在调用 中国银行（ServiceB）给用户B +100，由于ServiceA 调用ServiceB有延时，这时候用户A账号已经少了100元，但是由于延时原因，用户B在立马查询的时候发现账号此刻并未到账100元。

这个场景在 用户提现，支付宝提现，提示2小时到账  （其实是走CP）

Partition Tolerance 【可用性】 收到请求必须相应

同样还是上面银行转账的例子，用户A在工商银行系统-100，在中国银行给用户B加100的操作中，如果要保证用户B已经收到了100元才能查询，那么次数可以把 这个整个操作当做一个整体，只有全部完成的时候才能够对外提供服务。这时候就牺牲了可用性。

所以在分布式环境中，CAP是不能够同时满足的。至于是选择CA CP AP，根据自己的业务需求

在银行系统中， 一致性最重要，数据不能错，CP
在微服务中，系统的可用性，尤其是分布式，可用性尤为重要，没有可用性是跑不起来的 AP

 

例如：

• 同步调用HSF，为了追求可用性A，客户端会有超时时间
• 异步消息MQ，就无法保证一致性P，但是可以保障可用性A

微服务架构中的分布式事务

https://github.com/changmingxie/tcc-transaction

随着传统的单体架的构微服务化，原本单体架构中不同模块，被拆分为若干个功能简单、松耦合的服务。
系统微服务化后，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出。

比如支付退款场景需要从各分账方退回平台收益户(退分账)，再退还给付款方。其中退分账阶段， 涉及从多个分账方(商家1收益户，商家2收益户，商家3收益户，平台手续费账户)扣款，这些账户分布在不同数据库， 比如商家3收益户扣款失败，其他成功扣款需要回滚，这里需要分布式事务保证一致性。 

如何解决

如何解决上面退分账中分布式事务问题呢？ 选择使用tcc-transaction框架，执行流程如下：  （分布式事务-02:2PC 二阶段提交协议实现过程及原理https://cloud.tencent.com/developer/article/1995289）

• Try:
  商家1收益户->冻结分账金额
  商家2收益户->冻结分账金额
  商家3收益户->冻结分账金额
  平台手续费->冻结手续费
• Try成功 => Confirm:
  商家1收益户->扣除分账金额
  商家2收益户->扣除分账金额
  商家3收益户->扣除分账金额
  平台手续费->扣除手续费
  平台收益户-> 增加金额(总分账金额+手续费)
• Try失败 => Cancel:
  商家1收益户->解冻分账金额
  商家2收益户->解冻分账金额
  商家3收益户->解冻分账金额
  平台手续费->解冻手续费

工作原理

第一阶段：主业务服务分别调用所有从业务的 try 操作，并在活动管理器中登记所有从业务服务。当所有从业务服务的 try 操作都调用成功或者某个从业务服务的 try 操作失败，进入第二阶段。
第二阶段：活动管理器根据第一阶段的执行结果来执行 confirm 或 cancel 操作。
如果第一阶段所有 try 操作都成功，则活动管理器调用所有从业务活动的 confirm操作。否则调用所有从业务服务的 cancel 操作。
需要注意的是第二阶段 confirm 或 cancel 操作本身也是满足最终一致性的过程，在调用 confirm 或 cancel 的时候也可能因为某种原因（比如网络）导致调用失败，所以需要活动管理支持重试的能力，同时这也就要求 confirm 和 cancel 操作具有幂等性。

 

MQ分布式事务--本地消息表--基于消息的一致性

1. 上游投递消息

2. 下游获取消息

3. 上游投递稳定性

4. 下游接受稳定性

上游投递消息稳定性

如何保证数据一定能写入到队列，只有保障了投递的稳定性，才能保障流程的正常。

 上层应用在操作订单服务的时候，先将数据写入到临时数据表 Publisher中，另外一部分处理业务逻辑，这部分是一个事务。Publisher表中有一些软状态，成功和失败。表示是否成功写入到消息队列中。

队列数据可靠性

如何保证队列数据不丢失？RabbitMQ—集群&持久化

下游获取消息稳定性

如何保证下游一定获取到数据？Ack 就够了吗？

库存服务通过消息队列中拿到上游给的信息，但同时也有可能失败，比如库存服务宕机，或是网络超时等原因，这时候理应有从试、过期等机制，拿到数据后ACK将数据从消息队列中移除，避免消息队列有脏数据。

作者：MrWu
链接：https://www.jianshu.com/p/c89b4fba863f
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

2）CP：

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

如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。

设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

3）CA：

放弃分区容忍性，即不进行分区，不考虑由于网络不通或结点挂掉的问题，则可以实现一致性和可用性。那么系统将不是一个标准的分布式系统，我们最常用的关系型数据就满足了CA。

上边的商品管理，如果要实现CA则架构如下：

主数据库和从数据库中间不再进行数据同步，数据库可以响应每次的查询请求，通过事务隔离级别实现每个查询请求都可以返回最新的数据。

3、总结

通过上面我们已经学习了CAP理论的相关知识，CAP是一个已经被证实的理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项。它可以作为我们进行架构设计、技术选型的考量标准。对于多数大型互联网应用的场景，结点众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9（99.99..%），并要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择：保证P和A，舍弃C强一致，保证最终一致性。

作者：攀博课堂Java编程 https://www.bilibili.com/read/cv11112175?from=search 出处：bilibili