3.2 分布式事务（二）分布式事务方案

---

---

1. 概述

普通的事务可以理解为一个单体应用多人同时操作数据库产生：

而分布式事务则是多人同时操作多个嵌套服务的数据库关系：

在微服务系统中，每个微服务应用都可能会有自己的数据库，它们首先需要控制自己的本地事务。

一项业务操作可能会调用执行多个微服务。如何保证多个服务执行的多个数据库的操作整体成功或整体失败？这就是分布式事务要解决的问题。

2.解决概念

目前市面上共有俩种解决理念，分别为CAP 和 BASE；CAP 和 BASE是对大规模互联网系统分布式实践的理论总结，如果没有实践为基础理论则难以理解。

这里建议先对分布式事务进行实践，之后再来阅读理论来互相印证。

2.1 CAP

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

可用性（A）：保证每个请求不管成功或者失败都有响应。

分区容忍性（P）：系统中任意信息的丢失或失败不会影响系统的继续运作。

下面是关于百度百科对CAP的介绍：

在分布式系统中，由于网络原因出现子系统之间无法通信的情况，就会造成分区。一般分布式系统中必须容忍这种情况，那么就需要在A和C之间进行取舍。

在分布式事务中，

如果保证CP，就意味着要让所有子系统的数据操作要么全部成功，要么全部失败，不允许有不一致的情况发生。但是强一致性会造成性能下降。

如果保证AP，就意味着可以牺牲一定的一致性，允许在各个子系统中存在有的数据操作成功，有的数据操作失败的情况，只要通过后续处理，能够达到最终一致即可。

2.2 BASE

下面是关于百度百科对BASE的介绍：

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。

BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。接下来我们着重对BASE中的三要素进行详细讲解。基本可用：指分布式系统在出现不可预知故障的时候，允许损失部分可用性。

注意，这绝不等价于系统不可用，以下两个就是“基本可用”的典型例子：

• 响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
• 功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。
• 弱状态：也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
• 最终一致性：强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

2.3 解决方案

分布式事务有以下解决方案：

• XA
• TCC
• Seata 框架 AT 事务
• SAGA
• 可靠消息最终一致性
• 最大努力通知

后面我们会对 Seata 框架 AT 事务、TCC 和 可靠消息最终一致性 三个方案进行实践。