大家好，欢迎来到停止重构的频道。本期，我们来聊一下数据库事务以及分布式事务。
大家都在强调事务的重要性，而分布式事务也说是微服务必备的。但又说事务会影响性能，分布式事务更是很复杂的东西。使得大家都很迷茫什么时候才该用事务，也不清楚什么场景下，分布式事务才是必要的。
接下来我们将会实打实地讨论实际项目当中，数据库事务、分布式事务的工作原理以及相关的应用场景。
事务说白了就是把多次数据操作打包成一次操作。要么操作都成功，要么都不执行。而事务也分为两种，我们也将对这两种事务分别讨论。
1、数据库事务，一般指的是单个数据库的事务2、分布式事务，一般指的是多个数据库的事务
数据库事务
首先是数据库事务，数据库事务是保证单个数据库下多个数据表的数据一致性问题。也就是不会出现A表更新了数据而B表没更新的状况。数据库事务的工作原理是这样的。请求端发送“开启事务的SQL语句”到数据库以开启事务。
事务开启期间，请求端可发送多条SQL语句以操作数据。数据库会根据事务等级及相关的数据表或数据行阻塞其他数据操作。
操作完毕后，请求端可根据数据操作是否成功以及自身业务要求。决定发送“提交或回滚事务”的SQL语句，以告诉数据库是否将之前操作成功的数据进行回滚。
数据库事务影响数据库性能的原因有两个：
事务操作期间，可能会阻塞其他数据操作，具体需要根据事务等级、相关数据表或数据行而定；
若事务需要回滚，则一般会锁表，阻塞所有操作相关表的数据操作。
数据库事务虽然看上去很复杂，但是在实际开发过程中是简单的。以Spring框架为例，在Service函数中添加事务注解即可，框架会根据数据操作是否出现exception而决定是否回滚。
另外，事务等级是可以选择的。但除非数据的读一致性要求非常强，如账号余额检验等场景。一般情况下，事务等级保持默认就可以了。
那么什么时候使用数据库事务呢，我们的推荐如下：
需要多次数据更新操作的接口，一般需要添加数据库事务
查询与只更新一次数据的接口，且查询的数据读一致性要求非常强，如账号余额校验等场景。则一般添加数据库事务，且事务等级需要调到最高。
分布式事务
接下来是分布式事务，分布式事务是解决多个数据库的数据一致性问题。但分布式事务的实现方式是复杂的。
很多时候，分布式事务是没有必要的。例如，交易时需要同时操作余额数据库与优惠券数据库。其实这是一种过度设计，完全没必要分离出这两个系统。这也是大多数项目的现状，子系统分得太碎了以至于出现很多的分布式事务问题。又例如，博客编写后，自动推送到某个活动专栏或者论坛。这种情况，也是没有必要做分布式事务的。因为如果推送活动或论坛失败，博客仍应该更新，而不能回滚。
其实这也说明了一个问题，数据库事务与分布式事务的区别。除了单个数据库与多个数据库的区别，还有一个更加重要的区别：业务上的区别。
一个数据库内的表是业务关联性较强的，所以数据库事务是频繁的。但是多个数据库间由于所属的业务子系统是不一样的，所以业务关联性是不强的。自然需要分布式事务的场景其实也不多。所以，大多数场景下，需要同时操作多个数据库的话。一般前端整合多个子系统的API即可，或者由一个后端程序调用其他系统的API。当然，分布式事务的场景仍然是存在的。例如，订单与库存系统等。下面我们开始介绍分布式事务的具体方法，分布式事务的理论做法有很多。我们不一一介绍这些理论做法，只介绍实际项目中比较常用的几种具体方法。
XA事务
Seata分布式事务框架
我们常用的流程方式
分布式事务方法：XA事务
首先是XA事务，XA事务是数据库原生支持的分布式事务。
XA事务的工作原理如图所示，可以简单地理解为同时执行多个数据库的数据库事务。XA事务也有相关的操作框架，如JTA等。
XA事务在实现上是相对简单的，但在大型网站系统中，这种方式是不被提倡的。因为它同时阻塞了多个数据库。
同时，XA事务也意味着一个后端程序需要同时操作多个数据库。除非是这多个数据库。存储的是相同类型的数据，如由于用户信息太多而存储在多个数据库中，不然XA事务的应用场景其实不多。
分布式事务方法：Seata框架
接下来是Seata分布式事务框架，Seata的大致工作原理如图所示。Seata需要额外部署事务协调服务作为全局监控的中间件，后端程序需要嵌入Seata的事务管理器、资源管理器等代码。各个后端程序向事务协调服务报告其执行的结果，并根据全局事务的结果决定是否回滚已经操作成功的数据。
由于我们没有在实际项目中应用过这个框架，就不做过多解释了。没有使用的理由并不是它不优秀，之前有个项目也是决定使用的，但是最终没用是因为大多数工程师没弄懂。对于这种技术团队理解上存在门槛的技术，我们一直是慎用的，而且也推动我们设计出了一种更加简单有效流程方式。
分布式事务方法：流程方式
我们常用的分布式事务方法其实是一种流程的思维。因为在实际项目当中，分布式的事务的做法需要符合实际业务流程，而不能简单粗暴地有一条数据操作不成功就全局回滚。比如订单与库存的分布式事务，当订单正常生成后，但库存不足。一般情况下，并不要求订单回滚，而是应该把订单关闭，并记录库存异常，且通知采购。其实大多数的分布式事务场景都是一种流程，所以我们做了一个流程中心。流程中心的数据库记录了各个流程，其他后端程序与流程中心之间通过API调用。由于调度中心是独立子系统，所以即使某个业务子系统宕机，也能记录异常，以方便运营管理员通知运维人员修复。
这种流程中心的做法不仅能解决大多数分布式事务场景，而且能切断子系统与子系统的直接联系。通过流程中心作为调度中心，既能保证各子系统的独立性，也能对一些复杂流程进行统一管理。而不会出现子系统间有缕不清的关系。
当然，这种流程的方式有一种场景是不合适的。就是同类数据分库分区记录的场景，如两个用户记录在不同区域的不同数据库，A用户向B用户转账。对于这种场景，还是XA事务或者使用Seata框架比较合适。
总结
数据库事务或者分布式事务，都只是在防止一些极端情况和某些未发现的bug。很多时候，发生的概率很低，且在测试阶段很难发现。但是，这是系统健壮性的保险机制。如果开发时不注意事务的添加，只会徒增运营成本，且给用户留下各种不稳定的坏印象。
