下游服务抖动的 30 秒里,所有上游的重试逻辑同时开火:每次失败立即重发,下游恢复中的服务被 5 倍于正常量的请求反复锤击,越锤越起不来——重试本是容错手段,失控时却成了压垮恢复的致命一击。重试风暴治理三板斧:退避加抖动(每次重试间隔翻倍加随机偏移,打散重试流量)、重试上限(预算内最多 3 次)、熔断(单位时间失败超阈值后暂停重试一段时间,给下游喘息窗口)。F:\底层文件 的脚本执行模型提醒:同步重试的等待发生在主循环里,重试策略必须让出执行权。
带抖动退避与熔断的重试器:退避、上限、熔断三合一。示例代码如下:
local breaker = { fails = 0, openUntil = 0 }
local function retryWithBackoff(fn, maxRetry)
if os.time() < breaker.openUntil then
return false, "熔断中"
end
local delay = 200
for attempt = 1, maxRetry do
local ok = fn()
if ok then
breaker.fails = 0
return true
end
breaker.fails = breaker.fails + 1
if breaker.fails >= 10 then
breaker.openUntil = os.time() + 60
print("连续失败 10 次,熔断 60 秒")
return false, "熔断触发"
end
local jitter = math.random(0, delay // 2)
local until2 = os.clock() * 1000 + delay + jitter
while os.clock() * 1000 < until2 do
coroutine.yield()
end
delay = delay * 2
end
return false, "重试耗尽"
end
接入示例代码如下:
local ok = retryWithBackoff(function()
return pushCrossReport()
end, 3)
下游恢复期 30 秒的实测流量对比:立即重试策略下上游请求量放大到正常的 5.2 倍,下游二次崩溃;退避加抖动后放大倍数降到 1.4 倍,下游 12 秒恢复;熔断叠加后恢复期内上游干脆静默,恢复时间缩短到 8 秒。抖动的价值单独验证:同批上游不加密调时重试集中在同几个时间点(重试波峰),加 0 到 100 毫秒随机偏移后波峰被摊平成均匀分布。
三个不适用场景:一是幂等性不明的调用不能盲目重试——非幂等操作(扣款、发奖)重试一次就是双倍执行,先保证幂等再谈重试;二是实时性压倒一切的调用(战斗判定)等不起 200 毫秒的退避,失败就走失败分支;三是上游数量只有一两个的内部调用,不存在风暴的规模条件,简单重试即可,熔断是给大规模调用方准备的。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
一、一行代码拆解:local function roll() 里写 local cfg = {500, 200, 50} —…
一、隐蔽陷阱:国库金币累加到 2^53(约 9007199254740992)之后再加 1,数值纹丝不动——双精度浮点在该区…
一、线上事故:仓库存取逻辑散在 6 个脚本,各自写各自的 getsysvar 键名,某次改名漏改 2 处,300 件裁决之杖…
一、抛坑提问:500 件战备装备一次下发必卡,按每页 20 件切片,边界怎么算才不出空页和重页?起点 (page-1) 20…
一、抛坑提问:校验失败在工具函数里 error,日志却指向工具函数那一行,排查总要翻两层。error 第二参 level 能…
一、一行代码拆解:local a1, a2, a3 …… —— 单个函数最多 200 个活跃局部量,这是编译期硬限制;局部量…