【求助】tcc模式使用fence表情况下如何对上游重试做幂等？

[Ttdjs]

以下单为例，上游重试导致注册了两个事务，应该如何实现两个事务之间的幂等？
我们现在的方案是业务上维护了一张全局的事务状态幂等表（用业务主键作为幂等），但是感觉和fence表的定位有点重叠。

[funky-eyes]

They don't conflict. Seata TCC's fence mechanism is designed to address idempotency in the second phase and prevent dangling transactions in the first phase. It serves a distinct purpose from the idempotency requirements you need to implement for your service's first-phase invocations, with no overlap between the two.

[Ttdjs]

请问您有没有更好的解决这个问题的方案呀？我们现在自己维护了一张全局事务状态幂等表的性能太差了，因为事务的任何阶段都需要对这张表加锁判断状态，甚至不同的resources之间都需要进行锁竞争。

[funky-eyes]

You only need to ensure idempotency for the first phase (Try).
So, before the Try method is invoked, you can use an aspect (e.g., AOP) or similar mechanism along with a component like Redis to guarantee idempotency for the first phase.
You do not need to worry about the second phase (Confirm/Cancel) or the overall transaction status.

[Ttdjs]

只对try做幂等可能会有数据不一致问题。例如考虑时序：

1. t1 时刻，请求开始，注册事务，并且对两个resource执行try 成功，进入到confirm阶段
2. t2 时刻， resource1 confirm 成功， resource2 confirm未到达
3. t3 时刻，请求重试，重新注册新的事务，重新执行try，但是try因为网络原因失败，进入到cancel阶段
4. t4时刻，resource2 cancel成功
   这种情况下resource1 confirm，resource2 cancel，最终不一致。并且因为重试的请求可能是因为网络异常等原因失败，根本没有实际执行try，所以try的幂等没办法解决。
   我们尝试使用下列方式解决，请问是否可行：
   发起事务后记录下业务主键和xid的关系，重复请求时拦截请求，或者以第一次请求的xid继续后续流程

[funky-eyes]

只对try做幂等可能会有数据不一致问题。例如考虑时序：

1. t1 时刻，请求开始，注册事务，并且对两个resource执行try 成功，进入到confirm阶段
2. t2 时刻， resource1 confirm 成功， resource2 confirm未到达
3. t3 时刻，请求重试，重新注册新的事务，重新执行try，但是try因为网络原因失败，进入到cancel阶段
4. t4时刻，resource2 cancel成功
   这种情况下resource1 confirm，resource2 cancel，最终不一致。并且因为重试的请求可能是因为网络异常等原因失败，根本没有实际执行try，所以try的幂等没办法解决。
   我们尝试使用下列方式解决，请问是否可行：
   发起事务后记录下业务主键和xid的关系，重复请求时拦截请求，或者以第一次请求的xid继续后续流程

If you've already implemented idempotency properly in the Try phase, how could an extra branch transaction possibly appear?
By placing the idempotency check on the actual Provider side (rather than the Consumer side), the Provider can simply reject any duplicate attempts outright. In that case, isn't it impossible to end up with any redundant branch transactions?

[funky-eyes]

Moreover, your argument doesn't hold up.
A failed Try is simply the result of Phase 1. Once Phase 2 has already been resolved (global decision made), the server will outright reject any further branch registration attempts during Try — no new branches can be added.
If the Try registration succeeds, it means the server hasn't yet received or processed the Phase 1 resolution. Therefore, this extra branch will be handled exactly like the original one and receive the same Confirm or Cancel instruction.
There's simply no way one branch gets confirmed while the duplicate gets canceled.

[Ttdjs]

非常感谢，我明白了，你是对的。