转载请注明来源：janrs.com/bkt7

在这篇文章中，我们将看到关于跨微服务的分布式事务管理。

什么是事务

一个事务不过是一系列必须成功执行的操作。即使其中一个操作失败了，整个步骤也必须回滚，以使应用程序处于之前的稳定状态。一个事务具有以下ACID属性。

单体架构和微服务中的事务

在传统的单片机应用程序中，将有一个单一的大型应用程序连接到一个大型数据库，这种应用程序坚持ACID属性。

事务边界从服务层内部开始，可以根据该事务中所有步骤的结果进行提交或回滚。在微服务的情况下，每个微服务运行一个特定的业务领域，并保持单一仓库原则（SRP），这意味着每个微服务保持自己的数据库，另一个服务不应该直接使用其他服务的数据库。因此，事务是分布在各个微服务中的。

例子。让我们考虑一个在线订单处理的单体架构和微服务架构的以下情况

1. 用户在电子商务网站上将产品加入购物车并购买
2. 为用户创建一个订单，并生成一个订单号
3. 由于用户购买了该产品，该项目库存减少了1
4. 为该项目生成一张发票
5. 付款已成功完成
6. 发票通过电子邮件发送给用户

在单体架构中，所有的步骤都发生在一个单一的应用程序和单一的数据库中。所有的步骤都从一个服务类中执行；如果任何一个步骤失败，整个事务都可以回滚。

在微服务应用程序的情况下，上述每个步骤都是在特定的微服务和其特定的数据库中单独进行的

• 订单将在订单服务中被处理
• 库存在账户服务中被检查和计算
• 发票由发票服务处处理
• 支付服务中处理支付问题
• 电子邮件是由通知服务触发的

由于每个步骤都在不同的微服务及其数据库内运行，为整个事务维护ACID原则是非常困难和复杂的。如果可能的话，最好是完全避免分布式事务管理。

如果没有，那么有一些分布式事务管理的标准模式。

分布式事务管理的模式

1. Synchronous Patterns - 同步模式

   • Two-Phase Commit - 2阶段提交[2PC]
   • Three Phase Commit - 3阶段提交[3PC]

2. Asynchronous Pattern - 异步模式

   • Orchestration-Based Saga Pattern
   • Choreography-Based Saga Pattern

Synchronous Patterns 同步模式

Two-Phase Commit (2 PC) 2阶段提交

2阶段提交是一个标准协议，使用2个阶段即准备阶段和提交阶段来处理分布式交易。有一个交易协调器组件，通过与所有服务对话来协调整个交易

成功的情况

1. 事务协调器指示每个服务准备提交，然后每个服务检查是否可以顺利提交。
2. 在检查之后，每个服务向协调者发送一个准备好的响应。
3. 一旦协调人收到所有准备好的响应，它就会告诉所有服务将数据提交到数据库。
4. 现在交易成功了，所有的变化都在服务中被提交。

回滚的情况

1. 事务协调器指示每个服务准备提交，然后每个服务检查是否可以顺利提交。
2. 经过检查，想象一下，一个服务的响应状态是失败的
3. 协调人将发送一个中止命令来中止交易，以回滚在交易中执行的任何变化，以保持ACID原则。

2PC的缺点

1. 它非常慢，因为协调者在等待所有的响应，交易需要很长时间才能提交。
2. 每个数据库中的数据都被锁定，直到发出提交或终止命令。这些锁会降低系统的速度，导致性能下降。

Three Phase Commit (3 PC) 3阶段提交

一个两阶段的提交协议不能从协调者和同组成员在提交阶段的失败中恢复。

3 PC是2阶段提交的延伸，提交阶段被分为2个阶段。3阶段提交是为了在协调器或任何其他服务发生故障时，通过使用准备提交阶段来实现容错。

成功的场景

1. 如果交易协调器在向微服务发送prepare-to-commit命令之前失败，那么其他服务将认为操作被中止了。
2. 协调器不会向所有服务发送doCommit消息，直到它们为准备就绪的承诺发送ACK。
3. 这将确保没有任何一个服务被阻断，并等待其他服务。

失败的场景

1. 当协调者或服务或两者在提交阶段发生故障时，预提交阶段有助于系统的恢复。
2. 当协调器在提交阶段失败后，新的交易协调器接管时，它查询所有的服务，看它们处于哪种状态。
3. 如果服务处于提交阶段，那么新的协调者将知道前一个协调者在崩溃前已经发出了提交命令。
4. 如果任何一个服务没有收到prepare-to-commit命令，那么新的协调器将知道前一个协调器已经崩溃，甚至在它完成prepare-to-commit阶段之前。
5. 因此，它可以安全地中止事务。

3PC的缺点

1. 3PC必须谨慎实施，以确保网络分区不会导致交易中的不一致。
2. 3PC有更多的开销，因为它涉及到一个额外的步骤。

对异步模式的需求

虽然两阶段提交和三阶段提交适用于跨微服务的分布式事务，但它们并不高效，因为它具有阻塞和同步的性质。

一般来说，数据库系统会在50毫秒内完成一个交易。但是微服务有很长的延迟，因为事务通过RPS在不同的服务中跳转，因此长时间的锁定会成为系统的回瓶。在同步模式下，事务之间也可能出现死锁。

所有这些缺点为使用Saga模式的异步方式铺平了道路，该模式依赖于最终的一致性，不保持原子性。

在这篇文章中，我们看到了什么是事务，它是如何在单体和微服务中工作的。我们还看到了什么是2阶段提交和3阶段提交以及它们的缺点。

在下一篇文章中，我们将探索基于Saga的模式，这些模式是异步和反应式的。

转载请注明来源：janrs.com/bkt7

本作品采用《CC 协议》，转载必须注明作者和本文链接