在分布式架构中，应用常被拆分成多个服务，每个服务都可能有自己专用的数据库。例如，在一个电商系统中，用户下单操作可能需要跨越订单服务、库存服务、支付服务等不同的服务和数据库，因此需要分布式事务来保证操作的原子性和数据的一致性。

什么是分布事务

传统的事务，如数据库事务，通常是在单个数据库系统内部进行的，它遵循ACID（原子性、一致性、隔离性、持久性）原则来保证事务的安全性和数据的准确性。
分布式事务则是跨越多个独立的数据库、系统或网络边界的事务操作，这些操作必须作为一个整体被提交或回滚。
在单体应用中，所有模块都使用一个本地数据库，数据一致性自然由本地事务保证。假设有一个单体应用包含3个模块：库存模块、订单模块、支付模块，事务管理机制如图1所示。

图1 单体应用的事务管理机制

在分布式的微服务架构下，上述情况发生了变化。上面的3个模块现在被重新设计为3个独立的服务，每个服务都建立在不同的数据源之上。单个服务中的数据一致性自然由本地事务保证，但是整个业务系统的事务没法通过本地事务进行管理，此时就需要使用分布式事务机制来保证整个业务系统的数据一致性，如图2所示。

图2 分布式系统的事务管理

比如，在电商系统的用户下单场景下，订单服务、库存服务和支付服务分别对应不同的数据库或数据源，用户下单操作需要在这3个服务之间保持一致，即创建订单、减少库存和扣款这三个步骤需要作为一个整体来执行，要么全部成功，要么全部失败，如图3所示。

图3 电商系统的用户下单场景

（1）用户向订单服务请求下单，订单服务开始创建新订单。
（2）订单服务请求库存服务，以查询库存并预留商品。
（3）库存服务请求支付服务处理用户支付。
（4）支付服务返回支付结果给库存服务。
（5）根据支付结果，库存服务向订单服务确认库存减少。
（6）订单服务根据库存服务和支付服务的结果，最终确认订单创建。
在上述步骤执行过程中，一旦网络分区发生，可能导致“扣款成功，但库存未正确减少”或者订单创建失败等问题，破坏了数据一致性。为了保证整个操作序列的原子性和一致性，我们需要应用分布式事务机制来协调和管理这些跨服务的操作。

分布事务面临的挑战及应对策略

在分布式系统中，在跨多个数据库实例或服务进行操作时，如何保证“这些操作要么全部成功，要么全部失败（即事务的原子性）”成为设计分布式事务处理机制的重要挑战。

01

面临的挑战

分布式事务面临的主要挑战如下。
网络延迟和分区：分布式系统中的网络通信可能会因为延迟或网络分区导致节点之间的通信不可靠，这对事务的一致性和原子性提出了挑战。
数据一致性：如何保证在多个数据库实例上执行的事务操作能够保持数据的全局一致性。
资源锁定与死锁：在分布式事务中，资源的锁定策略需要考虑死锁的可能性，避免因资源竞争导致系统阻塞。

02

应对策略

针对上述挑战的应对策略如下。
使用现代分布式事务模式，如Saga、TCC等，它们通过业务逻辑来解决分布式事务带来的挑战。
确保服务的幂等性，即重复执行相同操作的结果与执行一次的结果相同，以减少重试操作带来的影响。
采用事件驱动架构，通过异步消息传递减少服务间的直接依赖，从而提高系统的可用性和扩展性。

一张图看懂Saga模式

Saga模式将长期运行的事务拆分成一系列更小、更易管理的事务，这些小事务可以独立提交。如果其中一个事务失败，则Saga模式通过执行一系列补偿事务（即回滚操作）来保持数据的一致性，而不是回滚整个长事务。
例如在电商系统中，用户下单流程涉及多个服务（如库存服务、支付服务和订单服务）。在传统的事务管理中，这个下单过程需要作为一个整体来保持一致性。但在Saga模式下，这个过程可以被拆分成多个小事务，具体如下。
（1）减库存事务。库存服务尝试减少商品库存量。如果成功，则进入下一个事务；否则，结束事务，可能需要通知用户库存不足。
（2）支付事务。支付服务处理用户支付。如果支付成功，则进入下一个事务；否则，执行补偿事务，如恢复库存。
（3）创建订单事务。订单服务根据用户信息和商品信息创建订单。如果成功，则整个下单流程完成；否则，执行补偿事务，包括恢复库存和退款操作。
在Saga模式下，上述用户下单流程的事务管理方式如图4所示。

图4 Saga模式下的用户下单流程

从用户下单开始，通过一系列事务（如减库存、支付和创建订单事务）来完成整个下单流程。在每个事务中，如果操作成功，则进入下一个事务；如果操作失败，则结束整个事务，并根据情况执行相应的补偿事务（如恢复库存或退款），从而保持系统的整体一致性。

在电商系统中实现Saga模式

Saga模式可以通过两种方式来实现：事件（消息）驱动和直接管理。

01

事件（消息）驱动

在事件（消息）驱动的Saga模式下，每个服务都执行其事务，并发布事件（消息）以表明事务已完成或失败。其他服务监听这些事件，并根据事件内容触发下一个事务或执行补偿事务。
例如，在电商系统中，用户下单流程涉及库存服务、支付服务和订单服务。
（1）库存服务执行减库存事务，事务执行成功后发布一个“库存更新成功”事件。
（2）支付服务监听到该事件后，触发支付事务。事务执行成功后，发布一个“支付成功”事件。
（3）订单服务监听到“支付成功”事件后，触发创建订单事务。事务执行成功后，发布“订单创建成功”事件。
如果在任何步骤中发生失败，则相应的服务会发布失败事件，触发之前操作的补偿事务，如恢复库存和退款。
在事件（消息）驱动的Saga模式下，用户下单流程的事务管理方式如图5所示。

图5 在事件（消息）驱动的Saga模式下的用户下单流程

02

直接管理

在直接管理的Saga模式下，有一个事务协调器负责管理整个Saga的执行过程。事务协调器指导每个服务何时开始其事务，以及在失败时执行哪些补偿事务。
例如，在电商系统中，Saga事务协调器负责下单流程的整体管理，具体如下。
（1）事务协调器指示库存服务减库存。在操作成功后，库存服务通知事务协调器成功。
（2）事务协调器在收到库存减少成功的通知后，指示支付服务进行支付操作。在操作成功后，支付服务通知事务协调器成功。
（3）事务协调器在收到支付成功的通知后，指示订单服务创建订单。在操作成功后，订单服务通知事务协调器成功。
（4）如果任何步骤失败，则事务协调器根据预定义的补偿事务进行回滚操作，如指示库存服务恢复库存、指示支付服务退款等。
在直接管理的Saga模式下，用户下单流程的事务管理方式如图6所示。

图6 在直接管理的Saga模式下的用户下单流程

以上内容摘自《分布式系统实战派》