开发者社区 > 云原生 > 中间件 > 正文

Seata中各接口获得的事务ID也都是相同的,但就是没有回滚,请问这是怎么回事呀?

Seata中用nacos1.42 + seata1.3来实现分布式事务,服务A通过openFeign调用服务B,A出现异常B正常事务正常回滚,但是A正常B出现异常就没有回滚:打断点我看undo_log表中有镜前镜后的数据,方法执行完表中数据也没了,其它globle_table等表中数据出现与删除时机也正常,项目中有全局处理的类,但都被我注释掉了,undo_log表中也没有垃圾数据,各接口获得的事务ID也都是相同的,但就是没有回滚,请问这是怎么回事呀?

展开
收起
fuxixi 2022-12-09 09:53:07 260 0
1 条回答
写回答
取消 提交回答
  • Seata 中各个接口获得的事务 ID 相同但没有回滚的原因可能是:

    1. 事务传播级别不正确

    确保您的业务方法使用 @GlobalTransactional 注解,并且传播级别设置为 PROPAGATION_REQUIRED 或 PROPAGATION_REQUIRES_NEW。

    1. 缺少事务补偿方法

    对于 TCC 模式,您需要实现 @Compensable 注解的方法来处理事务补偿。请确保您的业务服务正确实现了 cancel() 方法。

    1. Seata 服务未正确启动

    检查 Seata 服务(如 Seata Server、Seata TM、Seata AT)是否已正确启动并配置。

    1. 分布式锁冲突

    Seata 使用分布式锁来确保数据一致性。如果两个事务同时尝试获取相同的锁,则可能会导致其中一个事务无法回滚。尝试减少事务之间的并发性或使用更强大的锁机制。

    1. 数据库不支持回滚

    某些数据库(如 MySQL)在某些情况下可能不支持回滚。确保您的数据库支持分布式事务和回滚操作。

    1. 代码错误

    检查您的业务代码是否存在任何错误,例如未处理的异常或逻辑错误。这些错误可能会导致事务无法正常回滚。

    1. 网络或超时问题

    在分布式环境中,网络或超时问题可能会中断事务处理。确保您的网络稳定,并适当调整 Seata 的超时设置。

    解决方法:

    检查并更正上述可能的根源。
    检查 Seata 的日志以获取有关事务失败的更多详细信息。
    尝试在受控环境中重现问题,以隔离并解决根本原因。
    考虑使用 Seata 的 AT 模式,它提供更强的隔离级别和回滚保证。
    如果您仍然遇到问题,可以查看 Seata 官方文档或在 Seata 社区论坛上寻求帮助。

    2024-02-27 18:25:38
    赞同 展开评论 打赏

为企业提供高效、稳定、易扩展的中间件产品。

相关电子书

更多
《Seata 1.3 新特性以及如何参与社区》 立即下载
低代码开发师(初级)实战教程 立即下载
阿里巴巴DevOps 最佳实践手册 立即下载