有哪位大神知道是什么原因吗？

根据您描述的情况，TCC事务模式在执行过程中出现了预期的二阶段回滚操作，但数据库中的记录并未被删除。这可能涉及几个关键点，我们逐一排查：

1. TCC事务流程确认：

   • TCC模式分为Try、Confirm、Cancel三个阶段。Try阶段预留资源，Confirm阶段提交事务（确认操作），Cancel阶段进行回滚（取消预留）。确保您的业务逻辑正确实现了这三个步骤，并且在异常时能够进入Cancel流程。

2. 日志分析：

   • 您提到程序日志显示已经二阶段回滚，需要仔细检查这些日志以确认是哪个阶段的日志——是Cancel阶段的日志吗？同时，查看是否有与数据库交互相关的错误信息或警告，比如连接问题、权限不足或是SQL执行失败等。

3. 补偿操作实现：

   • 确认Cancel方法是否正确实现了数据的删除逻辑。在Saga模式中，补偿操作应明确地“反向”执行Try阶段的操作，而在TCC模式下，Cancel应当直接撤销之前Try所做的资源预留或更改。请确保Cancel逻辑无误，并能实际影响到数据库记录。

4. 数据库事务隔离级别：

   • 虽然TCC模式不直接依赖数据库事务，但数据库层面的事务隔离级别和自动提交设置也可能影响最终结果。检查数据库配置，确保没有外部因素干扰了Cancel操作的执行效果。

5. GTS服务状态：

   • 如果您使用的是阿里云GTS服务来管理TCC事务，请检查GTS服务的运行状态和配置，确认事务分组是否正常工作，以及事务的跟踪ID（txId）是否在GTS侧有正确的处理记录。

6. 资源锁定与并发问题：

   • 在高并发场景下，如果多个事务尝试对同一资源进行操作，可能会出现竞态条件。尽管TCC模式通过两阶段设计减少了锁的依赖，但仍需检查是否存在并发控制不当导致的Cancel操作未生效情况。

7. 代码与配置复审：

   • 重新审视示例工程“springcloud-seata-feign-master”的配置和代码实现，确保所有TCC接口正确注册并映射到了业务逻辑上，同时检查是否有遗漏的异常处理逻辑，或是资源释放不彻底的问题。

综上所述，解决此问题的关键在于细致检查TCC各阶段的实现细节、日志信息、数据库操作及服务配置，以定位具体原因并采取相应措施。希望以上建议能帮助您解决问题。您可以复制页面截图提供更多信息，我可以进一步帮您分析问题原因。