在微服务架构中，一个下单操作往往要同时扣减库存、冻结余额、生成订单记录，这些动作分散在不同的服务里，传统的本地事务已经无能为力。TCC（Try-Confirm-Cancel）模式把每个业务操作拆成三个阶段，由业务方自己实现资源预留与释放逻辑，从而在性能和一致性之间取得平衡。但TCC并不是免费的午餐，它要求有一个可靠的事务协调器来记录每个分支事务的状态、驱动Confirm或Cancel的执行、处理超时与重试。本文将围绕如何把这样一个协调器容器化部署展开，涵盖原理分析、架构设计与关键代码实现。
一、TCC事务协调器到底要做什么
先明确协调器的定位。TCC模式下，每个参与者需要提供三个接口：try负责资源预留，比如冻结100元额度；confirm确认提交，把冻结额度真正扣除；cancel取消预留，把冻结的额度释放回去。协调器的职责就是串起这三个阶段：在事务发起方调用各参与者的try接口时，记录全局事务和分支事务的上下文；当所有try都成功后，统一触发confirm；只要有任何一个try失败，就统一触发cancel。
听起来简单，但真正的难点在异常场景。某个参与者try成功后进程挂了怎么办？confirm调用超时是重试还是回滚？协调器自己重启后如何恢复未完成的事务？这些问题的答案都指向同一个设计：事务状态必须持久化，协调器的所有决策都必须基于持久化存储中的状态机，而不是内存。这也是后续容器化部署的前提条件——容器随时可能被销毁重建，协调器必须做到无状态或有可靠的状态恢复机制。
一个典型的状态流转模型如下：
// 全局事务状态
enum GlobalTxStatus {
TRYING, // try阶段进行中
CONFIRMING, // 正在执行confirm
CANCELLING, // 正在执行cancel
FINISHED // 终态：成功或已回滚
}
// 分支事务状态
enum BranchTxStatus {
REGISTERED, // 已注册，尚未执行try
TRIED, // try执行成功
TRY_FAILED, // try执行失败
CONFIRMED, // confirm成功
CANCELLED // cancel成功
}状态机的每一次流转都要先落库再执行动作，即所谓的Write-Ahead思路：先把状态改成CONFIRMING并提交事务，再真正调用参与者的confirm接口。这样即使协调器在调用过程中崩溃，重启后读取数据库发现状态是CONFIRMING，就知道应该继续重试confirm，而不是误判为失败去执行cancel。这个细节是保证TCC正确性的关键，很多自研协调器的bug都出在这里。
二、协调器的核心实现要点
协调器的核心是一个事务管理服务加一个补偿调度器。事务管理服务负责接收事务注册、状态上报等请求，补偿调度器则周期性扫描超时事务并驱动状态机前进。下面用Java风格的伪代码展示主干逻辑。
@Service
public class TransactionCoordinator {
// 注册全局事务，生成全局事务ID
public String begin(BusinessKey key) {
String txId = IdGenerator.next();
txRepository.save(new GlobalTransaction(txId, key, GlobalTxStatus.TRYING));
return txId;
}
// 注册分支事务
public void registerBranch(String txId, BranchInfo branch) {
txRepository.saveBranch(txId, branch, BranchTxStatus.REGISTERED);
}
// 分支上报try结果，全部成功则进入confirm，否则进入cancel
public void reportTryResult(String txId, String branchId, boolean success) {
txRepository.updateBranchStatus(branchId,
success ? BranchTxStatus.TRIED : BranchTxStatus.TRY_FAILED);
GlobalTransaction tx = txRepository.lockAndLoad(txId);
if (allBranchesTried(tx)) {
boolean anyFailed = tx.getBranches().stream()
.anyMatch(b -> b.getStatus() == BranchTxStatus.TRY_FAILED);
// 先落状态，再执行动作，保证崩溃恢复后决策一致
txRepository.updateGlobalStatus(txId,
anyFailed ? GlobalTxStatus.CANCELLING : GlobalTxStatus.CONFIRMING);
executor.submit(anyFailed ? () -> doCancel(tx) : () -> doConfirm(tx));
}
}
private void doConfirm(GlobalTransaction tx) {
for (BranchInfo b : tx.getBranches()) {
retryTemplate.execute(() ->
participantClient.confirm(b.getAddress(), tx.getTxId()));
}
txRepository.updateGlobalStatus(tx.getTxId(), GlobalTxStatus.FINISHED);
}
private void doCancel(GlobalTransaction tx) {
// 只对try成功或已注册的分支执行cancel
for (BranchInfo b : tx.getBranches()) {
if (b.getStatus() == BranchTxStatus.TRIED
|| b.getStatus() == BranchTxStatus.REGISTERED) {
retryTemplate.execute(() ->
participantClient.cancel(b.getAddress(), tx.getTxId()));
}
}
txRepository.updateGlobalStatus(tx.getTxId(), GlobalTxStatus.FINISHED);
}
}有几个实现细节值得展开。第一，confirm和cancel的调用必须带幂等保护，因为重试机制决定了参与者可能收到重复请求，业务侧通常用事务ID加资源流水号做唯一索引来防重。第二，cancel还要处理空回滚问题：如果参与者的try请求因为网络原因根本没到达，cancel到来时本地没有任何预留记录，直接返回成功即可，但必须记录一条空回滚日志，防止后续迟到的try又把资源冻结住却没人释放，这就是常说的悬挂问题。第三，补偿调度器的扫描频率不宜过高，一般5到10秒扫一次TRYING状态且超过60秒未更新的事务即可，避免数据库压力过大。
三、容器化部署：从Docker镜像到Kubernetes编排
协调器代码写好后，怎么在容器环境里稳定运行是另一个话题。协调器与普通无状态Web服务不同，它内部有补偿调度器这种后台线程，直接水平扩容会导致多个副本同时扫描同一批事务，产生重复的confirm或cancel调用。虽然幂等设计能兜底，但大量重复请求会浪费资源，也放大了参与者的压力。常见的解法有两种：一是引入分布式锁，扫描前先抢占数据库行锁或Redis锁；二是干脆做角色分离，把API服务与调度器拆成两个Deployment，调度器副本数固定为1，API服务可以自由扩容。
Dockerfile的编写要注意时区与JVM参数的配合。容器内默认时区往往是UTC，事务日志的时间戳如果不统一，排查问题时会非常痛苦。下面是一个可参考的Dockerfile：
FROM eclipse-temurin:17-jre-alpine
# 设置时区，避免事务时间戳混乱
RUN apk add --no-cache tzdata && \
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \
echo "Asia/Shanghai" > /etc/timezone
WORKDIR /app
COPY target/coordinator.jar app.jar
# 容器环境建议显式指定JVM参数，限制堆内存
ENV JAVA_OPTS="-Xms512m -Xmx512m -XX:MaxMetaspaceSize=128m"
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar app.jar"]Kubernetes编排中，健康检查的设计要区分liveness与readiness。协调器在启动后需要从数据库加载未完成事务、恢复补偿线程池，这个阶段服务虽已监听端口，但尚未就绪，此时应通过readiness探针把流量挡在外面。liveness探针则建议加上启动缓冲期，避免容器启动慢被反复重启。参考配置如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: tcc-coordinator
spec:
replicas: 2
strategy:
rollingUpdate:
maxUnavailable: 0
maxSurge: 1
template:
spec:
containers:
- name: coordinator
image: registry.ipipp.com/tcc/coordinator:1.4.0
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /actuator/health/readiness
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
lifecycle:
preStop:
exec:
command: ["sh", "-c", "sleep 10"]四、优雅停机与高可用容灾
容器随时可能被杀死，协调器收到SIGTERM信号后不能立刻退出，必须先把正在执行的confirm或cancel请求处理完，或者至少保证状态已经落库，让接管的实例可以继续。Spring Boot中可以注册一个SmartLifecycle Bean，在stop回调里先关闭补偿调度器，再等待正在飞行的事务动作完成，最后才关闭HTTP服务。配合terminationGracePeriodSeconds设置一个足够的宽限期，比如60秒，就能保证滚动更新期间事务不丢失。
高可用方面，多副本协调器依赖数据库乐观锁保证决策一致性：状态更新语句带上版本号条件，update global_tx set status='CONFIRMING', version=version+1 where tx_id=? and version=?，只有一个副本能更新成功，其他副本更新失败后直接放弃，简单而有效。数据库本身建议使用带主从切换能力的MySQL集群或云上RDS，协调器实例挂掉的影响只是事务补偿延迟几秒，不会造成数据不一致。
五、总结
容器化TCC事务协调器的核心思路可以归纳为三点：事务状态全部持久化并遵循先落库再执行的原则，保证崩溃恢复后决策一致；confirm与cancel接口做幂等、防空回滚、防悬挂三重防护；容器化部署时处理好调度器多副本冲突、健康检查与优雅停机。TCC的业务侵入性确实比消息事务、Saga模式要高，但它换来了更强的实时一致性，适合资金、库存这类对准确度要求苛刻的场景。如果你正在评估分布式事务方案，不妨先从实现一个最小化的协调器原型开始，把状态机与补偿逻辑跑通，再逐步补齐容器编排与监控告警，这样迭代路径最稳。