Seata---TCC-空回滚问题-悬挂事务问题

分布式事务处理里，TCC模式的空回滚和悬挂事务总让人头疼。商家搞促销活动，用户下单扣款后突然发现库存不足，这时候系统就得回滚。可要是回滚时发现根本没执行过预留资源操作，这就叫空回滚。

程序员老张最近就遇上这档子事。他们电商平台做秒杀，用户点击支付后突然网络抖动，Try阶段压根没执行成功，可系统却收到了回滚指令。这就像去饭馆点了菜，厨子还没开始做呢，服务员突然跑来退钱，后厨直接乱套了。

悬挂事务更闹心。Try阶段成功了，Confirm/Cancel却迟迟不来。好比快递员把包裹放驿站了，客户既不来取也不说退货，驿站堆的包裹都快溢出来了。某支付平台就吃过这亏，半夜对账时发现一堆未完成事务，财务差点拎着键盘找人干架。

解决这俩问题得靠事务日志打点。系统在Try阶段先记流水账，回滚前查查账本就知道该不该干活。给事务加个过期时间也行，就像外卖订单半小时不处理自动取消，省得资源吊在半空晃悠。

蚂蚁金服那帮工程师想了个妙招，给每个事务配个唯一ID，处理前先到数据库里查户口。这招跟小区物业似的，生面孔进门先登记，出门再销号，混进来的闲杂人等立马现原形。

分布式事务就像多人三脚跑，配合不好准摔跟头。银行转账时要是遇到系统抽风，这边钱扣了那边没到账，客户能急得把客服电话打爆。得亏有这些防错机制兜着，不然程序员早该集体去植发了。