分布式事务

一、什么是分布式事务

事务的具体定义-数据库本地事务-数据库事务中的四大特性 ACID-InnoDB 实现原理

事务的 ACID 是通过 InnoDB 日志和锁来保证。事务的隔离性是通过数据库锁的机制实现的，持久性通过 Redo Log（重做日志）来实现，原子性和一致性通过 Undo Log 来实现。

简单地说，事务提供一种“要么什么都不做，要么做全套（All or Nothing）”机制。

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

二、分布式事务产生的原因/分布式事务的应用场景

从上面本地事务来看，我们可以分为两块：

Service 产生多个节点
Resource 产生多个节点

**Service 多个节点**

随着互联网快速发展，微服务，SOA 等服务架构模式正在被大规模的使用。

举个简单的例子，一个公司之内，用户的资产可能分为好多个部分，比如余额，积分，优惠券等等。

在公司内部有可能积分功能由一个微服务团队维护，优惠券又是另外的团队维护。


这样的话就无法保证积分扣减了之后，优惠券能否扣减成功。

**Resource多个节点**

同样的，互联网发展得太快了，我们的 MySQL 一般来说装***的数据就得进行分库分表。

对于一个支付宝的转账业务来说，你给朋友转钱，有可能你的数据库是在北京，而你的朋友的钱是存在上海，所以我们依然无法保证他们能同时成功。

三、分布式事务的基础/理论

从上面来看分布式事务是随着互联网高速发展应运而生的，这是一个必然。

我们之前说过数据库的 ACID 四大特性，已经无法满足我们分布式事务，这个时候又有一些新的大佬提出一些新的理论。

**CAP**

CAP 定理，又被叫作布鲁尔定理。对于设计分布式系统(不仅仅是分布式事务)的架构师来说，CAP 就是你的入门理论。

**BASE**

BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写，是对 CAP 中 AP 的一个扩展。

基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。

软状态：允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是 CAP 中的不一致。

最终一致：最终一致是指经过一段时间后，所有节点数据都将会达到一致。

CAP/BASE

BASE 解决了 CAP 中理论没有网络延迟，在 BASE 中用软状态和最终一致，保证了延迟后的一致性。

BASE 和 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

四、分布式事务解决方案

有了上面的理论基础后，这里开始介绍几种常见的分布式事务的解决方案。【各个方案的说明、优点、缺点】

**2PC**

说到 2PC 就不得不聊数据库分布式事务中的 XA Transactions。

总的来说，XA 协议比较简单，成本较低，但是其单点问题，以及不能支持高并发(由于同步阻塞)依然是其***的弱点

**TCC**

关于 TCC（Try-Confirm-Cancel）的概念，最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions：an Apostate’s Opinion》的论文提出。

对于 TCC 来说适合一些：

强隔离性，严格一致性要求的活动业务。
执行时间较短的业务。

原文：
https://developer.51cto.com/art/201808/581174.htm