【20211023】在技术上是如何实现分布式事务的

时间：2021年10月23日

作者：小蒋聊技术

大家好，欢迎来到小蒋聊技术。小蒋准备和大家一起聊聊技术的那些事。

上次小蒋和大家一起聊了“究竟分布式事务要解决什么问题”，接下来咱就得看看“在技术层面上是如何实现分布式事务”的了。

在开始说技术实现前，咱先来看一个分布式事务在现实业务中使用的“场景”。技术的存在目的就是为了解决业务问题，小蒋认为不谈业务场景，纯聊技术就是耍流氓。

电商业务中下单扣减库存

现在电商行业分布式架构简直就是大行其道，用户下单减库存是一个非常常见的场景。那么在电商系统中，下单接口中必定会涉及生成订单 id, 扣减库存等操作。一般来说“订单服务”与“库存服务”通常都被拆分成了两个独立的服务，但也不是没有在一起的，这个不是绝对的，要看每个公司的具体业务情况和技术解决方案。但是，像京东、淘宝、天猫这种比较大的电商公司，无论你是“单体架构”还是“独立的微服务”架构，因为数据量摆在那，数据库肯定是分库了。

分库情况：

 

因此，在分库的情况下，依然需要分布式事务的支持。分布式事务来保证整个下单接口的成功。

独立服务情况：

 

另外，有一些公司本身业务数据量并没有达到非要拆库的量级，放在一起对开发和运维都比较容易。数据库层面只是做了主从分离和高可用。但是，在架构上采用了分布式服务设计，独立了“订单服务”和“库存服务”。此时，还是需要分布式事务，谁让你使用的是分布式架构呢。

独立服务+分库情况：

 

另外还有一种，在分布式架构下，使用的是不同数据库，两个服务相互调用。这种情况下肯定是需要分布式事务的，就不必再想了。

解决方法：

两阶段提交（2PC - Two-Phase-Commit）：

首先，大家要先知道，有一个分布式事务模型DTP（全称为Distributed Transaction Processing Reference Model）和DTP XA规范（全称为Distributed Transaction Processing The XA Specification），他们的制定者是X/Open，后来与Open Software  合并组成了现在的The Open Group。

The Open Group是一个非常厉害的组织。白金会员有Capgemini、HP、IBM、ORACLE等等，其成员大多是ERP和顾问咨询公司，并推出了一系列关于云计算商业应用场景、云计算的参考架构、云计算的投资回报计算方法的优秀白皮书。

DTP这个模型主要使用了两阶段提交来保证分布式事务的完整性，流程如下图所示：

 

DTP模型规定了要实现分布式事务需要三种角色：

1. AP（Application）：服务（微服务）
2. TM（Transaction Manager）：事务管理器
3. RM（Resource Manager）：资源管理器（数据库）

大致流程：

第一阶段（prepare），表决阶段：所有参与者都将自己 的事务进行预提交，并将能否成功的信息反馈给协调者。

1. 事务管理器发一个prepare指令给A和B两个服务。
2. A和B服务收到消息后，根据自身情况，判断自己是否可以提交事务。
3. 将处理结果记录到资源管理器中。
4. 将处理结果返回给事务管理器。

第二阶段（commit/rollback），执行阶段：协调者根据所有参与者的反馈，通知所有参与者，步调一致地执行提交或回滚。

1. 事务管理器向A和B两个服务发送提交指令。
2. A和B服务收到指令后，将自己本身事务提交。
3. 将处理结果记录到资源管理器。
4. 将处理结果返回给事务管理器。

两段式提交提高了数据一致性的概率，实现成本较低。但是这种实现方式缺点也十分明显，咱们来看两阶段提交的流程示意图：

 

总结：

可以从流程图中看出来，两阶段提交是一种尽量保证强一致性的分布式事务，因此它是同步阻塞的，而同步阻塞就导致长久的资源锁定问题，总体而言效率比较低，并且存在单点故障，在极端条件下存在数据不一致的风险。

另外，两阶段提交适用于我们第一种“分库情况”，也就是说适用于数据库层面的分布式事务场景。像Java中的JTA只能解决一个应用下多数据库的分布式事务问题，跨服务就不能用了。

Java中的JTA，它是基于XA规范来实现事务接口的，朋友们可以简单理解为它是基于数据库的一种两阶段提交实现。

以上，是今天技术内容的分享，下次小蒋将会和大家一起来看看另外一种实现分布式事务的方式“三阶段提交”。

培养战略意识

如果你现在是一名工程师，将来想要成为一名架构师，或者你已经是一名架构师了，还想再进一步提升。那么小蒋准备推荐一本书给你。

这本书的名字叫《善战者说》，副标题是孙子兵法与取胜法则十二讲。讲的是孙子兵法在企业竞争当中的应用，作者叫做宫玉振，此人既是一个军事学的博士，又是北京大学国家发展研究院的教授，是一位专门研究孙子兵法，和企业战略的专家。这本书也是颇受商界的好评。

架构师为什么要读一本兵书？为什么要去读一本商业上好评的书呢？

小蒋在刚刚成为架构师的时候，只专注技术的研究，学习各种主流的技术和架构解决方案。但殊不知，这些所谓的高大上的方案根本就无法“落地”。就算我的方案是世界级别的，但是我所在的公司、我所在的团队、我们负责的产品却并不是世界级别的。一个架构师的方案如果不是因地制宜的、量体裁衣的、对症下药的，那这个方案对所在的团队、产品、公司就没有一点价值，一个没有价值的方案，技术再先进又能怎样呢，这是小蒋成为架构师后逐渐意识到的。所以说做一名架构师在做方案时，思维是需要有战略高度的，这也是为什么我推荐大家去读《善战者说》的原因。

我们经常听人说，商场如战场，那么兵法应该完全符合商界法则，孙子兵法之所以能成为一代奇书，主要是因为他探讨的都是道的层面，而不是具体的术，也就是价值观，任何人的成功，基本上都会先有价值观的成功。战争是最强的竞争形态，而孙子兵法就是竞争中基本的取胜法则，所以他告诉你的都是在竞争中取胜的规律。软件中的架构其实也是一样的，软件开发的本质也是一场商业上的战争。

孙子兵法的重点，其实就两句话，第一句是最好不用打就能赢，叫做上兵伐谋，第二句话叫做，如果非要打，那么就用智慧去打，要敢于打，更要会打。以最小的成本，博取最大的胜利。想想软件架构，是不是也是一个道理，是不是一定要开发，如果非要开发，那也要以最小的开发成本，获取产品最大的收益。

孙子兵法是解决战略问题的，那么战略是什么？就是打不打，跟谁打，在哪打，何时打？这些都是战略问题，所谓战术，才是怎么打的问题。有太多人去研究战术，但其实自身却陷入了一场，根本就无法取胜，或者叫做压根就不该打的战斗。这就叫缺乏战略性思考。把资源用错了地方，最后害人害己。

小蒋在读《善战者说》这本书的时候，也意识到孙子能够跳出战争看战争，他虽然是一位将军，但是在他看来，打仗并不是目的，赢才是最终的目标。所以不要为了打仗而去打仗，一定要为了赢采取用兵。这就是最高深的东方智慧。

小蒋从本书中学到了，做一名架构师也是如此，不要为了技术而做架构的调整，赢才是最终目标。

年龄的增长不可怕，可怕的是从未成长！

感谢大家支持小蒋，小蒋希望和大家共同成长，谢谢。

音频地址：【20211023】在技术上是如何实现分布式事务的https://www.ximalaya.com/keji/51588599/465431403