Worker: Redis reconnect storm — connections retry without jitter, ~4,800 log lines from a 15s outage

问题场景

在自托管 Docker Compose 部署中，当 Redis 容器因镜像升级被重建时，其 DNS 名称会短暂消失约 15 秒。在此期间，langfuse-worker 会瞬间产生大量完全相同的连接错误日志（约 4,800 行），单分钟日志量可达 2,430 行，甚至在 35 毫秒内出现 20 条错误。该问题源于多个 Redis 连接（每个 BullMQ 队列一个）在无抖动（jitter）的确定性指数退避策略下，同时失败并同步重试。

报错原文

Worker: Redis reconnect storm — connections retry without jitter, ~4,800 log lines from a 15s outage

Error: getaddrinfo ENOTFOUND langfuse-redis
<timestamp> error   Redis error getaddrinfo ENOTFOUND langfuse-redis

原因分析

核心原因在 redisQueueRetryOptions 中 retryStrategy 的确定性指数退避逻辑，完全缺少抖动（jitter）：

retryStrategy: (times) => Math.max(Math.min(Math.exp(times), 20000), 1000)

由于 WorkerManager.register() 为每个 BullMQ 队列创建独立的 ioredis 连接，这些连接会同时遇到 DNS 解析失败，并在完全相同的调度上重试——形成经典的惊群效应（thundering herd）。日志侧，第 5 次及之后的重试会无条件记录（每次重试都产生 warn 日志），且 reconnectOnError 回调在每个错误事件上也记录一次警告，导致每次失败产生两行重复日志。此外，当前环境变量中没有任何暴露重试/退避策略的配置项，该策略完全硬编码在源码中。

环境排查

• 确认 Langfuse 版本是否为 4.1.0（或检查是否有更新版本包含相关修复）。
• 检查 Redis 版本（Issue 中为 7.4.10），确认是否因容器重建导致 DNS 暂时不可解析。
• 检查部署方式：langfuse-worker 与 Redis 是否在同一 user-defined bridge 网络。
• 查看 langfuse-worker 的日志输出，确认是否出现大量 getaddrinfo ENOTFOUND 错误叠加。
• 确认 WorkerManager.register() 创建的队列数量（每个队列对应一条 Redis 连接），以估算同步重试的规模。

解决步骤

1. 确认问题场景：在 Redis 容器重建或网络短暂中断时，观察 langfuse-worker 是否出现大规模重复错误日志。
2. 检查源码 packages/shared/src/server/redis/redis.ts 中的 retryStrategy 是否仍为无抖动的确定性指数退避。
3. 可优先尝试（补丁方案）：为 retryStrategy 的返回值添加最高 50% 的抖动，将同步重试分散到随机时间点。由于该改动涉及源码修改，需要重新构建 worker 镜像或向官方提交补丁。
4. 若无法立即修改源码，则只能暂时通过日志收集端的限流/去重规则缓解日志量，但需注意这会同时限制对真实故障的可见性。
5. 持续关注官方仓库的相关 PR（如 #12086、#13950）及本 Issue 的更新，等待合并后的修复版本发布。

验证方法

模拟 Redis 容器重建（如执行 docker restart langfuse-redis），观察恢复期间 langfuse-worker 的日志量：正常情况下应显著减少错误数量且重试时间点呈分散分布，不再出现 35ms 内 20 条错误的密集爆发。

参考来源

langfuse/langfuse #15855