Uber 如何防范重试风暴

简介 从历史上看，重试风暴会影响业务运营和品牌信任。虽然重试配置调整和重试预算在服务级别提供了有意义的缓解措施，但它们是手动配置的，并且缺乏对深度依赖链和扇出模式引起的跨服务放大的可见性。因此，很难保护基础设施免受堆栈深处单个服务中断引发的多米诺骨牌效应的影响。一个关键原因是现在的重试行为不具有上下文感知能力。虽然我们可以控制重试发生的次数，但我们无法精确控制重试发生的时间。这源于可靠区分服务生成的错误和仅通过服务传播的错误的挑战。因此，重试是统一应用的，而不是有条件的。此方法适用于瞬时或低率故障。然而，在中度或重度降解过程中，它会适得其反。对已经陷入困境的服务进行积极的重试会增加负载，加速失败，并放大上游依赖项的重试流量。局部中断可能会迅速升级为整个堆栈范围的事件，最终降低最终用户体验，或者在最坏的情况下，完全破坏最终用户体验。有人可能会争辩说，来自下游服务的错误代码可以被翻译到上游以提供重试的上下文。虽然从理论上讲是可行的，但由于大量的扇入和扇出、不断变化的呼叫流以及频繁的自适应更改的需要，这种方法在 Uber 无法扩展。因此，我们在共享基础设施中开发了上下文感知机制，以更有效地处理错误。这篇博客解释了这一机制。背景 考虑如图 1 所示的简单调用链，其中到达节点 A 的请求总数为 。由此推论，所有节点 B、C、D、E、F 和 G 在稳定状态下（当没有节点出错时）服务请求。图 1：具有 1:1 扇出的调用链，其中节点对于任何传入请求仅调用其下游一次。如果服务 D 开始出错，并且每个服务都配置为重试一次（常规尝试 1 次，如果下游失败则再尝试一次），让我们看看每个节点所服务的请求总数。图 2：服务出错的调用链。节点 A B C D E F G 深度 0 1 2 3 4 5 6 服务请求 2 × 4 × 8 × 8 × 8 × 8 × 假设每跳的重试次数 R 相同，这可以简化为一个简单的公式。 ɗ 表示调用链中节点的深度，如果节点创建或通过错误，则节点所服务的请求数量： Rɗ × ş 重试预算 我们可以通过引入重试预算来优化这一点。让我们假设 B 代表的每一跳的重试预算相同。新公式变为： (1+B)ɗ × ş 现在，让我们尝试查看重试预算为 10% 时所服务的请求数： Node A B C D E F G Depth 0 1 2 3 4 5 6 已服务的请求 ş 1.1 × ş 1.21 × ş 1.33 × ş 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33 × 1.33在从节点 C 到节点 D 的边缘（错误发生处）之间重试。节点 A B C D E F G 深度 0 1 2 3 4 5 6 服务请求数 1.1 × 1.1 × 1.1 × 1.1 × 在这里，我们将从 D 到叶节点 G 的所有节点所服务的请求总数限制为仅超过基线的 10%，同时允许在最多 10% 的错误下至少重试一次当他们第一次返回时。但是节点 C 所看到的节点 D 的可用性又如何呢？让我们针对各种可用性场景运行一些数字，并尝试在重试后计算可用性。基本可用性 % 基本错误率 % 重试后预算错误率 % 重试后可用性 % 99.9 0.1 10% 0.0001 99.9999 99 1 10% 0.01 99.99 95 5 10% 0.25 99.75 90 10 10% 1 99 80 20 10% 12 88 70 30 10% 23 77 如上表所示，当被叫方节点的可用性下降高达 10% 时，即使单次重试也有助于使调用方节点感知的可用性高达 99%。除此之外，感知的可用性显着下降，因为由于重试预算的存在，大量请求从未重试。此计算假设来自被调用方的错误是独立的，并且重试将导致恢复。然而，在许多现实场景中，例如服务过载、数据库主机故障、数据库过载或分片问题，即使重试，重试的概率仍然很高。这与重试被调用者总是增加调用者感知的可用性的想法相矛盾。也正是这种直觉构成了错误所有权的基础。在服务错误率较高期间，错误