分布式事务压测，先说明成功到底指什么

分布式事务压测先说明成功到底指什么分布式事务的压测结果必须先说明“成功”的定义。尝试次数、提交次数、业务最终成功数和重试成本不是同一件事。只报平均 TPS 很容易掩盖冲突、超时和长尾。将工作负载和指标拆开测试报告应给出键空间、读写比例、事务大小、隔离级别、并发、预热时间、持续时间和冲突分布。均匀分布与热点分布回答的是不同问题不要用其中一种代表所有业务。有效吞吐可定义为在观察窗口内完成且业务语义正确的事务数。回滚、重试、死锁和客户端超时应单列。延迟至少区分成功与失败路径并报告分位数和采样方法。后台 GC、复制或日志压缩也要覆盖足够长的窗口避免只测到前台路径。type Report struct { Attempts int64 Committed int64 Aborted int64 Window time.Duration } func (r Report) Goodput() float64 { if r.Window 0 { return 0 } return float64(r.Committed) / r.Window.Seconds() }这里的Committed需按业务定义过滤例如异步补偿尚未完成的事务不能简单归为成功。不把模型对比写成定论乐观、悲观、2PC、Saga 等模式的表现依赖冲突、隔离、重试和业务补偿。报告应说明每种模式的适用条件和未覆盖的失败路径。遇到热点先确认数据模型、访问顺序和重试退避再选择事务策略。