漫画：什么是分布式事务？

àì夳堔傛蜴生んèń 2022-05-21 00:29 329阅读 0赞

![640?wx\_fmt=jpeg&wxfrom=5&wx\_lazy=1][640_wx_fmt_jpeg_wxfrom_5_wx_lazy_1]

![640?wx\_fmt=jpeg&wxfrom=5&wx\_lazy=1][640_wx_fmt_jpeg_wxfrom_5_wx_lazy_1 1]

—————  第二天  —————

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 1]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 2]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 3]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 4]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 5]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 6]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 7]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 8]

————————————

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 9]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 10]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 11]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 12]

假如没有分布式事务

在一系列微服务系统当中，假如不存在分布式事务，会发生什么呢？让我们以互联网中常用的交易业务为例子：

![640?wx\_fmt=png][640_wx_fmt_png]

上图中包含了库存和订单两个独立的微服务，每个微服务维护了自己的数据库。在交易系统的业务逻辑中，一个商品在下单之前需要先调用库存服务，进行扣除库存，再调用订单服务，创建订单记录。

正常情况下，两个数据库各自更新成功，两边数据维持着一致性。

![640?wx\_fmt=png][640_wx_fmt_png 1]

但是，在非正常情况下，有可能库存的扣减完成了，随后的订单记录却因为某些原因插入失败。这个时候，两边数据就失去了应有的一致性。

![640?wx\_fmt=png][640_wx_fmt_png 2]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 13]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 14]

什么是分布式事务？

分布式事务用于在分布式系统中保证不同节点之间的数据一致性。分布式事务的实现有很多种，最具有代表性的是由Oracle Tuxedo系统提出的XA分布式事务协议。

XA协议包含两阶段提交（2PC）和三阶段提交（3PC）两种实现，这里我们重点介绍两阶段提交的具体过程。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 15]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 16]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 17]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 18]

在魔兽世界这款游戏中，副本组团打BOSS的时候，为了更方便队长与队员们之间的协作，队长可以发起一个“就位确认”的操作：

![640?wx\_fmt=png][640_wx_fmt_png 3]

当队员收到就位确认提示后，如果已经就位，就选择“是”，如果还没就位，就选择“否”。

![640?wx\_fmt=png][640_wx_fmt_png 4]

当队长收到了所有人的就位确认，就会向所有队员们发布消息，告诉他们开始打BOSS。

![640?wx\_fmt=png][640_wx_fmt_png 5]

相应的，在队长发起就位确认的时候，有可能某些队员还并没有就位：

![640?wx\_fmt=png][640_wx_fmt_png 3]

![640?wx\_fmt=png][640_wx_fmt_png 6]

![640?wx\_fmt=png][640_wx_fmt_png 7]

以上就是魔兽世界当中组团打BOSS的确认流程。这个流程和XA分布式事务协议的两阶段提交非常相似。

那么XA协议究竟是什么样子呢？在XA协议中包含着两个角色：事务协调者和事务参与者。让我们来看一看他们之间的交互流程：

第一阶段：

![640?wx\_fmt=png][640_wx_fmt_png 8]

在XA分布式事务的第一阶段，作为事务协调者的节点会首先向所有的参与者节点发送Prepare请求。

在接到Prepare请求之后，每一个参与者节点会各自执行与事务有关的数据更新，写入Undo Log和Redo Log。如果参与者执行成功，暂时不提交事务，而是向事务协调节点返回“完成”消息。

当事务协调者接到了所有参与者的返回消息，整个分布式事务将会进入第二阶段。

第二阶段：

![640?wx\_fmt=png][640_wx_fmt_png 9]

在XA分布式事务的第二阶段，如果事务协调节点在之前所收到都是正向返回，那么它将会向所有事务参与者发出Commit请求。

接到Commit请求之后，事务参与者节点会各自进行本地的事务提交，并释放锁资源。当本地事务完成提交后，将会向事务协调者返回“完成”消息。

当事务协调者接收到所有事务参与者的“完成”反馈，整个分布式事务完成。

以上所描述的是XA两阶段提交的正向流程，接下来我们看一看失败情况的处理流程：

第一阶段：

![640?wx\_fmt=png][640_wx_fmt_png 10]

第二阶段：

![640?wx\_fmt=png][640_wx_fmt_png 11]

在XA的第一阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚。

于是在第二阶段，事务协调节点向所有的事务参与者发送Abort请求。接收到Abort请求之后，各个事务参与者节点需要在本地进行事务的回滚操作，回滚操作依照Undo Log来进行。

以上就是XA两阶段提交协议的详细过程。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 19]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 20]

XA两阶段提交的不足

XA两阶段提交究竟有哪些不足呢？

1.性能问题

XA协议遵循强一致性。在事务执行过程中，各个节点占用着数据库资源，只有当所有节点准备完毕，事务协调者才会通知提交，参与者提交后释放资源。这样的过程有着非常明显的性能问题。

2.协调者单点故障问题

事务协调者是整个XA模型的核心，一旦事务协调者节点挂掉，参与者收不到提交或是回滚通知，参与者会一直处于中间状态无法完成事务。

3.丢失消息导致的不一致问题。

在XA协议的第二个阶段，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。

如果避免XA两阶段提交的种种问题呢？有许多其他的分布式事务方案可供选择：

1.XA三阶段提交

XA三阶段提交在两阶段提交的基础上增加了CanCommit阶段，并且引入了超时机制。一旦事物参与者迟迟没有接到协调者的commit请求，会自动进行本地commit。这样有效解决了协调者单点故障的问题。但是性能问题和不一致的问题仍然没有根本解决。

2.MQ事务

利用消息中间件来异步完成事务的后一半更新，实现系统的最终一致性。这个方式避免了像XA协议那样的性能问题。

3.TCC事务

TCC事务是Try、Commit、Cancel三种指令的缩写，其逻辑模式类似于XA两阶段提交，但是实现方式是在代码层面来人为实现。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 21]

几点补充：

.本漫画纯属娱乐，还请大家尽量珍惜当下的工作，切勿模仿小灰的行为哦。

**参考文献:**

![640?wx\_fmt=jpeg&wxfrom=5&wx\_lazy=1][640_wx_fmt_jpeg_wxfrom_5_wx_lazy_1]

![640?wx\_fmt=jpeg&wxfrom=5&wx\_lazy=1][640_wx_fmt_jpeg_wxfrom_5_wx_lazy_1 1]

—————  第二天  —————

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 1]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 2]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 3]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 4]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 5]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 6]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 7]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 8]

————————————

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 9]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 10]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 11]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 12]

假如没有分布式事务

在一系列微服务系统当中，假如不存在分布式事务，会发生什么呢？让我们以互联网中常用的交易业务为例子：

![640?wx\_fmt=png][640_wx_fmt_png]

正常情况下，两个数据库各自更新成功，两边数据维持着一致性。

![640?wx\_fmt=png][640_wx_fmt_png 1]

但是，在非正常情况下，有可能库存的扣减完成了，随后的订单记录却因为某些原因插入失败。这个时候，两边数据就失去了应有的一致性。

![640?wx\_fmt=png][640_wx_fmt_png 2]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 13]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 14]

什么是分布式事务？

XA协议包含两阶段提交（2PC）和三阶段提交（3PC）两种实现，这里我们重点介绍两阶段提交的具体过程。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 15]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 16]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 17]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 18]

在魔兽世界这款游戏中，副本组团打BOSS的时候，为了更方便队长与队员们之间的协作，队长可以发起一个“就位确认”的操作：

![640?wx\_fmt=png][640_wx_fmt_png 3]

当队员收到就位确认提示后，如果已经就位，就选择“是”，如果还没就位，就选择“否”。

![640?wx\_fmt=png][640_wx_fmt_png 4]

当队长收到了所有人的就位确认，就会向所有队员们发布消息，告诉他们开始打BOSS。

![640?wx\_fmt=png][640_wx_fmt_png 5]

相应的，在队长发起就位确认的时候，有可能某些队员还并没有就位：

![640?wx\_fmt=png][640_wx_fmt_png 3]

![640?wx\_fmt=png][640_wx_fmt_png 6]

![640?wx\_fmt=png][640_wx_fmt_png 7]

以上就是魔兽世界当中组团打BOSS的确认流程。这个流程和XA分布式事务协议的两阶段提交非常相似。

那么XA协议究竟是什么样子呢？在XA协议中包含着两个角色：事务协调者和事务参与者。让我们来看一看他们之间的交互流程：

第一阶段：

![640?wx\_fmt=png][640_wx_fmt_png 8]

在XA分布式事务的第一阶段，作为事务协调者的节点会首先向所有的参与者节点发送Prepare请求。

当事务协调者接到了所有参与者的返回消息，整个分布式事务将会进入第二阶段。

第二阶段：

![640?wx\_fmt=png][640_wx_fmt_png 9]

在XA分布式事务的第二阶段，如果事务协调节点在之前所收到都是正向返回，那么它将会向所有事务参与者发出Commit请求。

接到Commit请求之后，事务参与者节点会各自进行本地的事务提交，并释放锁资源。当本地事务完成提交后，将会向事务协调者返回“完成”消息。

当事务协调者接收到所有事务参与者的“完成”反馈，整个分布式事务完成。

以上所描述的是XA两阶段提交的正向流程，接下来我们看一看失败情况的处理流程：

第一阶段：

![640?wx\_fmt=png][640_wx_fmt_png 10]

第二阶段：

![640?wx\_fmt=png][640_wx_fmt_png 11]

在XA的第一阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚。

以上就是XA两阶段提交协议的详细过程。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 19]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 20]

XA两阶段提交的不足

XA两阶段提交究竟有哪些不足呢？

1.性能问题

2.协调者单点故障问题

事务协调者是整个XA模型的核心，一旦事务协调者节点挂掉，参与者收不到提交或是回滚通知，参与者会一直处于中间状态无法完成事务。

3.丢失消息导致的不一致问题。

如果避免XA两阶段提交的种种问题呢？有许多其他的分布式事务方案可供选择：

1.XA三阶段提交

2.MQ事务

利用消息中间件来异步完成事务的后一半更新，实现系统的最终一致性。这个方式避免了像XA协议那样的性能问题。

3.TCC事务

TCC事务是Try、Commit、Cancel三种指令的缩写，其逻辑模式类似于XA两阶段提交，但是实现方式是在代码层面来人为实现。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 21]

几点补充：

.本漫画纯属娱乐，还请大家尽量珍惜当下的工作，切勿模仿小灰的行为哦。

https://blog.csdn.net/bjweimengshu/article/details/79607522

![640?wx\_fmt=jpeg&wxfrom=5&wx\_lazy=1][640_wx_fmt_jpeg_wxfrom_5_wx_lazy_1]

![640?wx\_fmt=jpeg&wxfrom=5&wx\_lazy=1][640_wx_fmt_jpeg_wxfrom_5_wx_lazy_1 1]

—————  第二天  —————

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 1]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 2]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 3]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 4]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 5]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 6]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 7]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 8]

————————————

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 9]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 10]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 11]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 12]

假如没有分布式事务

在一系列微服务系统当中，假如不存在分布式事务，会发生什么呢？让我们以互联网中常用的交易业务为例子：

![640?wx\_fmt=png][640_wx_fmt_png]

正常情况下，两个数据库各自更新成功，两边数据维持着一致性。

![640?wx\_fmt=png][640_wx_fmt_png 1]

但是，在非正常情况下，有可能库存的扣减完成了，随后的订单记录却因为某些原因插入失败。这个时候，两边数据就失去了应有的一致性。

![640?wx\_fmt=png][640_wx_fmt_png 2]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 13]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 14]

什么是分布式事务？

XA协议包含两阶段提交（2PC）和三阶段提交（3PC）两种实现，这里我们重点介绍两阶段提交的具体过程。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 15]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 16]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 17]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 18]

在魔兽世界这款游戏中，副本组团打BOSS的时候，为了更方便队长与队员们之间的协作，队长可以发起一个“就位确认”的操作：

![640?wx\_fmt=png][640_wx_fmt_png 3]

当队员收到就位确认提示后，如果已经就位，就选择“是”，如果还没就位，就选择“否”。

![640?wx\_fmt=png][640_wx_fmt_png 4]

当队长收到了所有人的就位确认，就会向所有队员们发布消息，告诉他们开始打BOSS。

![640?wx\_fmt=png][640_wx_fmt_png 5]

相应的，在队长发起就位确认的时候，有可能某些队员还并没有就位：

![640?wx\_fmt=png][640_wx_fmt_png 3]

![640?wx\_fmt=png][640_wx_fmt_png 6]

![640?wx\_fmt=png][640_wx_fmt_png 7]

以上就是魔兽世界当中组团打BOSS的确认流程。这个流程和XA分布式事务协议的两阶段提交非常相似。

那么XA协议究竟是什么样子呢？在XA协议中包含着两个角色：事务协调者和事务参与者。让我们来看一看他们之间的交互流程：

第一阶段：

![640?wx\_fmt=png][640_wx_fmt_png 8]

在XA分布式事务的第一阶段，作为事务协调者的节点会首先向所有的参与者节点发送Prepare请求。

当事务协调者接到了所有参与者的返回消息，整个分布式事务将会进入第二阶段。

第二阶段：

![640?wx\_fmt=png][640_wx_fmt_png 9]

在XA分布式事务的第二阶段，如果事务协调节点在之前所收到都是正向返回，那么它将会向所有事务参与者发出Commit请求。

接到Commit请求之后，事务参与者节点会各自进行本地的事务提交，并释放锁资源。当本地事务完成提交后，将会向事务协调者返回“完成”消息。

当事务协调者接收到所有事务参与者的“完成”反馈，整个分布式事务完成。

以上所描述的是XA两阶段提交的正向流程，接下来我们看一看失败情况的处理流程：

第一阶段：

![640?wx\_fmt=png][640_wx_fmt_png 10]

第二阶段：

![640?wx\_fmt=png][640_wx_fmt_png 11]

在XA的第一阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成功，必须回滚。

以上就是XA两阶段提交协议的详细过程。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 19]

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 20]

XA两阶段提交的不足

XA两阶段提交究竟有哪些不足呢？

1.性能问题

2.协调者单点故障问题

事务协调者是整个XA模型的核心，一旦事务协调者节点挂掉，参与者收不到提交或是回滚通知，参与者会一直处于中间状态无法完成事务。

3.丢失消息导致的不一致问题。

如果避免XA两阶段提交的种种问题呢？有许多其他的分布式事务方案可供选择：

1.XA三阶段提交

2.MQ事务

利用消息中间件来异步完成事务的后一半更新，实现系统的最终一致性。这个方式避免了像XA协议那样的性能问题。

3.TCC事务

TCC事务是Try、Commit、Cancel三种指令的缩写，其逻辑模式类似于XA两阶段提交，但是实现方式是在代码层面来人为实现。

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 21]

几点补充：

.本漫画纯属娱乐，还请大家尽量珍惜当下的工作，切勿模仿小灰的行为哦。

[640_wx_fmt_jpeg_wxfrom_5_wx_lazy_1]: https://img-blog.csdnimg.cn/img_convert/c8971401b8a8ba8ac4e9c111e248e863.png;wxfrom=5&wx_lazy=1
[640_wx_fmt_jpeg_wxfrom_5_wx_lazy_1 1]: https://img-blog.csdnimg.cn/img_convert/10977b28b9cff5f53ec834b79ca0b078.png;wxfrom=5&wx_lazy=1
[640_wx_fmt_jpeg]: /images/20220521/4460ed78d58248b8adefa7336578d6c0.png
[640_wx_fmt_jpeg 1]: /images/20220521/0ee26e6192564376bdba316d28fca495.png
[640_wx_fmt_jpeg 2]: /images/20220521/2cc1a2a601e24d42bd7d2704245f2361.png
[640_wx_fmt_jpeg 3]: /images/20220521/0c37f932b5da4fc8a14e67ca34da43bb.png
[640_wx_fmt_jpeg 4]: /images/20220521/21168a104a8e423989e68630fa409f4b.png
[640_wx_fmt_jpeg 5]: /images/20220521/4331a83904b0444e941107d615fb84a8.png
[640_wx_fmt_jpeg 6]: /images/20220521/1f73ed67692e451cb98380824df9af43.png
[640_wx_fmt_jpeg 7]: /images/20220521/47ad93a9665140cbb74eb9e23a88e36c.png
[640_wx_fmt_jpeg 8]: /images/20220521/ba4fea34b9f64ff19071b1864aa52e07.png
[640_wx_fmt_jpeg 9]: /images/20220521/931e2b3d71f44ac7b7aa80dfb9c99638.png
[640_wx_fmt_jpeg 10]: /images/20220521/8ac5be1a7c29452f9cd9f67257b38097.png
[640_wx_fmt_jpeg 11]: /images/20220521/6288de79acdb44c9a2729ec8926373c4.png
[640_wx_fmt_jpeg 12]: /images/20220521/decc6aa475794257b59e1586f92fd849.png
[640_wx_fmt_png]: /images/20220521/a6da4c1290954ba593fa9a474647c080.png
[640_wx_fmt_png 1]: /images/20220521/25a4ee398c2542c8b46da4642a4d324f.png
[640_wx_fmt_png 2]: /images/20220521/26bc19fdc02b4fdd903560e456f388f3.png
[640_wx_fmt_jpeg 13]: /images/20220521/e021154b6aa34a4dbcbd43a4d8cece02.png
[640_wx_fmt_jpeg 14]: /images/20220521/c591c18a451b41e281649822025912c3.png
[640_wx_fmt_jpeg 15]: /images/20220521/57bddfeadb6e4b6e99cbab4e64d23c13.png
[640_wx_fmt_jpeg 16]: /images/20220521/e1111384cdff49888a77e0426229a4e6.png
[640_wx_fmt_jpeg 17]: /images/20220521/4c1da45461ab443085152b0488044e18.png
[640_wx_fmt_jpeg 18]: /images/20220521/b70ad691c2a9411a92d0913811781bfc.png
[640_wx_fmt_png 3]: /images/20220521/22354d7a74a14064a860781ac73f7992.png
[640_wx_fmt_png 4]: /images/20220521/467ec7fa066f40ea96ada4e3a1b4a54a.png
[640_wx_fmt_png 5]: /images/20220521/9d64f48239344c8486274429886d81a7.png
[640_wx_fmt_png 6]: /images/20220521/6b082c8bf8364636bbf1b315f25645ff.png
[640_wx_fmt_png 7]: /images/20220521/740c5a0af7e44acf86d992397c493d2e.png
[640_wx_fmt_png 8]: /images/20220521/4775a5b7825a4a049f351625a6b016c3.png
[640_wx_fmt_png 9]: /images/20220521/9ec7357cc2b24df59ef1122756dede96.png
[640_wx_fmt_png 10]: /images/20220521/7a22e41e0a654d9d905321e7977a124b.png
[640_wx_fmt_png 11]: /images/20220521/aad088a35d454d93816079b365ed0a01.png
[640_wx_fmt_jpeg 19]: /images/20220521/816f2fb1b6a14d6f9e068ee825a0b4ea.png
[640_wx_fmt_jpeg 20]: /images/20220521/4ba67d784aa74c719449745dc8e3517c.png
[640_wx_fmt_jpeg 21]: /images/20220521/3822e98c3417494887645a45055978a9.png