资源 · 54
Webhook：处理重复、延迟和恢复
将收到的通知转换为唯一、可追溯的业务影响，以便在发生故障后恢复。
已更新 · 3 min
本指南有助于实现的目标
- 验证通知
- 将收据与处理分离
- 防止重复影响
- 恢复被阻塞的事件
快速检查
- 哪些字节已签名？
- 收据何时持久？
- 两个工作进程可以同时执行操作吗？
- 提供商是否保证顺序？
- 如何查找丢失的事件？
分步指南
- 1
读取提供商契约
记录类型、版本、账户上下文、签名、时间安排和重试规则。 Stripe 声明不保证交付顺序，并且可能会出现重复；不要对每个 API 应用 Stripe 特有的延迟。
交付物：带有日期的提供商契约。
- 2
在生效前进行验证
使用提供商要求的库和原始正文检查签名。 限制接受的大小和类型。 在授权环境中测试无效签名和意外的帐户上下文，且不记录密钥。
交付成果：无影响的拒绝。
- 3
确认前持久化
将持久化接收与缓慢处理区分开来。 如果队列无法接受事件，则不要将其报告为已保留。 成功表示已根据您的合约收到，但不一定表示业务操作已完成。
交付成果：已接收、正在处理、已完成和已阻塞状态。
- 4
强制幂等性
定义事件键和业务效果标识。 测试并发重复，而不仅仅是顺序交付。 在没有原子约束或锁定的情况下进行初步检查，可能会允许两个工作进程创建相同的效果。
交付成果：效果唯一性的证据。
- 5
处理延迟和混乱
不要假设旧的通知描述了当前状态。 在合约允许的情况下，查阅源并应用已验证的业务转换。 保留尚无法解释的事件。
交付物：转换和逆序测试。
- 6
协调和重放
准备一个包含所有者、原因、尝试次数和关闭信息的错误队列。 在重放期间保持重复保护。 定期比较提供程序和应用程序：成功恢复并不证明没有遗漏任何事件。
交付物：恢复程序和差异报告。
可重复使用的工作表
填写您已授权的观察结果。 这些字段是工作模板，而非观察结果。
| 字段 | 待记录信息 |
|---|---|
| 事件 | 提供商、帐户、标识符和版本 |
| 收据 | 已验证的签名和持久时间戳 |
| 影响 | 业务密钥、状态和唯一性证明 |
| 恢复 | 原因、尝试、所有者和关闭 |
虚构示例
示例情境
示例：两名工作人员在恢复过程中收到相同的确认通知。
决策及预期证据
通过独特的业务影响约束和事务状态，允许只履行一次交付，同时保持两次交付的可追溯性。
区分机制
| 机制 | 目的 | 验证或限制 |
|---|---|---|
| 签名 | 根据合同验证来源 | 不使效果唯一。 |
| 去重 | 识别重复通知 | 同时检查并发性和业务影响 |
| 协调 | 查找遗漏和差异 | 命名来源和周期 |
管理指标
| 指标 | 衡量内容 | 首要行动 |
|---|---|---|
| 队列年龄 | 未完成事件的延迟 | 检查最旧的事件 |
| 重复效果 | 错误重复的业务操作 | 纠正原子性 |
| 源/应用程序差距 | 缺失或不一致的状态 | 与闭合证据协调 |
常见错误
- 在签名体验证之前进行解析
- 在持久接收之前进行确认
- 假设按顺序交付
- 仅按顺序测试重复项
常见问题解答
HTTP 成功是否意味着处理完成？
这取决于合约。 对于异步处理，它应该意味着持久接收，而业务状态则单独跟踪。
是否可以假定只交付一次？
在实际合同下，针对重复交付和交付失败进行设计，并考虑其独特的影响和协调机制。
是否应该保留全部交付数据？
仅在必要时保留，并采用适当的访问权限和保留策略。 应尽可能减少追踪信息，以支持诊断和恢复，同时避免泄露机密信息。
官方参考文献
参考文献支持该方法。 请根据您的实际情况调整检查；它们并非认证。 原始参考文献标题和源文档可能使用其他语言。
参考资料查阅日期 .
