2023年7月28日发(作者：)

如何保证跨系统的数据的⼀致性⼀、多系统间的分布式事务在分布式环境中，⼀个交易将会被分布到不同的系统中，在多个微服务进程内执⾏计算，多个数据库中执⾏数据更新操作，这个场景⽐数据库事务⽀持的单进程单数据库场景复杂太多了。如何通过 分布式事务 来保证微服务系统中，我们所⾯临的分布式系统中的数据⼀致性问题呢？理论上分布式事务也是事务，也需要具有。但在实际情况下，为了兼容性能和⾼可⽤，所以往往⽆法严格遵守ACID四个特性。分布式事务的解决⽅案有很多，⽐如：2PC、3PC、TCC、Saga 和本地消息表等等。2PC 和 本地消息表 这两种分布式事务的解决⽅案，⽐较贴近于我们⽇常开发的业务系统。1、本地消息表——订单系统与积分系统的分布式事务订单系统在落库新单的时候会同时修改积分系统的数据，为了保证两系统间的 分布式事务，我们采⽤的是 本地消息表法。1. 通过 Spring的事务控制 订单落库 和 发送给积分系统的消息 同时进⾏落库2. 启动异步线程，通过MQ的⽅式将消息发送给 代理队列，并由代理队列投递给 积分系统。（消息的准确投递，有MQ的监控机制实现）3. 积分系统通过处理消息 并且 提交数据，来保证与订单系统数据的⼀致性。2、2PC——⼆阶段提交法2PC 引⼊了⼀个事务协调者的⾓⾊，来协调两个系统。以使⽤消费券 进⾏ 下单为例，协调者对客户端提供⼀个完整的“使⽤优惠券下单”的服务，在这个服务的内部，协调者再分别调⽤订单系统和促销系统的相应服务。所谓的⼆阶段指的是准备阶段和提交阶段。在准备阶段，协调者分别给订单系统和促销系统发送“准备”命令，订单和促销系统收到准备命令之后，开始执⾏准备操作。1、准备阶段可以完成 除了提交数据库事务以外的所有操作：拼接数据信息将数据信息插⼊相应的表中不提交事务，并向事务协调者返回 准备成功。在准备阶段，如果任何⼀步出现错误或者是超时，协调者就会给两个系统发送“回滚事务”请求。每个系统在收到请求之后，回滚⾃⼰的数据库事务，分布式事务执⾏失败，两个系统的数据库事务都回滚了，相关的所有数据回滚到分布式事务执⾏之前的状态，就像这个分布式事务没有执⾏⼀样。2、事务协调者 在收到两个系统“准备成功”的响应之后，开始进⼊第⼆阶段。提交阶段就⽐较简单了，协调者再给这两个系统发送“提交”命令，每个系统各⾃提交⾃⼰的数据库事务，然后给协调者返回“提交成功”响应。如果发⽣⽹络传输失败的情况，需要反复重试，直到提交成功为⽌。如果这个阶段发⽣宕机，包括两个数据库宕机或者订单服务、促销服务所在的节点宕机，还是有可能出现订单库完成了提交，但促销库因为宕机⾃动回滚，导致数据不⼀致的情况。这种情况⽆法避免，但是，因为提交的过程⾮常简单，执⾏很快，出现这种情况的概率⾮常⼩。所以，从实⽤的⾓度来说，2PC 这种分布式事务的⽅法，实际的数据⼀致性还是⾮常好的。

⼆、单系统间分布式事务在单系统中，常常应为数据量巨⼤，在数据的存储上采⽤的⽔平扩展的⽅式，将相同的库表分别放置在不同的物理实例上，如订单系统的分库分表，在实际应⽤过程中，如何保持分布式的事务的呢。在实际应⽤中，未真正的实现分布式事务，通过DBP中间件的限制，保证了⼀个事务中进⾏提交的操作只会对⼀个物理表进⾏修改。对于跨库的事务未保证⼀致性，只是提供了补偿机制，确保可以在发现问题后，可以保证数据的最终⼀致⾏。对于⽀付系统的是采取的真正的分布事务，该分布式事务应⽤的是阿⾥⾦融云提供的分布式事务组件。