知识卡片
多层重试的指数放大效应
内容
每一层调用都独立设重试，看似各自合理，组合起来却是灾难：若JS层、前端、后端各发3次重试（每层 共4次尝试），一次用户操作最终可能对数据库产生 4×4×4=64 倍请求量——放大恰好发生在系统最脆弱、 最不需要额外负载的时刻。护栏：重试间隔用随机化指数退避、设重试次数上限、设全局重试预算（如 每分钟最多重试60次，超出直接判失败）。谁该重试见[[只在拒绝的那一层重试避免重试风暴]]。
参考来源
- 位置：《SRE：Google运维解密》第22章《处理连锁故障》"重试"一节（源文件：_epub-src/OEBPS/Text/0009_0013.xhtml）
- 结论依据：原文明确"如果服务器由于过载不能提供服务，后端、前端、JavaScript层各发送3次重试（总计4次请求），那么一个用户的动作可能会造成对数据库的64次请求（4³）"，并列出随机指数退避、重试次数限制、全局重试预算三项应对措施。
- 原始内容：从多个视角重新审视该服务，决定是否需要在某个级别上进行重试。这里尤其要避免同时在多个级别上重试导致的放大效应：高层的一个请求可能会造成各层重试次数的乘积数量的请求……那么一个用户的动作可能会造成对数据库的64次请求（4³）。