面试现场对面面试官把问题一抛“TCC知道吧那你说说TCC里悬挂和空回滚这两个问题怎么解决”刚把TCC的Try、Confirm、Cancel三个词背得滚瓜烂熟当场就开始冒汗。背定义谁都会但悬挂suspension和空回滚empty rollback是TCC落地时最刁钻的两个“隐藏陷阱”它们考察的不是你记没记住概念而是你有没有真正用TCC扛过真实业务流量有没有在异常时序里调过数、对过账、救过火。这篇文章就围绕这两个问题往深里拆什么是悬挂、什么是空回滚它们各自在什么时序下产生以及最关键的一点——怎么设计一套可落地的“事务控制表状态机”方案把这两个问题一起解决掉。内容同时覆盖面试话术和工程实现两套体系准备面试的同学能拿去直接用自己正在做TCC落地的开发者也能直接抄作业。1. 面试官这一问到底在考什么1.1 三个高频追问背后的隐藏考点很多面试题看着在考一个点实际考的是另一个点。“TCC的悬挂、空回滚怎么解决”就是典型表面考分布式事务实际考的是你对下面这三件事的综合掌控第一幂等设计。TCC的三个阶段任何一个都可能被重复调用。Try被重试、Cancel被重试、Confirm被重试全部是常态。你的接口能不能做到同一个事务分支被调用一百次结果跟调用一次完全相同这是分布式系统的基本功。第二异常时序下的状态判断。网络超时后重试、乱序到达、协调器误判这些不是小概率事件而是分布式环境里的“日常”。你要能说清楚当二阶段先于一阶段到达时系统处在什么状态该走哪条逻辑分支。第三最终一致性。TCC不是强一致性方案它追求的是“在系统稳定后所有数据能收敛到一致”。悬挂和空回滚的解决方案本质上都是在回答同一个问题怎么保证在极端乱序下事务依然能走向终态而不是卡在中间永远出不来。面试官问一个点你如果能沿着这三个维度展开基本就是碾压级别的回答。1.2 从全局看TCC的完整执行链路在深入两个问题之前先把TCC的整体链路看一遍否则后面的细节容易对不上号。TCC有三个角色事务协调器TMTransaction Manager、事务管理器TCTransaction Coordinator、资源管理器RMResource Manager。其中RM才是真正干活的人它对外暴露Try、Confirm、Cancel三个接口。正常流程是这样的TM发起全局事务生成一个全局事务IDxid然后调用各个RM的Try阶段让每个RM把本地资源预留出来。Try全部成功后TM逐个调用Confirm把预留的资源正式确认掉如果Try阶段有任何一个RM失败TM就会调用所有RM的Cancel把已经预留的资源补偿回去。这个流程看起来清晰但有一个致命前提所有调用都是同步且可靠的。现实里网络超时、消息丢失、进程崩溃任何一个环节都可能让TM误判执行结果。比如某个RM的Try其实已经执行成功了但响应报文在路上丢了TM等不到响应就判定失败直接发起了Cancel。这时候悬挂和空回滚就开始登场了。而面试官的追问往往就是从这里切进来的。2. 悬挂问题预留的资源没人认领2.1 用“订房”类比讲清楚悬挂是什么用一个生活里的场景来理解悬挂。你去订一家热门酒店的房间。前台系统里先给你做了一个“预占”操作把这间房标记成“有人预定”但你还没完成付款确认。这时候酒店的网络出了点问题订房请求的响应没送到你手里。你等得不耐烦又给前台打了个电话说“我不订了”。前台的取消单到了系统一看确实有个预占记录于是把预占解除房间恢复可售。到这里一切正常。但真正的麻烦来了你最开始发出的那条订房请求因为网络延迟这时候才到达前台系统。系统一看“这个请求好像没处理过”于是又做了一次预占把房间标记成“已预占”。完了。房间被占住了但你已经取消了订单不会再有人来确认入住也不会有人再去取消这条预占。这间房就永远“悬挂”在已预占状态无法被其他人预定。这就是TCC里的悬挂问题一阶段Try因为网络延迟在二阶段Cancel执行之后才真正生效导致资源被预留了却永远不会再有后续的Confirm或Cancel来结束它。2.2 悬挂产生的两种典型场景悬挂不是凭空想象出来的它在真实系统里有两个非常具体的触发场景。第一个场景是网络超时加乱序。RM的Try执行成功预留了库存但响应报文因为网络抖动没有送到TM。TM在超时时间之后判定Try失败于是发起Cancel。此时Cancel正常执行把预留的库存释放掉。但那条迟到的Try响应还在网络上漂着RM可能因为某种原因又收到了重试的Try请求比如TM重发再次执行了资源预留。这时候记录已经被Cancel处理成终态却又被新预留的资源“挂”起来了。第二个场景是Try和Cancel并发到达。这种情况更隐蔽。TM判定Try超时发出Cancel同时RM又收到了Try请求。如果两个请求在RM内部并发执行Cancel先查询分支事务记录发现还没有记录于是走了空回滚逻辑紧接着Try开始插入记录、执行资源预留。两条线程互不知道对方的存在结果就是Cancel已经认为事务被回滚了Try却真的预留了资源。这两个场景还原了分布式系统里最让人头疼的问题——并发加乱序。解决方案不能靠运气必须在设计层面强行规避。2.3 悬挂的判定标准与防悬挂设计解决悬挂问题的关键在于二阶段先行的状态必须被一阶段感知到。具体来说Cancel或者Confirm在执行时一定会把分支事务记录标记成一个终态比如CANCELED或者CONFIRMED。Try阶段在执行资源预留之前先查一下这个标记如果发现当前分支事务已经处于终态说明二阶段已经执行过了那么这次Try无论是迟到的还是重发的都不能再执行资源预留——直接返回成功释放线程什么都不做。这个动作就叫“防悬挂”。它的核心不是去回滚什么而是拒绝让一阶段在二阶段之后产生新的副作用。有一些框架层级的实现还会把这个标记设计得更细。比如在Cancel执行时除了把状态改成CANCELED还会额外写入一个“二阶段已执行”的标记位。Try到达时不仅检查状态还检查这个标记位双重保险。同时Try在发现是悬挂调用时最好把这个事件记录到日志或者监控里方便事后排查——因为这说明前置网络链路上出现过超时或者乱序属于系统健康度的信号。这里有个容易忽略的细节防悬挂的判断必须和Try入口在同一个事务边界里完成。也就是说查询“二阶段是否已执行”的操作必须和插入“一阶段开始”记录的操作放在同一个本地事务里不能让两者之间出现间隙否则恰好会让并发请求钻空子。3. 空回滚问题取消单到了业务记录还没影3.1 什么是空回滚再来一个场景。还是那家酒店前台系统的订单表里根本没有你这笔订房记录。这时候取消单到了。正常来说取消一个不存在的订单系统应该报错“订单不存在”。但在TCC里协调器等着Cancel的返回结果如果你直接报错协调器就会判定Cancel失败开始无限重试。每一次重试系统都报“记录不存在”然后又重试……事务永远无法结束。更危险的是另一种处理方式Cancel接口发现没有记录就“聪明”地直接返回成功。这确实让协调器不重试了但带来的问题是如果后续Try请求真的到了网络乱序Try就会正常预留资源资源再也没有人去补偿。事务在数据上并没有真正回滚协调器却以为已经回滚干净了。这就是空回滚问题二阶段Cancel或Confirm执行时发现分支事务记录不存在。此时不能直接回滚因为没有记录可以回滚也不能直接返回失败因为协调器会无限重试。需要特意处理“空回滚”这个状态。3.2 空回滚为什么不能靠“接口幂等”糊弄过去有人会说我的Cancel接口做一下幂等不就完了重复调用只处理一次返回成功不就解决了吗这个想法是错的。接口幂等只能解决“同一个请求被调多次”的问题解决不了“第一次调用时就没有处理对象”的问题。幂等的前提是第一次请求已经正常处理过了留下了处理结果后续重复请求可以基于这个结果直接返回。但空回滚发生时第一次请求就面临着“无记录可回滚”的困境。你让接口返回什么如果直接返回成功协调器认为回滚完成了但数据库里可能根本没有预留资源需要回滚这就是一次什么都没做就成功的“假装成功”后续Try还可能踩进来。而且如果不落一条记录情况会更糟协调器第一次Cancel返回成功后如果因为某种原因比如重新发起全局事务、重试又调用了一次Cancel系统依然查不到记录依然要面对这个“空”的状态。永远没有收敛。所以解决空回滚的正解不是简单返回成功而是要在Cancel发现无记录时主动落一条“空回滚记录”把这次回滚行为固化下来让后续所有调用无论是Try还是Confirm还是Cancel都能看到这个分支已经终态了不会再做多余的操作。3.3 空回滚的解决方案空回滚标记空回滚的落盘逻辑一般是这样的Cancel入口先按xid branchId查询分支事务记录。如果记录不存在说明一阶段很可能执行失败或者记录还没写进去。此时不是直接返回而是插入一条记录状态置为CANCELED同时打上一个“空回滚”标记比如empty_flag true然后返回成功。这条记录的意义有两个一是告诉协调器“回滚已经完成”事务可以继续推进二是给后续可能到达的Try一个“已经终态”的提示。Try过来一看状态是CANCELED就不会再去预留资源直接跳过。这样空回滚和悬挂的设计就形成了一个闭环空回滚用一条记录占住位置防悬挂用这个位置拦住迟到的Try。一个解决二阶段的“无米之炊”一个解决一阶段的“亡羊补牢”配合起来把乱序时序彻底锁死。4. 一套能落地的事务控制表设计4.1 控制表字段与状态机定义前面讲了一堆理论现在落到工程实现。TCC的悬挂和空回滚业界主流方案的核心就是一张事务控制表也叫分支事务记录表。这张表必须和业务数据在同一个数据库、同一个本地事务里完成读写——这是硬性要求后面会解释为什么。表结构设计参考如下字段类型说明idbigint主键自增xidvarchar(64)全局事务IDbranch_idbigint分支事务IDstatusvarchar(20)分支状态TRYING/CONFIRMING/CONFIRMED/CANCELING/CANCELEDempty_flagtinyint是否空回滚标记0正常1空回滚suspended_flagtinyint是否悬挂标记0正常1悬挂调用versionint乐观锁版本号create_timedatetime创建时间update_timedatetime更新时间其中要用xid branch_id建唯一索引保证同一个分支只有一条记录。这张表本身不存业务数据它只负责记录“这个事务分支走到哪一步了”。状态机定义如下TRYING一阶段Try已经执行或正在执行资源预留中CONFIRMINGConfirm正在执行CONFIRMEDConfirm已完成终态CANCELINGCancel正在执行CANCELEDCancel已完成终态可能带空回滚标记这个状态机有一个非常关键的特征所有终态CONFIRMED/CANCELED都不允许再迁移到其他状态。这样设计的目的就是让终态成为“一锤定音”的防悬挂标记。4.2 Try阶段完整实现含防悬挂判断Try阶段的伪代码长这样public boolean tryPhase(String xid, Long branchId) { // 同一本地事务内先查控制表 BranchRecord record branchDao.selectByXidAndBranchId(xid, branchId); // 1. 首次进入插入TRYING记录再执行资源预留 if (record null) { branchDao.insert(xid, branchId, Status.TRYING, 0); boolean success resourceManager.prepare(xid, branchId); if (!success) { branchDao.updateStatus(xid, branchId, Status.CANCELED); throw new BusinessException(资源预留失败); } return true; } // 2. 幂等处理已经TRYING直接返回成功 if (Status.TRYING.equals(record.getStatus())) { return true; } // 3. 防悬挂已经处于终态说明二阶段先行禁止再预留资源 if (Status.CANCELED.equals(record.getStatus()) || Status.CONFIRMED.equals(record.getStatus())) { // 标记悬挂便于监控排查 branchDao.markSuspended(xid, branchId); return true; } // 4. 其他状态CONFIRMING/CANCELING按异常处理抛错重试 throw new IllegalStateException(unexpected status: record.getStatus()); }这里面有几个细节值得多说一句。先插入TRYING记录再执行资源预留顺序不能反。因为如果先预留资源再插入记录时数据库报错资源就白白预留了没有人知道要去释放。先把记录插入等于先把位置占住后续所有异常都有据可依。防悬挂判断为什么放在幂等判断后面因为CANCELED也是一种“最终状态”如果直接走幂等也行但单独拎出来处理能区分出是“正常重复调用”还是“悬挂调用”方便监控和日志归因。还有一个坑如果TRYING状态下Try接口本身发生了异常、进程崩溃记录会一直停在TRYING协调器超时后会走到Cancel来纠偏这个场景下Cancel必须能处理TRYING状态的数据——这正是下面要讲的。这段Try代码的最后一步有个小设计如果资源预留失败直接把状态更新成CANCELED。因为预留失败本身就意味着这个分支不该再继续了将它标记为终态后即使后续有重复的Try请求到达也会被防悬挂逻辑挡住。4.3 Confirm与Cancel阶段完整实现含空回滚判断Cancel接口是悬挂和空回滚两个问题交汇的地方实现也要更谨慎public boolean cancelPhase(String xid, Long branchId) { // 同一本地事务内先查控制表 BranchRecord record branchDao.selectByXidAndBranchId(xid, branchId); // 1. 空回滚记录不存在落一条空回滚记录 if (record null) { branchDao.insert(xid, branchId, Status.CANCELED, 1); // empty_flag1 return true; } // 2. 幂等已经是CANCELED直接返回成功 if (Status.CANCELED.equals(record.getStatus())) { return true; } // 3. 已确认完成说明之前被Confirm处理了Cancel不应再介入 if (Status.CONFIRMED.equals(record.getStatus())) { // 通常说明协调器状态错乱记录日志告警按成功返回 return true; } // 4. 正常回滚状态从TRYING切到CANCELING执行补偿落终态 if (Status.TRYING.equals(record.getStatus())) { branchDao.updateStatus(xid, branchId, Status.CANCELING); boolean success resourceManager.rollback(xid, branchId); if (!success) { throw new BusinessException(资源回滚失败等待重试); } branchDao.updateStatus(xid, branchId, Status.CANCELED); return true; } // 5. 已经是CANCELING说明有并发Cancel在跑幂等返回 if (Status.CANCELING.equals(record.getStatus())) { return true; } throw new IllegalStateException(unexpected status: record.getStatus()); }Confirm接口的逻辑类似把rollback换成commit把CANCELED换成CONFIRMED即可。这个实现最核心的就是分支1无记录时必须插入一条空回滚记录而不是直接返回成功。这是前面3.3节强调的落盘动作。有了这条记录后续迟到的Try就会被防悬挂逻辑挡住整个事务的终态也被固定下来。有个细节很多人踩过坑步骤1的插入操作必须和业务事务在同一个事务里提交。如果控制表的记录先提交了业务资源的回滚却失败了数据就不一致了反过来如果业务回滚成功但控制表记录没提交下次重试又会走到空回滚。所以要强调的是控制表和业务数据必须在同一个本地事务边界内完成更新要么一起成功要么一起失败。4.4 状态机下的并发与幂等控制光有状态判断还不够因为Try和Cancel可能在同一个瞬间并发修改同一行记录。没有并发控制时会发生这种事故Try查到记录为null准备插入TRYINGCancel同时查到记录为null准备插入CANCELED空回滚。两个插入同时进行结果唯一索引冲突一个成功一个失败系统状态就乱了。解决办法有两个层次第一层唯一索引兜底。xid branch_id的唯一索引能保证只有一个请求能成功插入记录。失败的请求根据主键冲突可以反查当前记录状态再走对应的逻辑。这样即使并发插入也只有一个赢家。第二层乐观锁或者行锁控制状态迁移。TRYING - CANCELING - CANCELED这个状态流转需要用version字段做乐观锁或者直接SELECT ... FOR UPDATE锁行。比如Cancel把状态从TRYING改成CANCELING时要带上条件WHERE status TRYING AND version ?更新影响行数为0时说明状态已经被别的线程改掉了此时要重查状态重新判断。在这套设计里我一直强调“先插入记录再执行资源操作”的执行顺序本质上就是为了配合并发控制。如果记录还没落就直接去操作底层资源两个并发请求都觉得自己是合法的一定会产生不可控的交叉状态。5. 极端时序实战推演5.1 网络超时加乱序的组合拳怎么破把理论放到具体时序里推演一遍你才能真正感受到这套设计怎么兜住乱序。假设库存服务收到一个Try请求代码执行流程Try插入TRYING记录预留库存成功。但响应报文在网络上丢失。TM等待超时判定Try失败发起Cancel。Cancel查询控制表查到TRYING记录执行回滚释放库存状态更新为CANCELED。此时一条迟到的Try重试请求到达。Try查询控制表发现状态是CANCELED触发防悬挂逻辑标记suspended_flag 1直接返回成功。最终库存是释放的控制表记录是终态事务实际是回滚的。全局一致性没问题。再看一个变体Try请求在Cancel之后才第一次到达TM发起Try请求在网络上滞留。TM等待超时发起Cancel。Cancel先到查询控制表没有记录落一条CANCELED空回滚记录。Try之后再到达查询控制表发现状态是CANCELED不允许预留资源返回成功。最终没有资源被预留回滚语义被正确执行。空回滚记录和防悬挂判断在这里形成了一个完美的配对。这两种情况如果没有控制表和状态机要么资源被永久悬挂要么协调器无限重试。有了这套机制所有极端路径都收敛到终态。5.2 同一条记录的并发流转怎么破再推演一个更刁钻的Try和Cancel同时到达且先查到了控制表记录为null。Try线程A和Cancel线程B都执行select都得到了null。线程A执行insert TRYING成功。线程B执行insert CANCELED时主键冲突捕获到唯一索引冲突反查记录发现当前状态是TRYING于是走“正常回滚”分支执行回滚把状态变成CANCELED。如果线程A插入成功后先执行了资源预留、还没把状态改成终态那么线程B查到的就是TRYING回滚逻辑会正常释放资源如果线程B在步骤2已经把状态改成了CANCELED那么线程A的预留动作已经结束Try后续执行到“查状态确认”时会发现是终态跳过任何额外处理。怕就怕两个线程都没被唯一索引拦住而且都在“插入后、操作前”之间拿到过理想状态。所以代码里要保证插入记录和资源操作之间必须再次检查状态没有变成终态或者直接把资源操作放在一个受控的事务里资源操作前完成状态锁定。这也是为什么我在4.3节的实现里把“更新到CANCELING/CONFIRMING”放在执行资源动作之前。状态先锁定资源操作后执行这样并发请求看到CANCELING就能判断“有人在处理了”不会重复闯入。5.3 数据库与资源之间的“小事务”陷阱最后讲一个实现层面的隐性陷阱控制表的更新和底层资源操作很难做到绝对原子。分布式环境不存在一个事务能同时覆盖本地数据库和远程库存中心。所以这里有一个取舍——你的控制表记录、业务表数据必须在同一个库同一个事务里但资源管理器比如远程扣减服务的调用只能做到“尽量同步、失败补偿”。这意味着如果网络断了可能发生“控制表记录显示TRYING但底层资源已经预留成功”的情况。此时依赖协调器超时后发起Cancel来纠偏也可能发生“控制表记录显示TRYING但底层资源没有预留成功”此时Try返回失败协调器会走CancelCancel发现TRYING记录执行回滚——但底层根本没有预留回滚会出现幂等问题。所以底层资源操作接口本身必须自带幂等预留和回滚都以xid branchId为幂等键资源服务自己维护预留记录重复预留不重复占用重复回滚不重复释放。这样控制表负责流程状态资源服务负责最终操作幂等两层配合TCC才算真正闭环。6. 面试现场怎么答才加分6.1 三段式答题框架面试遇到这个问题不要上来就背定义。按照“现象定义—解决方案—极端场景”三段式来答逻辑清楚内容也够深。第一段讲清楚什么是悬挂、什么是空回滚建议用一两个短例子带过。比如“Cancel先执行了Try后到Try又把资源预占了但再也不会有后续操作来释放它这就是悬挂”“Cancel到了但分支事务记录不存在没法正常回滚既不能直接失败也不能假装成功这就是空回滚”。第二段直接亮方案核心是一张事务控制表用xid branch_id唯一约束字段包含状态机和标记位。Try阶段先插记录再预留资源遇到终态就防悬挂Cancel阶段无记录就插空回滚记录有TRYING记录就正常回滚到终态。所有操作在同一个本地事务边界内完成。第三段主动补充极端场景网络超时加乱序、Try和Cancel并发冲突、唯一索引兜底、乐观锁状态流转。这一段是拉开差距的地方——大部分候选人都知道控制表但能把并发冲突和幂等细节讲透的并不多。6.2 面试官可能的追问与应对追问一Confirm重复调用怎么办答和Cancel的幂等设计完全一致查状态、CONFIRMED就直接返回。如果发现状态是CANCELED说明事务已经回滚此时Confirm要按异常告警处理但返回成功或失败需要看框架约定一般是返回成功避免全局事务卡死。追问二Try没返回响应但实际执行了怎么知道答正是通过控制表。状态停留在TRYING并且ResoureManager预留记录存在就可以判定Try实际执行了。协调器侧的超时判断加上控制表状态查询是TCC框架里常见的一致性校验手段。追问三为什么不用Redis存控制表答Redis虽然快但无法和业务数据库保持同一个事务边界。控制表和业务数据的强一致性要求二者要么一起提交要么一起回滚只有同一个数据库事务才能做到。Redis只能做辅助缓存不能做核心状态存储。追问四状态机为什么不允许终态再流转答因为终态代表整个分支事务已经有了最终结论。一旦允许CANCELED流转到TRYING悬挂问题就复活了。终态不可变是防悬挂设计的基石这也是状态机设计上最基本的约束。回答完这几个追问面试官基本就能确认你不是背题而是真的理解这套方案的工程取舍。我个人在实际项目里踩过最深的坑是刚开始做TCC时以为加个幂等就万事大吉结果一次网络事故同时触发了悬挂和空回滚排查了一整天才意识到问题的根源在于“没有一张记录事务进度的表”。后来把事务控制表和状态机这套设计沉淀下来所有和TCC相关的业务都稳定多了包括后来做Saga方案时也沿用了这同一套“先记录、后操作、终态不可逆”的思路。所以如果你正在设计类似方案不用纠结于技术选型的新旧把控制表和状态机这两个基本功打扎实比什么都管用。面试答这题的时候能把手画的这张状态机流程图讲清楚再补一句“记录写入必须先于业务操作”基本就是高分答案了。
