3
在这个官方文档中，我认为有必要提供文档的具体路径和显式的配置文件。当全局事务之外的本地事务操作了一些数据，导致全局事务回滚时快照信息与当前数据不一致时，Seata采取了什么策略？默认逻辑和配置是什么？或者，如果Seata的固有逻辑无法满足用户需求，是否有可用的接口来传递上下文信息和快照数据，使用户能够自定义某些回滚操作？
Q
[seata]Seata官方文档的补充以及全局事务回滚策略的扩展
A
回答
6
这种问题定位和维护对于我个人来说还是比较困难的。如果自定义场景较多，使用TCC可能更合适。
1
这种问题定位和维护对于我个人来说还是比较困难的。如果自定义场景较多，使用TCC可能更合适。
当然可以，但我建议首先在此处完成官方文档。至于AT模式是否应该提供一个接口来自定义全局事务快照的回滚，相信社区相关个人可以讨论一下。
3
AT模式是自动模式。当遇到无法处理的不一致问题时，它会采取“快速失败”策略。 SDK中不直接支持这方面的直接扩展。未来可以在控制台中进行交易修订控制。
7
https://github.com/seata/seata/pull/4585 https://github.com/seata/seata/pull/4559 我们现在有两个解决方案，我想知道您对这两个解决方案有何看法？或者您认为使用自定义扩展更好？
6
我已经阅读了这两个问题并理解了它们的含义。目前，我认为这两种方案都是可行的。通过配置可以跳过一些字段的检查，毕竟并不是所有的字段都需要进行快照比较，这样在选择上就更加灵活了。我也认为有必要扩展接口。在一些逻辑比较复杂的场景下，可能需要通过快照数据和元数据信息来查询当前的业务数据，比较数据权重，然后做出正确的回滚逻辑。我认为这两个条件都是必要的，以适应不同的场景。
6
经进一步反思
从目前的AT模式来看，考虑到AT模式是一种完全自动化的全局交易管理机制，更应该强调其自动化方面。主要问题是用户没有正确配置全局事务管理的注解，或者在数据库中设置定时任务或执行定时脚本，导致全局事务之外的机制改变当前快照数据中的某些字段信息。全球交易。
按照这个思路，字段过滤配置可能是解决这些问题的主要机制，并且它可以将全局事务的数据管理范围缩小到字段级别。这可以减少某些字段的快照数据中意外的不一致。虽然不能完全解决问题的根源，但可以保证问题出现在预期的领域。
相反，要求用户实现自己的回滚逻辑似乎需要的不仅仅是单个表的逻辑。他们可能需要为全局事务中涉及的所有相关业务表实现逻辑。这确实会给用户带来很大的心理负担。而且这样的实现与TCC的实现逻辑类似，不太符合AT的设计理念。这可能是最后的解决方案。