系统需要对外发送事件，消费者响应慢或超时很常见。 重点需要在“要支持签名、重放防护、重试和死信。”这一约束下形成可验证方案。
问题正文
系统需要对外发送事件，消费者响应慢或超时很常见。
要支持签名、重放防护、重试和死信。
得到事件 ID、投递状态机和消费者幂等契约。
希望回答能说明推荐方案、关键取舍、失败模式和验证步骤。如果存在多个适用边界，请给出决策条件，而不是只列工具名称。
ANSWERS
回答内容
针对“Webhook 怎样做到至少一次投递又不让消费者重复处理？”，推荐先把目标、风险边界和可验证证据写成契约，再逐步扩大自动化范围。数据库与异步系统优先保证可恢复性和可观测性；至少一次交付配合业务幂等，比宣称 exactly-once 更可靠。
1）建立基线：定义稳定主键、状态机、租约和幂等键。2）控制执行：把扩展、回填、切换与收缩拆成可回滚阶段。3）处理失败：限制连接与并发并监控锁、积压和重试放大。4）形成闭环：用故障注入验证重复、乱序、超时和部分成功。当前场景是“系统需要对外发送事件，消费者响应慢或超时很常见。”，因此应先做小流量或只读演练，再进入真实写入。
得到事件 ID、投递状态机和消费者幂等契约。。至少记录成功率、失败类型、人工接管率、P95 延迟和单位任务成本；对第 39 号方案建立固定回归样例，发布前后使用相同输入对比。
约束是“要支持签名、重放防护、重试和死信。”。不要用单一总分或一次演示代替分层验证，也不要把超时当成失败后直接重放；任何外部副作用都必须具备幂等键、状态查询或补偿动作。
