标准答案
- 请求去重通常保存幂等键、请求参数摘要、处理状态和响应结果，防止同一客户端重复提交。
- 消息去重保存事件 ID、来源、版本和处理结果，覆盖重试、回放和延迟投递窗口。
- 业务幂等还要依靠唯一约束、状态机或版本记录，不能只保存“见过这个 ID”。
- 保留期应覆盖客户端重试、消息保留、对账和人工恢复周期，并考虑清理后的迟到请求。
题目解析
请求去重、消息去重和业务幂等的对象不同：前者关联一次 API 调用，中间者关联一个事件，后者要保证最终副作用不重复。它们可以共用幂等键思想，但不能共用一套不分场景的保留策略。
可靠证据至少要能回答是否已经受理、当前是否 processing、最终结果是什么，以及请求参数是否与第一次一致。只有一个布尔值无法处理崩溃恢复、参数冲突和结果复用。
保留期要覆盖所有可能的重复来源，包括客户端重试、消息保留、延迟投递、人工重放和对账周期。清理前要确认迟到请求会怎样处理，避免删掉证据后重新执行副作用。
常见误区
- 误区：只按 IP 去重。改正：使用业务幂等键、事件 ID 或请求 ID，IP 只能作为风控维度。
- 误区：幂等表不校验同一 Key 的参数。改正：保存参数摘要或关键字段，不一致时返回冲突，避免把两个业务请求误合并。
- 误区：保留期短于消息重放窗口。改正：按客户端重试、消息保留、对账和人工恢复的最大窗口设置保留期。