问TDMQ RabbitMQ 消费幂等记录过期后，如何防止旧消息重复入账？

想请教 TDMQ RabbitMQ 消费端幂等记录的保留边界。这是方案设计问题，尚未做线上故障复现，没有实际报错。 拟用环境：腾讯云消息队列 RabbitMQ 版、Java 消费者、MySQL 8.0；手动 ACK，消息携带稳定的业务事件 ID。业务是账本流水写入，同一事件不能重复入账。正常消费之外，还需要考虑死信队列中的消息在排障后被人工重新投递。 已经查阅腾讯云的 RabbitMQ 客户端实践与消息可靠性文档，理解消费端需要自行保证幂等。目前推演的方案是：把事件 ID 插入带唯一索引的去重表，与账本变更放在同一个 MySQL 事务中，事务提交后再 ACK。这样可以覆盖提交成功但 ACK 前断连的窗口。尚未验证的边界是：去重记录若只保留 30 天，之后再重放较早的死信，原事件 ID 就可能被当作新事件。30 天只是拟定的存储清理策略，不是产品默认值。 想确认三点： 1. 在允许人工死信重放的前提下，主队列的消息 TTL 能否作为去重表清理依据？还需要约束哪些重投递或重放路径，才能定义可靠的最大重复窗口？ 2. 如果没有可强制执行的最大重放期限，是不是应把事件 ID 的唯一约束保留在长期账本中，而不依赖短期去重表？历史账本归档时通常如何延续这一约束？ 3. 超出业务允许期限的旧事件再次到达，如何区分“已入账的重复事件”和“从未成功入账的迟到事件”，避免简单按消息时间丢弃导致漏账？ 希望讨论上述设计边界与可验证的故障场景，不要求消息队列实现 exactly-once。