tcc适合强一致性场景，本地消息表适合异步解耦场景。tcc通过try-confirm-cancel三阶段处理，适用于支付、订单、库存等需多服务同时变更状态的高一致性需求，实现复杂但实时性强；本地消息表通过数据库事务保障本地操作与消息写入一致，适合日志、通知等允许短暂不一致的异步场景，实现简单但存在延迟。两者选型应根据业务一致性要求和技术能力决定。
微服务架构下，事务处理不能像单体应用那样简单用数据库事务搞定。Golang写的微服务也一样，面对跨多个服务的数据一致性问题，得靠分布式事务方案来兜底。TCC和本地消息表是比较常见、落地性比较强的两种做法，下面从使用场景、实现逻辑和注意事项几个角度讲清楚。
什么是TCC？怎么在Golang中用？
TCC（Try-Confirm-Cancel）是一种补偿型事务机制，把一次分布式操作拆成三个阶段：Try（资源检查与锁定）、Confirm（执行业务操作）、Cancel（回滚）。它不依赖全局事务协调器，而是通过业务代码自己控制。
比如下单减库存加订单的例子：
立即学习“go语言免费学习笔记（深入）”；
- Try阶段：订单服务创建订单但状态为“待确认”，库存服务预扣库存。
- Confirm阶段：两个服务都成功就正式提交（订单变“已确认”，库存真正减少）。
- Cancel阶段：任一失败，调用 Cancel 接口释放资源（订单取消，库存回退）。
在Golang中，你可以用一些框架如 DTM 或者自建流程引擎来管理这些步骤。关键点是每个服务都要提供 Try/Confirm/Cancel 三个接口，并且保证幂等性。
注意事项：Confirm 和 Cancel 要设计成幂等的，防止网络重传导致重复执行需要一个事务协调器记录状态，用于失败后自动重试或人工介入
本地消息表怎么做？适合什么场景？
本地消息表是另一种轻量级的最终一致性方案，核心思想是在本地数据库中记录一个事务消息，再异步发送给其他服务，借助数据库的事务特性保证本地操作和消息写入的一致性。
举个例子，用户注册送积分的服务：
- 用户服务在一个事务里完成插入用户数据的同时，往一张
message_log表里写一条“发积分”的消息； - 然后后台有个定时任务不断扫描这张表，把消息发到MQ或者直接调用积分服务API；
- 积分服务收到后执行加分操作，并返回结果，用户服务再标记这条消息为已处理。
这个方式的好处是不依赖第三方事务中间件，实现成本低，适合对实时性要求不高、但又需要可靠消息传递的场景。
实现要点：
- 消息写入和主业务操作必须在同一个数据库事务中
- 消息处理要有重试机制，避免失败丢失
- 建议加上唯一标识做幂等，防止重复处理
TCC vs 本地消息表，该怎么选？
这两个方案各有适用范围：
- TCC 更适合对一致性要求较高、涉及多个服务同时变更状态的场景，比如支付+库存+订单这种组合操作。但它开发复杂度高，需要维护三段式逻辑。
- 本地消息表 更适合异步解耦、允许短暂不一致的情况，比如日志记录、通知类操作。实现简单，但可能有延迟。
如果你的服务间交互频繁、对一致性要求高，可以考虑引入TCC；如果只是需要异步保障消息送达，本地消息表会更轻便。
基本上就这些。这两种方案都不是银弹，实际选型还得看你的业务需求和技术能力。
