image.png
大家好。在本文中，我们将讨论如何跨微服务进行分布式事务管理。
什么是事务？
事务只是一系列必须成功执行的操作。即使其中一个操作失败，也必须回滚整个步骤，以使应用程序保持之前的稳定状态。事务具有以下ACID属性：
- 原子性(A)：整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
- 一致性(C)：在事务开始之前和事务结束以后，数据库的完整性限制没有被破坏。
- 隔离性(I)：两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时，中间某一时刻的数据。
- 持久性(D)：在事务完成以后，该事务对数据库所作的更改便持久地保存在数据库之中。
单体架构和微服务中事务
在传统的单体应用程序中，会有一个大的应用程序连接到一个大的数据库，这样的应用程序能保持ACID属性。
事务边界从服务层内部开始，可以根据该事务中所有步骤的结果提交或回滚。在微服务架构中，每个微服务运行一个特定的业务领域，并维护独立的代码库原则(SRP)，这意味着每个微服务维护自己的数据库，而另一个服务不应该直接使用另一个服务的数据库。因此，事务分布在微服务中。
示例:让我们考虑下面场景中单体服务和微服务架构的在线订单处理过程。
1、用户将产品添加到电子商务网站上的购物车中并购买。
2、为用户创建订单并生成订单号。
3、当用户购买该产品时，商品库存减少1。
4、生成订单发票。
5、付款成功完成。
6、发票通过电子邮件发送给用户。
在单体应用程序中，所有步骤都在单个应用程序和单个数据库中进行。所有步骤都从一个服务类执行；如果任何步骤失败，整个事务都可以回滚。
在微服务应用程序中，上面的每一个步骤都单独发生在特定的微服务及其特定的数据库中。
- 订单将在Order服务中处理。
- 在帐户服务中检查和计算库存。
- 发票由发票服务处理。
- 付款在Payment服务中处理。
- 电子邮件由通知服务触发。
由于每个步骤都在不同的微服务及其数据库中运行，因此为整个事务维护ACID原则是极其困难和复杂的。如果可能的话，最好完全避免分布式事务管理。否则，有一些用于分布式事务管理的标准模式。
1、同步模式
- 两阶段提交
- 3阶段提交
2、异步模式
- Soga模式
两阶段模式
2阶段提交是处理分布式事务的标准协议，使用2个阶段，即准备阶段和提交阶段。有一个事务协调器组件，它通过与所有服务通信来协调整个事务。
成功情况：
1、事务协调器指示每个服务准备提交，然后每个服务检查是否可以毫无问题地完成提交。
2、检查后，每个服务向协调器发送一个Prepared响应。
3、一旦协调器接收到所有Prepared响应，它就通知所有服务将数据提交到数据库中。
4、事务成功了，所有更改都跨服务提交了
回滚情况：
1、事务协调器指示每个服务准备提交，然后每个服务检查提交是否可以顺利完成。
2、检查之后，假设有一个服务响应失败状态。
3、协调器将发送一个中止命令来中止事务，以回滚事务中执行的任何更改，维护ACID原则。
两阶段提交的缺点：
1、它非常慢，因为协调器要等待所有微服务响应，事务需要很长时间才能提交。
2、在发出commit或abort命令之前，每个DB中的数据都会被锁定。这些锁将使系统变慢，并导致性能下降。
3阶段提交
两阶段提交协议不能从提交阶段协调器和其中一个微服务失败中恢复。
3阶段提交是2阶段提交的扩展，把提交阶段分为2个阶段。3阶段提交是为了在协调器或任何其他服务出现故障时使用准备提交阶段进行容错而设计的。
针对两阶段提交存在的问题，三阶段提交协议通过引入一个 预询问 阶段，以及超时策略来减少整个集群的阻塞时间，提升系统性能。三阶段提交的三个阶段分别为：预询问（can commit）、预提交（precommit），以及事务提交（commit）。
1、如果事务协调器在向微服务发送prepare -to-commit命令之前失败，那么其他服务将认为操作已终止。
2、协调器不会向所有服务发送doCommit消息，直到它们发送了准备提交的ACK。
3、这将确保没有任何服务被阻塞并等待其他服务。
失败提交情况
1、在提交阶段，当协调器或服务或两者都失败时，预提交阶段有助于系统恢复。
2、在提交阶段协调程序失败后，当新的事务协调程序接管时，它将查询所有服务，以查看它们所处的状态。
3、如果服务处于提交阶段，那么新的协调器将知道前一个协调器在崩溃之前发出了提交命令。
4、如果任何服务没有接收到准备提交命令，那么新的协调器将知道前一个协调器在完成准备提交阶段之前已经崩溃。
5、因此，它可以安全地中止事务。
3阶段提交缺点
- 必须确保网络分区不会导致事务不一致。
- 增加了协调步骤资源消耗更大。
网友评论