Spring Cloud Alibaba 一致性挑战：微服务架构下的数据一致性解决方案

本讲咱们填之前埋下的一个坑，如何在微服务架构下有效保障数据一致性问题。本讲咱们涉及三方面内容：

• CAP 原则与 BASE 定理；

• TCC 一致性解决方案；

• Seata TCC 模式。

首先咱们了解什么是 CAP 原则与 BASE 定理。

CAP 原则与 BASE 定理

CAP 原则

CAP 是Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性）的首字母组合，它是所有分布式系统在设计前设计师必须优先考虑的事情。

• 一致性 C 代表更新操作成功后，所有节点在同一时间的数据完全一致。

• 可用性 A 代表用户访问数据时，系统是否能在正常响应时间返回预期的结果。

• 分区容错性 P 代表分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。

CAP 是新人比较难理解的知识，我们通过实际案例进行说明。以订单系统与库存系统为例，

在实际业务中订单的创建会伴随着库存的减少，在原本单体架构中，这是一个应用中的两个模块，但随着业务发展库存模块压力增加，架构师就将其剥离为新的库存系统，库存数据也存放在单独的数据库中，两个系统间通过网络进行通信，架构模式自然也转为分布式。但与此同时，加入网络通信后系统故障概率也在增加，架构师必须考虑应用“分区”后的容错性问题，这就是 CAP 中的 P 分区容错性的含义，分区容错性是任何分布式系统必须包含的因素。

那么如何后续处理呢？有两种方案：

• 第一种，放弃 C 一致性保障 A 可用性，简称 AP。具体表现为产生通信故障后，应用会完成新增订单放弃减少库存的操作，应用立即返回响应，并在响应中说明具体处理的细节，这种方案用户会有更好的体验，但数据层面是不完整的，需要后续补偿。

• 第二种，放弃 A 可用性保障一致性 C，简称 CP。具体表现为产生通信故障后，应用会进入阻塞状态，一直尝试与库存系统恢复通信直到完成所有数据处理。这种方案是优先保障数据完整性，但此方案用户体验极差，因为在所有操作完成前用户会一直处于等待的状态。

我们发现，CAP 本身就是互斥的，只能三者选两个，对于 CA、AP、CP 都有它们自己的应用场景，要结合实际进行选择。例如，CA 因为不考虑分区容忍度，所以它所有操作需要在同一进程内完成（也就是我们常说的单体应用）；AP 因为放弃数据一致性，适合数据要求不高但强调用户体验的项目，如博客、新闻资讯等；CP 反之放弃了可用性，适合数据要求很高的交易系统，如银行交易、电商的订单交易等，就算是用户长时间等待，也要保障数据的完整可靠。

以上就是 CAP 原则在实际项目中的运用，对于互联网应用来说，如果为了用户体验完全放弃数据一致性这也是不可取的，毕竟数据才是根本。那怎么解决呢？这又衍生出一个新的理论：BASE 定理。

BASE 定理

BASE 定理是Basically Available(基本可用)，Soft State（软状态）和**Eventually Consistent（最终一致性）**三个短语的缩写。BASE 是对 CAP 中一致性和可用性权衡后的选择，其来源于对大规模互联网系统分布式实践的结论，是基于 CAP 定理逐步演化而来的，其核心思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

在刚才案例中，订单与库存系统通信故障时，架构师选择AP方案保障了用户的响应速度，此时订单创建但库存并没有减少，这就是不一致的情况。为了解决这种问题，很多项目会写一个任务线程定时检查通信状态，当通信恢复后该任务会通知库存系统完成减库存的处理，使数据保持一致。

BASE 允许存在软状态，所谓软状态就是在上述案例中订单增加但库存没有减少时的中间状态，后续的补救措施中任务线程对库存进行补偿，此时数据最终做到了的一致，此时的状态就是最终一致性状态。BASE 定理只要求保障数据是最终一致的，因此存在中间的软状态。

保障最终一致性的措施有很多，如 TCC、任务定时检查、MQ