有个微服务架构下分布式事务的一致性保障及高并发压测失效问题

Question

33 浏览2024年5月6日

0

毛彦甫 2024年4月1日 0条评论

毕业论文题目是“基于 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。

附上我的系统拓扑图和压测曲线。求指点！

score 0 · Answer 1 · 2024-04-23T08:58:41+00:00

关于连接池爆满，你检查一下 druid 或 hikari 的最大连接数配置了吗？ Seata 的代理数据源会对 SQL 进行解析和重写，这个过程很吃 CPU。建议：

开启 Seata 的 Async Commit（异步提交）选项，让分支事务在二阶段直接异步清理日志，能显著降低主线程的阻塞时间。

检查数据库索引。如果分布式事务扫描的是全表，锁定时间会无限拉长。