什么是 Webhook 重试策略？

Webhook重试策略是Webhook系统用于确定当Webhook发送不成功时是否重新发送的一套规则。此配置明确了系统重试的次数上限、每次尝试之间的暂停时间、失败的判定标准以及停止重试的条件。在大多数策略中，会采用指数退避来避免在短时间内进行多次尝试，而永久失败的事件则会被发送到死信队列。

重试策略是一个重要的考虑因素，鉴于网络和服务的可靠性可能存在差异。在交付过程中遇到网络或服务中断时，数据传输的最终完成取决于是否存在有效的重试策略。重试策略通过确保在接收端未返回2xx响应时进行重试，从而防止因交付失败导致的数据丢失。

当事件投递尝试遇到问题时，系统策略通常通过检查 HTTP 状态码来处理。之后，会根据重试计划引入一个暂停，然后重新尝试事件传输。这些是组成部分：

•       触发条件：触发重试的精确 HTTP 状态。
•       重试计划：尝试之间的时间间隔，通常是指数退避或从Retry-After标头中提取的值。
•       故障显现：它涉及能够识别问题但无需立即解决的函数，例如下一次重试时间的指示。
•       可观测性和幂等性：用于故障分析的日志、指标和重放工具，以及用于处理重复项的幂等处理。

大多数重试策略都会在每次尝试之间加入延迟。最常用的一种是指数退避；它会随着每次尝试而延长等待时间，这反过来又减轻了遇到某种问题的接收方的负担。

这意味着：

•       指数退避：是一种重试尝试之间间隔时间逐渐加长的技术。
•       添加抖动: 通过随机元素调整等待时间，以避免同时出现重试高峰。Twilio Event Streams 实现了抖动（jitter）的思想，以避免“惊群效应”。
•       分层重试: 立即、短期、长期和死信队列。

此队列用于处理那些已执行其配置的重试过程但仍未达到完成状态的事件。这些事件被保留在指定位置，以便检查其具体信息、观察其处理序列，或根据情况需要进行处理。

与其盲目复制激进的重试策略，不如采用良好的重试设计，考虑系统何时可能因过多重试而过载。这意味着要仔细斟酌重试限制和间隔时间。

•       优先采用指数退避加抖动。
•       建立明确的重试限制和停止标准。
•       制定明确的状态码规则，以确定哪些交付将重试，哪些不会。
•       幂等性键涉及重新处理的一致性管理。

监控实践旨在早期识别管道交付中的不一致。追踪指示问题的指标，然后通过警报自动通知，并将其与操作工具关联起来。

•       仪表盘：过去一段时间内交付健康状况的概述。
•       手动重放：一个选项，允许在根源解决后再次发送事件。
•       运行手册: 它们为待命工程师提供预定义的操作，旨在指导故障排除过程。

•       有条不紊地重试失败交付的过程旨在解决事件可能未被处理的情况。
•       这有助于减少短期中断和交付延迟期间事件数据丢失的可能性。
•       集成通常能够从短暂的中断中恢复，其相关问题往往是暂时性的，而非导致长时间的停机。
•       关键数据（例如订单和支付）的持续稳定交付，是影响集成信任度的一个因素。