做微服务的团队，几乎都绕不开分布式事务这个坎。
很多人选型时只盯着功能清单看：支持几种模式、社区活不活跃、注解好不好用，结果一上线到高并发场景才发现，响应时间直接翻倍，吞吐量上不去，再想换框架成本就高了。
最近我们针对核心下单接口做架构优化，专门拿 Seata 和 ByteTCC 这两款最常用的框架，在真实 API 场景下跑了一轮完整压测。今天就从架构根源、实测数据、选型建议三个维度讲透，看完你就知道自己的项目该选哪个。
一、先搞懂本质：两款框架的架构差在哪？
性能差距从来不是靠代码优化堆出来的，根子上是架构设计的区别。一个走中心化调度，一个走嵌入式协调，路线完全不同，性能上限自然天差地别。
1. Seata：带 “中央总指挥” 的全能选手
Seata 的核心逻辑是单独部署一个 TC 事务协调器，所有服务的事务分支都要向它注册、提交、回滚，相当于整个系统里有个总指挥，所有事务流程都听它统一调度。
它最大的优势是模式全，AT、TCC、Saga、XA 四种模式都支持，团队可以根据业务场景随便换。比如后台系统用 AT 模式，加个注解就接入，几乎不用改业务代码；核心链路用 TCC 模式，自己控制锁粒度，性能更好。
但代价也很明显：所有事务都要绕 TC 走一圈，单次事务要多好几次网络交互。服务分支越多，往返次数就越多，TC 本身很容易成为整个系统的性能瓶颈，高并发下很容易被打满。
2. ByteTCC：“去中心化” 的纯 TCC 玩家
ByteTCC 走的是完全相反的路线：协调器直接嵌在业务进程里，不用单独部署节点。事务发起方本地管理事务状态，事务上下文跟着业务请求在调用链里透传，每个参与方靠本地状态机执行二阶段操作。
这种架构的好处很直接：没有中心化瓶颈，协调逻辑分布式执行，也省去了和独立 TC 的多次 RPC 交互，事务链路更短，天然适合低延迟场景。
但它也有短板：事务状态存在本地数据库，出问题排查起来没有全局视角方便；而且只支持 TCC 一种模式，业务代码侵入性高，开发量要大不少。
3. 为什么架构直接决定性能上限
拿最常见的 “下单扣库存 + 扣余额” 双分支 API 举个例子：
Seata TCC 模式下，要先开全局事务、两个分支分别注册、执行业务，最后 TC 再分别通知提交，全程至少 7 次网络交互
ByteTCC 模式下，本地开事务、透传上下文、直接调用两个分支，本地状态机驱动提交，全程只要 4 次网络交互
别小看这两三跳的差距，在高并发场景下，网络往返的开销会被成倍放大，这就是两者性能差异的根源。
二、真实场景压测：性能差距比你想的还大
光说架构太虚，我们直接上实测数据。测试模拟的是电商核心下单 API，包含订单创建、库存扣减、余额扣减三个服务分支，两款框架都采用 TCC 模式实现，保证对比公平。
测试环境与方法
业务服务用 3 台 4C8G 机器，三个服务各部署一个节点；Seata 单独用一台 2C4G 机器部署 TC，用数据库存储模式；数据库统一用 8C16G 的 MySQL 8.0，各服务独立分库，全程同机房内网调用。
我们用压测工具阶梯式加压，从 50 并发起步，每分钟加 50 并发，直到错误率超过 1% 或者响应时间出现明显拐点，最后取 200 并发下稳定运行 10 分钟的数据做对比。
核心性能数据对比
表格
性能指标Seata TCCByteTCC性能差异
平均 TPS12871856ByteTCC 高 44.2%
平均响应时间142ms98msByteTCC 快 31.0%
P95 响应时间268ms165msByteTCC 快 38.4%
P99 响应时间412ms247msByteTCC 快 40.0%
事务失败率0.12%0.08%基本持平
几个关键实测结论
第一，并发越高，ByteTCC 的优势越明显。200 并发下吞吐量已经高出 44%，到 300 并发时 Seata 的 TC 节点 CPU 直接打满，响应时间开始非线性上涨，而 ByteTCC 还能继续扛压。
第二，低并发场景下差距很小。50 并发以内时，两者性能差距在 15% 以内，这时候业务逻辑本身的耗时占主导，框架开销不明显。
第三，Seata 的 AT 模式性能比 TCC 差很多。相同环境下 AT 模式 TPS 只有 856 左右，比 TCC 模式低了 33%，主要是全局锁持有时间长，高并发下锁竞争太严重。
第四，两者的瓶颈点完全不一样。Seata 卡脖子的是 TC 节点，所有事务都走它调度，网络 IO 和状态存储很容易到上限；ByteTCC 的压力分散在各个业务节点，主要瓶颈是本地事务日志的写入，以及高并发下状态机的竞态重试。
三、直接抄作业：不同场景怎么选？怎么优化？
性能不是唯一标准，还要结合开发成本、运维能力、业务要求综合判断。我们整理了不同场景的选型建议，以及亲测有效的优化手段，直接对应自己的业务就行。
四种典型场景选型建议
后台管理类接口、并发不高、迭代快：选 Seata AT 模式。开发效率最高，一个注解就能接入，几百 TPS 的量级完全够用，不用在事务上浪费开发精力。
核心交易接口、高并发、对延迟敏感：选 ByteTCC。比如秒杀、支付这类峰值流量场景，嵌入式架构延迟更低，没有中心化瓶颈，性能优势很明显。
复杂业务链路、多服务编排、一致性要求高：选 Seata TCC+TC 集群。中心化协调更可靠，事务状态全局可查，出问题好排查，TC 用 Raft 模式做高可用，稳定性有保障。
异构技术栈、跨语言 API 调用：选 Seata。多语言 SDK 支持更完善，ByteTCC 基本只适配 Java 生态，跨语言几乎没法用。
亲测有效的性能优化技巧
如果已经选定了框架，下面这些优化手段，在 API 场景下都能带来明显的性能提升。
Seata 优化方向：
把 TC 的存储模式从 DB 换成 Raft，事务状态写入性能能提升 40% 左右，也避免了数据库成为 TC 的瓶颈。
开分支事务异步提交，减少 Try 阶段的阻塞时间，接口响应会快不少。
按业务域拆分 TC 集群，不同业务线用独立的 TC 节点，避免核心业务和边缘业务互相影响。
ByteTCC 优化方向：
事务日志表按天分表，避免单表数据量越来越大，影响写入和查询性能。
调优补偿线程池的参数，根据业务峰值设置合理的线程数和队列长度，避免补偿任务堆积。
核心接口把幂等校验前置，减少重复执行的数据库交互，也能避免异常场景下的脏数据。
最后多说一句，分布式事务从来没有银弹。Seata 胜在生态完善、模式灵活、运维管控方便，适合绝大多数业务场景；ByteTCC 胜在纯 TCC 场景下的性能优势，适合对延迟和吞吐量有极致要求的核心接口。
别人的压测数据永远只是参考，上线前一定要结合自己的业务模型跑一轮真实压测，这比任何第三方 benchmark 都靠谱
