分布式幂等面试题：HTTP、MQ、任务、状态机与副作用

本页只放标准回答，完整状态模型、Demo和Runbook见幂等主线。

问题	标准回答	原理页
幂等是什么	同一业务意图重复执行，只产生一次业务效果，并返回与第一次相容的结果；它不阻止重复到达。	定义
重复从哪里来	HTTP超时重试、MQ至少一次、支付回调、调度补偿、用户连点、服务重启和CDC重放都会产生重复。	重复来源
超时为什么不能直接重试	超时只说明没按时得到结果，下游可能已提交但响应丢失；先按业务流水查询事实，再决定幂等重试或补偿。	结果未知
幂等键怎样设计	标识稳定业务意图并跨重试不变，包含合适租户/操作作用域；同Key还要保存请求摘要防止参数不同复用结果。	幂等键、摘要
traceId能当幂等键吗	通常不能，traceId标识一次调用尝试或链路，重试可能变化；幂等键要标识业务意图。	幂等键
幂等状态有哪些	常见PROCESSING、SUCCESS、FAILED_RETRYABLE、FAILED_FINAL等；重复请求根据状态返回原结果、等待、接管或拒绝。	状态模型
为什么先查后插不安全	两个并发请求都可能查到不存在，再同时执行副作用；应先用唯一约束或条件更新原子抢占。	竞态、原子抢占
幂等记录和业务怎样原子	同库时在一个本地事务中完成幂等占位、业务写入和结果记录；否则可能出现记录成功但业务失败或相反。	同事务模式
PROCESSING卡住怎么办	用ownerToken和lease标识处理者，过期后先查事实源，再补成功、条件接管或转人工，不能看到超时就直接重做。	租约
HTTP接口怎样幂等	客户端提供稳定Idempotency-Key，服务端原子抢占、校验摘要、执行事务并保存响应，重复请求复用结果。	HTTP流程
支付回调怎样幂等	校验签名和金额，以支付平台流水唯一约束，订单状态条件更新，已处理回调返回成功避免平台无限重试。	支付回调
MQ消费者怎样幂等	以consumerGroup+eventId唯一占位，业务写与消费结果同事务提交，之后ACK；ACK丢失重投时复用成功记录。	MQ消费、事务边界
Redis SETNX够不够	只适合短时防抖；TTL、淘汰、故障切换以及Redis与数据库双写窗口都可能失效，关键业务要数据库约束。	SETNX边界
分布式锁能替代幂等吗	不能。锁可能过期、脑裂或误删，只控制并发入口；幂等还要吸收顺序和时间上重复。	锁边界
定时任务怎样幂等	使用业务周期+任务类型唯一键、状态条件更新、分片归属和结果记录，调度框架不保证Exactly Once。	定时任务
幂等记录保留多久	至少覆盖最大重试、消息保留、回调和补偿窗口；资金审计可能长期保留，过早清理会让旧重复重新生效。	去重窗口
热点幂等键怎么办	避免轮询风暴，使用请求合并、等待通知、状态查询限流和结果缓存，但最终状态仍以事实库为准。	热点
线上重复执行怎么查	按业务键聚合请求、幂等记录、数据库流水、MQ Attempt和外部副作用，确认是抢占竞态、租约接管还是ACK丢失。	Runbook

本章小结

幂等面试应沿“稳定业务意图—原子抢占—同事务副作用—结果复用—过期恢复”回答。