毕业论文题目是“基于 Seata 的高性能微服务分布式事务一致性优化研究”。目前在搭建实验环境进行压力测试时，遇到了两个非常棘手的问题，严重影响了对比实验的数据结果：
-
高并发下的全局锁竞争：在模拟双十一秒杀场景时，我使用了 Seata 的 AT 模式。当并发线程达到 2000+ 时，数据库连接池瞬间爆满，大量请求因为等待全局锁（Global Lock）超时而报错。
-
具体困惑：数据回滚残留：在模拟网络分区（Network Partition）故障时，虽然 Seata 触发了回滚，但由于下游某服务处于宕机状态，Undo Log 无法被正确清理，导致数据库中出现了大量的“僵尸数据”，手动清理非常麻烦。响应延迟：加入分布式事务后，系统的平均响应时间（RT）比不带事务时增加了 3 倍。大家在写论文时，是如何平衡 强一致性 和 系统吞吐量 的？
-
开发环境：Spring Cloud Alibaba, Seata 1.5.2, MySQL 8.0, Redis 6.0。
附上我的系统拓扑图和压测曲线。求指点！
回滚残留的问题，建议检查一下你的 RM（资源管理器） 是否配置了自动重试机制。 如果下游服务宕机，Seata TC 会持续发起回滚请求。你需要配置一个死信队列或者手动补偿接口。 论文里可以画一个 CAP 定理 的权衡图，重点讨论在弱网络环境下，你的系统是如何在 A（可用性）和 C（一致性）之间做动态权衡的。
关于连接池爆满，你检查一下 druid 或 hikari 的最大连接数配置了吗？ Seata 的代理数据源会对 SQL 进行解析和重写，这个过程很吃 CPU。 建议：
开启 Seata 的 Async Commit（异步提交） 选项，让分支事务在二阶段直接异步清理日志，能显著降低主线程的阻塞时间。
检查数据库索引。如果分布式事务扫描的是全表，锁定时间会无限拉长。
建议很及时，我准备把库存服务改成 TCC 模式试一下。