消息队列消费出现大量重复消费，业务侧已有幂等逻辑但仍产生重复扣款。请设计排查方案并说明幂等键、去重窗口和补偿机制如何配合。

我会先把这个问题拆成两部分看：一部分是为什么 MQ 出现大量重复投递或重复消费，另一部分是为什么业务幂等没有挡住重复扣款。因为 MQ 本身通常只能保证至少一次投递，重复消息是正常可能发生的，关键是扣款链路必须做到业务级幂等。

排查时我会按链路从上到下看。

先看消息侧：确认重复消息是生产端重复发送，还是消费端重复消费。可以通过 messageId、业务单号、traceId、发送时间、消费时间来串起来。如果同一个业务单号对应多个不同 messageId，说明可能是生产端重试或者上游重复触发；如果是同一个 messageId 被多次消费，那重点看消费者 ack 机制，比如消费成功后 ack 失败、消费超时、消费者重平衡、实例重启、处理时间超过锁定时间等。

然后看消费端：重点查消费者是否在扣款成功之前就提交 offset，或者扣款成功之后 ack 失败导致消息重新投递。如果是 RocketMQ、Kafka、RabbitMQ 这类 MQ，都要确认提交 offset / ack 的时机是否合理。一般应该是业务处理成功后再确认消息，但这也意味着确认失败时会重复消费，所以业务幂等必须可靠。

接