perf: collapse short submit result callbacks

2026-08-21 10:46:27 +08:00
parent fcf6d3e6b4
commit 3c6f1beed1
5 changed files with 9 additions and 1 deletions
@@ -3843,3 +3843,4 @@ git diff --check
 - 首轮正价三运营商100条/秒生成2999条，2999/2999 SubmitResp成功、P50/P95/P99=`32/68/130ms`，Inbox与唯一MessageId均2999；移动/联通/电信分别998/996/1005，六通道最终各承载488至514条，证明主动双活与跨运营商分流有效。注入结束时仅388条完成扣费，命令Stream`128/2131`、结果Outbox`32/192`、等待锁/idle in transaction各5，按停止线不升200档。
 - 该轮最终双Stream归零，冻结/释放各2999、正式扣费2987、退款30、12条供应商最终拒绝只释放不扣费；SmsBillingRecord为charged2957/refunded30，余额恒等式精确成立，六通道与数据库最终无等待锁/idle in transaction。证据确认瓶颈是每个正价Submit结果在企业账户锁上串行，而不是单价0时可见的通道容量。
 - 后续最小修复将正常“释放冻结+正式扣费”改为单个幂等SQL：冻结已在入口扣减，流水对净余额为零，因此正常结算不再取得账户锁或更新账户；历史已释放未扣费状态仍用原带锁路径补扣，并保留并发`ON CONFLICT`后一次MVCC恢复读。专项134项和TypeScript已通过，完整门禁、修复提交、新恢复资产与复测待补记。
+- 无账户锁修复后100条/秒复测仍在注入结束出现命令Stream`128/1687`、结果Outbox`32/452`；相同观测点完成扣费从388提高至637、等待锁降为0，但单分片短信同时发布分片与聚合两个结果事件，仍造成约双倍API回调和分片审计写入。新增最小Gateway修复：单分片只发布已携带完整segments的聚合事件，多分片仍逐片先持久化，待新恢复资产和同口径复测。