一、该问题的重现步骤是什么？
1、目前你们官方推荐在生产推荐使用 seata吗？
2、如果使用你们是推荐把系统内的分布式事务全部使用seata处理，还是仅仅部分业务使用seata，其余的场景通过设计来规避？
3、如果是部分业务使用seata，那么官方建议实际业务中应该如何使用？是将使用seata的业务独立出一个工程单独。还是可在工程内部混合使用(加上@Transactional和@GlobalTransactional说明启用分布式事务，不加@GlobalTransactional说明使用单机的事务,可否这么使用)？
二、你期待的结果是什么？实际看到的又是什么？
三、你正在使用的是什么产品，什么版本？在什么操作系统上？
四、请提供详细的错误堆栈信息，这很重要。
五、若有更多详细信息，请在下面提供。
我们推荐使用业务设计来规避分布式事务，原则上分布式事务越少越好。
如果无法规避则缩减到两个服务，这样就可以优先考虑手动规则配置回滚。
如果必须3个以上服务，才用分布式事务，如果是分布式事务的话，我们推荐seata，当然有钱也可以采用阿里云商用版的GTS。
手动配置规则回滚，这个能详细解释下吗？
比如说我现在有A、B两个服务。
程序逻辑是先执行A服务的一系列插入、再执行B服务的一系列插入。
如果通过设计来规避，那么B服务提示异常后，如何通知到A服务执行回滚呢？
手动配置规则回滚，这个能详细解释下吗？
比如说我现在有A、B两个服务。
程序逻辑是先执行A服务的一系列插入、再执行B服务的一系列插入。
如果通过设计来规避，那么B服务提示异常后，如何通知到A服务执行回滚呢？
扫一扫访问 Blade技术社区 移动端
加载中...
苏公网安备 32041102000998号