n8n生产工作流如何应对重复Webhook

同一个 Webhook 到了两次，n8n 的两次执行都显示成功，客户却收到了两封确认邮件。作者用这个生产案例说明：工作流跑绿，只代表执行没有报错，不代表业务只发生了一次。Webhook 应当按「至少投递一次」来设计，重复到达是正常情况。

这篇的价值，是把接收、去重、验签和下游幂等串成一条处理链。不过，作者没有提供性能数据或对照实验，其中关于验签失败也返回 200 的建议，需要结合具体服务商协议判断。

先把事件收下来，再让 LLM 慢慢跑

作者运行了数月的工作流，会接收支付、表单提交或状态变化事件。某次服务商重复投递，造成确认邮件和下游记录各生成了两份。n8n 没有报错，也没有自行重试，重复来自上游。

原因并不复杂：服务商没有及时收到 2xx、响应途中连接断开，或者主动重放事件，都可能再次投递。接收方不能把「收到一个请求」当成「发生了一件新事情」。

作者首先建议缩短接收流程。如果一个请求要等 30 秒，期间调用 LLM、写入 3 个系统、发送邮件，上游可能早已超时并启动重投。

在 n8n 中，可以让入口工作流只负责校验、记录事件、返回 200，再由另一个工作流或后续阶段读取记录，完成耗时操作。

这里的顺序很重要：先可靠记录，再确认接收。如果提前返回成功，事件却没存下来，上游便可能不再补发。原文提出了分阶段处理，但没有展开记录失败时如何响应，以及第二阶段如何领取任务。

快速响应能够减少超时引起的重投，不能阻止服务商主动重放。去重仍然必须做。

去重真正依靠的是唯一约束

重复请求的到达时间不同，n8n execution id 不同，payload 也可能带有新的投递时间或尝试次数。因此，按时间、执行编号或整个 payload 判断，很容易把同一事件认成新事件。

作者建议优先使用服务商在 payload 或 header 中提供的 event id，并以 Stripe、GitHub 为例。接入时仍需确认该字段究竟标识业务事件还是某次投递，以及重投时是否保持不变。

没有 event id，就从业务内容构造自然键，例如「支付 ID＋状态」「订单 ID＋事件类型」「记录 ID＋所响应的变化」。不能给每次请求生成随机 ID，否则每份副本都会成为新事件。

但选对键只完成了一半。

去重的关键，是让数据库原子地决定谁获得处理资格。

作者要求在产生任何副作用之前，依靠 unique constraint 加 insert-if-absent 完成占位：插入成功的继续，触发重复约束的停止。

「先查有没有，再决定插入」存在竞态。两个并发请求可能都查到不存在，然后同时执行后续操作。即使 n8n 流程图看起来是一条直线，不同执行实例之间仍然可以并发。

自然键也需要谨慎设计。如果业务允许某种状态多次出现，只用「记录 ID＋状态」可能误吞合法事件。原文给出了选键方向，没有提供适用于所有业务的通用公式。

验签和下游幂等，补上入口去重的缺口

去重只能证明「这个键还没处理过」，不能证明「这个事件来自服务商」。公开的 Webhook URL 可以被任何人 POST，伪造请求也可能顺利通过去重。

作者要求先验证签名，再记录和处理事件：保留原始请求体（raw body），按服务商规则校验 HMAC，并采用常量时间比较。JSON 解析后再序列化，得到的字节可能已经变化，不能拿来替代原始请求体。

验签失败时，作者的做法是丢弃、记录日志，仍然返回 200，避免继续重投。这是作者的处理策略，不能直接当成所有 Webhook 的通用响应规范。

另一个缺口发生在入口之后：事件已经落库，worker 完成部分操作，却在标记完成前崩溃，恢复任务便可能再次执行。去重表被重置后，旧事件重放也会遇到类似问题。

因此，下游还要有自己的幂等保障：

• 写记录时按自然键 upsert，避免每次执行都新增。
• 创建业务对象前，判断该事件是否已有对应记录。
• 发送消息时使用确定性的 message id，让第二次发送可以被识别。

最后一项有前提：接收系统必须支持相应的识别或去重机制。仅仅生成一个固定 ID，并不会自动阻止重复发送。

入口去重减少重复执行，下游幂等负责让重复执行不再重复产生结果。

我的判断

作者把问题定位在「交付语义」上，这一点很准确。至少一次投递允许副本出现，接收方需要承受它。原文所说的 exactly-once，也应理解为接收系统最终呈现一次业务效果，不能理解为网络请求或工作流只执行一次。

相比给每个节点加一条查询判断，数据库唯一约束更适合处理并发；相比在入口等待所有业务结束，先持久化再异步执行，也更容易控制响应时间。

但文章仍是一份经验清单。作者称这些修复来自自己销售和维护的真实模板，并经过测试，却没有展示重复率、响应耗时或故障恢复的对照数据。第二阶段的任务领取、失败重试和完成状态如何管理，也没有交代清楚。

对于验签失败仍返回 200，我会更保留。它可能压住重投，也可能让合法服务商认为事件已成功交付，使密钥配置错误长期被隐藏。响应码应遵循具体服务商协议，验签失败本身则需要可追踪。

正常重复投递只记日志、不逐条告警，是合理的降噪做法；它也不等于重复数量异常增长时无需排查。

能拿来做什么

• 检查现有 n8n Webhook：如果入口还在等待 LLM、邮件和多系统写入完成，就先拆出事件持久化与后续处理两个阶段，并明确记录失败时的处理方式。
• 给每类事件写清去重键及其语义，再用数据库唯一约束执行原子插入，避免用 n8n execution id、到达时间或随机 ID 代替业务身份。
• 接入 Node Webhook 或调整 n8n 请求处理时，先确认验签需要的原始字节在哪里获取，再安排 JSON 解析；不要因为验签不通过就跳过验证。
• 用同一事件连续发送和并发发送，随后模拟处理中断再恢复，检查记录、邮件等副作用是否重复。验证对象应当是业务结果，而不只是执行页面是否显示成功。