分布式事务实战--go 语言的 saga 事务

[dongfuye1]

事务

某些业务要求，一系列操作必须全部执行，而不能仅执行一部分。例如，一个转账操作：

-- 从 id=1 的账户给 id=2 的账户转账 100 元
-- 第一步：将 id=1 的 A 账户余额减去 100
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- 第二步：将 id=2 的 B 账户余额加上 100
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

这两条 SQL 语句必须全部执行，或者，由于某些原因，如果第一条语句成功，第二条语句失败，就必须全部撤销。

这种把多条语句作为一个整体进行操作的功能，被称为数据库事务。数据库事务可以确保该事务范围内的所有操作都可以全部成功或者全部失败。如果事务失败，那么效果就和没有执行这些 SQL 一样，不会对数据库数据有任何改动。

更多事务介绍

微服务

如果一个事务涉及的所有操作能够放在一个服务内部，那么使用各门语言里事务相关的库，可以轻松的实现多个操作作为整体的事务操作。

但是有些服务，例如生成订单涉及做很多操作，包括库存、优惠券、赠送、账户余额等。当系统复杂程度增加时，想要把所有这些操作放到一个服务内实现，会导致耦合度太高，维护成本非常高。

针对复杂的系统，当前流行的微服务架构是非常好的解决方案，该架构能够把复杂系统进行拆分，拆分后形成了大量微服务，独立开发，独立维护。

更多微服务介绍

虽然服务拆分了，但是订单本身的逻辑需要多个操作作为一个整体，要么全部成功，要么全部失败，这就带来了新的挑战。如何把散落在各个微服务中的本地事务，组成一个大的事务，保证他们作为一个整体，这就是分布式事务需要解决的问题。

分布式事务

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

更多分布式事务介绍

分布式事务方案包括：

• xa
• tcc
• saga
• 可靠消息

下面我们看看最简单的 xa

XA

XA 是由 X/Open 组织提出的分布式事务的规范，XA 规范主要定义了(全局)事务管理器(TM)和(局部)资源管理器(RM)之间的接口。本地的数据库如 mysql 在 XA 中扮演的是 RM 角色

XA 一共分为两阶段：

第一阶段（ prepare ）：即所有的参与者 RM 准备执行事务并锁住需要的资源。参与者 ready 时，向 TM 报告已准备就绪。 第二阶段 (commit/rollback)：当事务管理者(TM)确认所有参与者(RM)都 ready 后，向所有参与者发送 commit 命令。

目前主流的数据库基本都支持 XA 事务，包括 mysql 、oracle 、sqlserver 、postgre

我们看看本地数据库是如何支持 XA 的：

第一阶段 准备

XA start '4fPqCNTYeSG'
UPDATE `user_account` SET `balance`=balance + 30,`update_time`='2021-06-09 11:50:42.438' WHERE user_id = '1'
XA end '4fPqCNTYeSG'
XA prepare '4fPqCNTYeSG'
-- 当所有的参与者完成了 prepare，就进入第二阶段 提交
xa commit '4fPqCNTYeSG'

xa 实践

介绍了这么多，我们来实践完成一个微服务上的 xa 事务，加深分布式事务的理解，这里采用 dtm 作为分布式事务的管理者，来运行其中一个 xa 的 demo

安装 go 安装 mysql

获取 dtm

git clone https://github.com/yedf/dtm.git
cd dtm

配置 mysql

cp conf.sample.yml conf.yml
vi conf.yml

运行示例

go run app/main.go xa

从日志里，能够找到 XA 部分的输出，最后成功提交完成了事务

# 服务 1 输出
XA start '4fPqCNTYeSG'
UPDATE `user_account` SET `balance`=balance - 30,`update_time`='2021-06-09 11:50:42.438' WHERE user_id = '1'
XA end '4fPqCNTYeSG'
XA prepare '4fPqCNTYeSG'

# 服务 2 输出
XA start '4fPqCPijxyC'
UPDATE `user_account` SET `balance`=balance + 30,`update_time`='2021-06-09 11:50:42.493' WHERE user_id = '2'
XA end '4fPqCPijxyC'
XA prepare '4fPqCPijxyC'

# 服务 1 输出
xa commit '4fPqCNTYeSG'

#服务 2 输出
xa commit '4fPqCPijxyC'

整个交互的时序详情如下

总结

至此，一个完整的 xa 分布式事务介绍完成。 在这篇简短的文章里，我们大致介绍了 事务，分布式事务，微服务处理 XA 事务。有兴趣的同学可以通过dtm 继续研究分布式事务。

不好意思，标题错了，是 XA 事务

[AngryPanda]

XA 还是 saga ？

[NeroKamin]

不是 saga 吗，咋正文里就 XA 了

[ylsc633]

正好我今天也在看这个.. 顺带总结了几个

http://interview.wzcu.com/%E5%88%86%E5%B8%83%E5%BC%8F/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1.html

借道分享一个吧

[aitaii]

这位同学分享的是 xa 吧

[dongfuye1]

sorry，是 XA，已经发布的，貌似不能够撤销了

[dongfuye1]

@ylsc633 你的这个，只能看到一部分，貌似没办法看全

[luoqeng]

以前总结的

2PC 是多 obj 的同时修改的 atomic commit 问题，consensus 一般是同一个 obj 的不同 replica 的一致问题；

在事务的上下文中，一致性（ Consistency ）的概念是：对数据的一组特定陈述必须始终成立。即不变量（ invariants ）。具体到分布式事务的上下文中这个不变量是：所有参与事务的节点状态保持一致：要么全部成功提交，要么全部失败回滚，不会出现一些节点成功一些节点失败的情况。

在分布式系统的上下文中，线性一致性（ Linearizability ）的概念是：多副本的系统能够对外表现地像只有单个副本一样（系统保证从任何副本读取到的值都是最新的），且所有操作都以原子的方式生效（一旦某个新值被任一客户端读取到，后续任意读取不会再返回旧值）。

分布式事务一致性会因为协调者单点引入可用性问题
为了解决可用性问题，分布式事务的节点需要在协调者故障时就新协调者选取达成共识
解决共识问题等价于实现一个线性一致的存储
解决共识问题等价于实现全序广播（ total order boardcast ）
Paxos/Raft 实现了全序广播

分布式事务本身的一致性是通过协调者内部的原子操作与多阶段提交协议保证的，不需要共识；但解决分布式事务一致性带来的可用性问题需要用到共识。

全序广播要求将消息按照相同的顺序，恰好传递一次，准确传送到所有节点。