技术负责人 | 分布式事务 | 面试高频

▌ 技术引导
分布式事务是高并发系统里最让人头疼的活儿，尤其是在金融、电商、物流这些业务场景里，一个没处理好就可能直接导致资金错误，订单混乱，系统崩溃。我亲测过，在实际项目里用的是Seata + MySQL + Redis的组合，整个流程比想象中复杂得多。关键点在于事务参与方的协调、资源锁定的粒度、TCC模式的实现，以及网络不稳定时的回滚机制。我发现很多面试官其实关心的是你怎么处理异常，而不是你用了什么工具。他们更想知道你有没有实际经历过并发冲突，有没有针对性优化过性能。比如，某次线上事故是因为没有正确配置Seata的事务分组导致的脏读，这让我对数据库的XA模式有了更深刻的认识。在面试中，如果你能说出具体的TC、TM、分支事务之间的交互细节，以及在不同数据库下配置的差异，那你就赢了一半。

▌ 技术参考
分布式事务的核心在于保证多个服务或数据库之间的数据一致性。在实际项目中，我们通常采用两阶段提交（2PC）或三阶段提交（3PC）的模型，但这些传统方案在高并发环境下表现不佳，容易出现资源占用高、恢复慢的问题。当前主流方案是基于补偿机制的TCC（Try-Confirm-Cancel）模式，结合Seata这样的框架，能满足大部分业务场景。你得知道Seata的TC、TM、RM三个角色如何配合，以及如何配置事务分组、分支事务的隔离级别。在本地事务中，可以通过@GlobalTransactional注解开启分布式事务，但必须确保配置的TC服务器是稳定的，否则可能会出现事务无法提交的问题。


在实际部署中，MySQL的XA事务支持并不完美，尤其是在高并发写入时容易出现超时，这时候需要配置事务回滚超时时间。比如在MySQL的配置文件中，可以设置 innodb_lock_wait_timeout=60，避免锁等待时间过长导致事务回滚失败。同时，Seata的事务管理器需要与MySQL的XA模式配合，通过配置seata.tx-mode=AT，可以启用基于AT的分布式事务。但如果你用的是Oracle，需要配置seata.tx-mode=JTA，并且确保数据库支持分布式事务。这时候你得知道怎么在数据库层面启用分布式事务，比如Oracle的distributed transactions需要在服务端配置TNS，客户端也要有正确的连接参数。


在分布式事务中，常见的一个坑就是网络超时导致的事务状态不一致。比如，当TM（Transaction Manager）发起了一个全局事务，但其中一个RM（Resource Manager）因为网络问题迟迟未响应，这时候Seata会默认认为该分支事务失败，触发回滚，但如果你的业务逻辑需要重试，就必须手动处理这种情况。我踩过这样的坑，就是在调用远程服务时，没有设置超时重试策略，结果发现一个分支事务失败，整个全局事务就被回滚了，导致数据不一致。后来改用重试机制，再配合分支事务的回滚策略，才避免了这个问题。另外，如果数据库连接池配置不当，比如最大连接数太小，也会导致分布式事务失败，这时候需要调整连接池的参数，比如maxPoolSize=50。


如果使用TCC模式，必须保证Confirm和Cancel操作的幂等性。我之前在设计一个订单系统时，误以为只需在Confirm阶段处理逻辑，却没有考虑到Cancel阶段可能重复触发。结果在系统压力测试中，出现多次Cancel操作，导致数据异常。后来通过引入Redis来保存事务状态，确保每个分支事务只能被Confirm或Cancel一次。同时，在Confirm操作中，要避免直接修改数据库，而是先记录日志或状态，待后续确认后再执行。在代码中，可以通过给方法添加@TwoPhaseBusinessAction注解，配合自定义的确认和取消逻辑，来保证事务的最终一致性。这一步很关键，否则整个事务机制就失去了意义。


Seata的配置项也容易出错，比如在配置文件中指定seata.service.vgroupMapping.default_txgroup=group1，但实际启动TC时，配置的group1可能没有正确绑定，这时候会出现事务找不到分组的问题。我之前就遇到过这种情况，导致所有分布式事务都无法提交。后来检查发现，TC的配置文件中没有正确设置service.vgroupMapping的值，或者MySQL的XA事务配置有误。这时候需要通过seata的控制台查看事务状态，或者在日志中查找是否有Transaction Manager配置错误的提示。同时，确保每个微服务的配置文件都引用了正确的TC地址，比如seata.tx-service-group=order-service。


事务日志的存储方式也会影响性能，Seata默认使用File模式，但如果你的系统有大量事务，建议切换为DB模式。这样可以避免磁盘IO的压力，同时提升事务的持久化能力。在配置中，需要设置store.mode=db，并且确保数据库表seata_tx_undo_log的结构正确。另外，事务日志的清理策略也很重要，比如设置undo.log.table.name=undo_log来指定表名，或者调整undo.log.delete-time=1800000（30分钟）来控制清理频率。这些配置一旦出错，就会导致事务日志堆积，影响系统性能。


在分布式事务中的性能调优，关键在于减少事务参与节点的数量。比如，如果一个订单创建操作需要修改数据库、调用MQ、更新库存等多个系统，那么每个系统都参与事务会增加协调开销。这时候，可以考虑将某些非关键操作放到事务之外，比如使用消息队列异步处理库存扣减。另外，事务的隔离级别也需要仔细调整，比如在MySQL中设置transaction_isolation=REPEATABLE-READ，避免出现脏读或幻读的问题。不过，过高的隔离级别会导致性能下降，所以在实际项目中，需要根据业务场景权衡。


在使用Seata时，必须确保所有参与服务都使用相同的事务组。比如，订单服务和库存服务需要配置相同的service.vgroupMapping值，否则会触发事务异常。我之前在多服务协同中，因为没有统一配置事务组，导致事务无法提交，最终需要排查所有服务的配置文件。此外，本地事务的超时时间也需要合理设置，比如在Spring Boot中可以通过@Transactional(timeout=30)来限制事务的执行时间。如果某个服务的本地事务超过了全局事务的超时时间，整个事务就会被回滚，导致数据不一致。所以，在实际测试中，要模拟极端情况，确保所有服务都能在规定的超时时间内完成操作。


在一些特殊场景下，比如数据库连接池资源有限，或者网络不稳定，分布式事务可能无法正常提交。这时候，可以考虑引入重试机制，比如在Spring Retry中配置重试策略，或者在Seata的配置中添加retry配置。比如在seata.conf中设置retry.count=5，retry.interval=1000，这样在事务提交失败时会自动重试。不过，重试策略不能滥用，否则会引发循环依赖的问题。我曾经在一次部署中，因为重试次数太多，导致事务不断回滚，最终系统陷入死循环。后来改用异步重试机制，并配合熔断策略，才解决了问题。


在某些业务逻辑中，可以通过事务补偿机制来减少对分布式事务的依赖。比如，对于不需要强一致性，但需要最终一致性的场景，可以使用本地事务加消息队列的方式。比如在订单创建时，先执行本地事务，再发送消息到MQ，由MQ的消费者异步处理库存更新。这样可以避免多个数据库参与事务，减少锁竞争，提升性能。但这种方法也有其局限性，比如消息可能会丢失，或者消费者处理延迟，这时候需要额外的机制来保证消息的可靠传递和补偿处理。我用过这种方式，但后来发现，在高并发场景下，消息堆积还是会影响用户体验。


在实际开发中，分布式事务的调用链必须清晰，否则排查问题会非常困难。比如，在调用下游服务时，要确保每个服务都支持Seata的事务传播机制，否则整个事务链就会断裂。这时候需要在Spring Boot的配置中添加seata.enable=true，并设置事务传播模式，比如seata.tx-type=AT。同时，在Service层要添加@GlobalTransactional注解，确保事务的正确开启和提交。如果某个服务没有正确配置，就会导致事务无法继续，最终引发异常。我之前在集成测试中发现，一个服务漏掉了这个注解，结果整个事务链失败，数据不一致。


当需要处理跨数据库的分布式事务时，除了Seata，还可以考虑使用Atomikos或Bitronix这样的JTA事务管理器。这些工具更适合传统的Java EE环境，但配置起来更复杂。比如，使用Atomikos时，需要在JNDI中配置数据源，并在事务管理器中指定多个数据源。在配置文件中，可以设置transactionManager="AtomikosTransactionManager"，并配置相关参数如maxPoolSize=20。不过，这些工具在Spring Boot中的使用频率较低，因为它们对应用层的侵入性较大，而且性能不如Seata。我之前用过Atomikos，但后来发现Seata更适合微服务架构，所以逐渐转向使用Seata方案。


在某些高可用场景下，可以采用多TC服务器的集群部署。比如，将TC部署在多个节点上，确保即使一个节点宕机，事务状态也不会丢失。这时候需要在seata.conf中配置registry.conf，指定多个TC地址，比如registry.conf=registry,config。同时，配置TC的负载均衡策略，比如使用nacos或eureka作为注册中心，确保服务发现和通信的稳定性。但要注意，多TC部署需要同步事务日志，否则可能导致数据不一致。我之前尝试过，结果发现日志同步不及时，导致事务状态不一致，最终需要手动清理日志文件。


在处理分布式事务时，需要特别关注事务的幂等性。比如，在远程服务调用失败后，事务可能会回滚，或者进入补偿阶段。这时候需要确保每个操作只能被执行一次，否则会导致数据错误。比如在订单状态更新操作中，添加幂等校验，比如检查订单ID是否已经处理过。这时候可以使用Redis作为缓存，记录已处理的订单ID，并设置过期时间。在代码中，可以通过@RedisHash注解或手动使用RedisTemplate来实现。我之前在这样的情境中没有处理幂等性，结果导致同一个订单被多次处理，最终数据错误。


对于某些对性能要求极高的场景，可以考虑使用Seata的TCC模式来优化。比如，在高并发下单场景中，将库存扣减操作改为TCC模式，而不是直接在AT模式中处理。这时候需要在服务中实现Try、Confirm、Cancel三个接口，并在调用时通过@TwoPhaseBusinessAction注解定义。在Try阶段，先预留资源，Confirm阶段执行实际操作，Cancel阶段释放资源。这样的设计可以减少数据库锁的持有时间，提高并发能力。但在实际使用中，需要确保Confirm和Cancel的实现是幂等的，并且能够处理网络异常情况。


在某些分布式系统中，为了提升性能，可以使用异步提交的方式。比如，将事务提交操作延迟到异步线程中执行，这样可以减少主线程的阻塞时间。不过，这种方法需要配合重试机制，否则可能导致事务提交失败。比如，在Spring Boot中使用@Async注解，配合RabbitMQ或Kafka进行消息异步处理。但要注意，异步提交可能会带来延迟，所以在实际项目中需要评估是否接受这种延迟。我之前尝试过异步提交，但发现延迟过高，导致业务端用户感知差，最终还是放弃这种方式。


在某些微服务架构中，可以使用SAGA模式来处理分布式事务。这种模式通过将事务拆分为多个本地事务，并在每个步骤中记录状态，最后通过补偿机制来处理失败情况。比如，订单创建先执行本地事务，然后发送消息到MQ，由消费者处理库存扣减。如果某个步骤失败，就触发补偿操作，回滚前面的事务。这种方法在某些场景下可以替代传统的分布式事务，但需要额外维护补偿逻辑。我之前在某个项目中用过SAGA模式，但发现补偿逻辑的编写非常复杂，需要仔细设计。


最后，分布式事务的监控和日志分析非常重要。比如，可以通过Seata的控制台查看事务状态，或者在日志中分析是否有事务回滚、分支事务超时等问题。在实际项目中，我曾使用Prometheus和Grafana来监控Seata的事务状态，比如事务数量、回滚次数、超时时间等。这些指标可以帮助你及时发现系统问题，优化事务性能。同时，在日志中要保留详细的事务ID和操作日志，以便在出现异常时快速定位问题。