栈：RocketMQ 5.1.4（proxy 模式）、Java 17、消费端 SimpleConsumer（gRPC 客户端 5.0.7）、下游依赖 MySQL 8.0 + Redis 7.2 场景：库存扣减事件流
stock-deduct，16 个队列，消费端 6 实例，峰值 9200 msg/s，单条 1.8KB
一、现象：迁移 SimpleConsumer 后，重复扣库存从「偶发」变成「每 10 分钟一批」
我们把消费端从 4.x PushConsumer 迁到 5.x SimpleConsumer，迁移后第一周，下游库存服务就报了 14 次「同一笔扣减事件被消费两次」，全部集中在业务耗时 P99 附近的消息上。
量化一下影响面：
stock-deduct日均 6800 万条，迁移后 7 天内出现 213 笔重复消费（旧链路 3 个月才 9 笔）；- 重复集中在业务处理耗时 1.9s～2.2s 的消息——恰好卡在我们设置的
invisibleDuration = 2s边界上； - 其中 11 笔因为幂等表的唯一键约束被拦下，102 笔打到了下游 RPC（下游自己做了幂等），最终 100 笔静默通过，靠对账 T+1 捞回。
这不是 bug，是语义差异被当成等价替换了。
二、根因：invisible time 是「可见性窗口」，不是「消费超时」
4.x 的 PushConsumer 是拉模型：broker 把队列分配给消费者，消费端本地长轮询 PULL_BATCH_SIZE=32 条一批，处理完批量 commit offset，重复窗口是「offset 提交前的已消费条数」。
5.x SimpleConsumer 是 POP 模型，机制完全不同：
receive()从 broker 领取一批消息，broker 立即把这些消息置为 invisible，对同消费组其他实例不可见；- invisible 状态带一个倒计时
invisibleDuration（即 invisible time），倒计时归零且消息未 ack，broker 认为消费端已死亡，消息重新可见，可能被同组另一个实例再次 receive； - 只有显式
ack()才是终态；changeInvisibleTime()可以延长窗口（有次数上限，默认 3 次）。
关键差异一句话：4.x 的重复窗口由「offset 提交节奏」决定，5.x 的重复窗口由「invisible time 与业务耗时的差值」直接决定。
我们把 invisibleDuration 拍成 2s 的依据是「P99 耗时 1.8s，留 10% 余量」——这是 4.x 调 offset 提交间隔的惯性思维。POP 模型下这个余量根本不够：GC 停顿一次 300ms、下游 RPC 抖动一次 200ms，1.8s 的消息就跨过了 2s 窗口，被兄弟实例二次领取。14 次事故里 11 次的触发时刻都伴随一次 Full GC 或下游 P99 抖动，时间线完全对得上。
三、具体做法：窗口量化 + 续期 + ack 纪律
3.1 invisible time 的量化公式（别再拍脑袋）
invisibleDuration = P999(业务耗时) + max(GC最大停顿) + 下游RPC P999 余量 + 安全垫
我们的实测数据：
- 业务耗时 P999 = 2.31s（含下游 RPC）
- G1 最大停顿 412ms（
-Xlog:gc*采样 72h） - 安全垫 500ms
最终 invisibleDuration = 4s，比原值 2s 放大 2 倍。代价是：实例真挂后消息要 4s 才能被接管（原来是 2s），换来重复消费归零。这两个值是一对跷跷板：窗口越大，故障接管越慢；窗口越小，重复越频繁。 业务对重复的容忍度决定往哪头偏——库存扣减这种有幂等兜底的，可以偏小；没有幂等兜底的，必须偏大。
3.2 长耗时任务用 changeInvisibleTime 续期，而不是把窗口拍大
对超过 10s 的慢消息（大单批量扣减），不要全局放大 invisible time，在业务侧续期：
consumer.receive(16, Duration.ofSeconds(4)).forEach(msg -> {
if (isLongTask(msg)) {
// 默认最多续期 3 次，每次 +4s；续期前先确认任务还在推进
msg.changeInvisibleTime(Duration.ofSeconds(4));
}
try {
process(msg);
msg.ack();
} catch (Exception e) {
// 不 ack = 等窗口到期重新投递；需要立即重投才用 changeInvisibleTime(0)
}
});
注意 changeInvisibleTime(Duration.ZERO) 的语义是立即重新可见，这是手动触发重试的手段，不是「立即重试」的银弹——它不保证下一条 receive 一定拿到它。
3.3 ack 纪律：先落幂等，再 ack
1. 业务处理（写幂等表/下游 RPC，必须可重入）
2. 全部成功后再逐条 ack
3. 禁止「先 ack 再异步落库」——ack 即终态，之后没有任何兜底
3.4 监控指标（迁移后必须加的 4 个）
| 指标 | 来源 | 报警阈值 |
|---|---|---|
| 重复消费率 | 幂等表拦截数 / 总消费数 | > 0.01% |
| 窗口到期重投量 | broker POP_CK 相关 metrics | 突增 5 倍 |
| receive→ack 耗时 P99 | 消费端埋点 | > invisible time × 0.8 |
| 续期次数分布 | 消费端埋点 | P99 ≥ 2 次 |
四、踩过的坑（反直觉清单）
- 「不 ack 就会自动重试」只对了一半。 不 ack 的消息要等窗口到期才重新可见，重试延迟 = invisible time 的整数倍。想要「失败立即重试」，4.x 的 16 级重试队列在 SimpleConsumer 里是没有的，得自己用
changeInvisibleTime(0)或业务侧重投实现。 - 续期有次数上限。 默认 3 次，超窗又没 ack 的消息照样重投。我们初版把续期次数理解成无限，一个死循环任务把同一条消息重投了 4 轮才被发现。
- SimpleConsumer 的 receive 是「租约」，不是「分配」。 同组实例数可以随意扩缩，不需要 rebalance 流程，但扩容那一刻，正在处理的消息窗口不受影响——这意味着扩容不能用来「救」正在超窗的消息。
- 顺序语义变了。 5.x POP 模型下，同一队列内跨实例不保序（旧文里 4.x 顺序消费单队列单线程锁的模型，见社区江若衡-355 的复盘），需要严格顺序的链路别简单切 SimpleConsumer。
- 混合消费模式有兼容期限制。 4.x PushConsumer（经 proxy）和 5.x SimpleConsumer 不能同时消费同一 topic 同一消费组，迁移必须选边，灰度期要用不同 consumerGroup 名。
五、结论与可复用清单
核心结论：SimpleConsumer 的重复消费窗口 = f(invisible time, 业务耗时)，迁移 4.x→5.x 时这一项语义必须重新校准，不能沿用旧的 offset 调参经验。
迁移 checklist：
- [ ] invisible time 按「P999 耗时 + GC 停顿 + 安全垫」重算，禁止沿用默认值（默认 3s 对大多数链路偏小）
- [ ] 幂等兜底先于消费端上线（唯一键 / 幂等表，不是「下游会去重」）
- [ ] 加 4 个监控指标：重复率、窗口到期重投量、receive→ack P99、续期次数分布
- [ ] 长耗时任务单独走 changeInvisibleTime 续期，续期次数打点
- [ ] 需要严格顺序的链路评估 POP 模型是否可用，别一刀切
- [ ] 灰度期新旧消费组用不同 consumerGroup，结束后再收敛
这套参数我们是拿 7 天灰度数据校准出来的，上面的公式和阈值可以直接抄，但要按自己链路的 P999 / GC 停顿重新代入。