用 Redis 做消费幂等时如何设置 Key 过期时间，处理未完就过期会怎样？

核心回答

先区分两种生命周期：处理租约防止多消费者同时处理，完成记录防止同一业务事件在将来再次生效。处理中标记的 TTL 要覆盖正常处理与调度抖动，必要时续租；完成记录的保留期则要覆盖消息重试、重放和业务追溯窗口，不能用同一个短超时混在一起。

若处理未完成标记就过期，另一个消费者可能重新进入，旧消费者仍继续执行，形成并发重复副作用。即使处理正常结束，完成标记过早过期，也会让迟到的重复消息再次执行。因此资金、订单等重要动作应有持久的业务唯一约束或去重记录作为最终防线。

怎样组织消费状态

可以按稳定业务事件标识维护待处理、处理中、已完成、可重试失败等状态。领取时使用原子操作和持有者标识；只有当前持有者能续租或释放处理权。消费完成后，把业务更新与持久去重记录放在同一个本地事务中提交，再确认消息。

重复消息若发现已经完成，返回已处理结果；发现仍在处理，应按队列语义延后检查，不能立即当成功丢弃尚未完成的工作。发生超时接管时，还需要版本条件或其他资源端约束，阻止旧执行者恢复后重复写入。

TTL 不是凭经验填一个固定数字

处理租约依据最长可接受任务时间、正常尾延迟与续约周期确定，并设置业务截止时间。去重保留期依据消息保留时间、最大重试和运维重放范围确定；手工重放可能跨越缓存保留期，必须纳入业务约束。

Redis 标记还可能因淘汰、重启或故障切换丢失。若先扣款后写完成标记，扣款成功、标记写失败就会产生重复扣款风险；若先写完成再扣款，又可能丢掉业务。缓存标记优化并发与查询，最终正确性仍由可原子提交的业务状态或下游幂等接口保证。

对应教程

参考资料