REDIS 遺失/復原只在 n8n 內部發生

問題
,
1

嗨各位，我在 K8s 中運行 n8n
並在日誌中看到這個

2026-08-11T12:50:34.114Z | warn  | Lost Redis connection. Trying to reconnect in 1s... (0s/60s) {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

2026-08-11T12:50:35.157Z | info  | Recovered Redis connection {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

2026-08-11T12:54:39.507Z | warn  | Lost Redis connection. Trying to reconnect in 1s... (0s/60s) {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

2026-08-11T12:54:41.116Z | warn  | Lost Redis connection. Trying to reconnect in 1s... (0s/60s) {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

2026-08-11T12:54:42.144Z | info  | Recovered Redis connection {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

2026-08-11T12:54:54.513Z | warn  | Lost Redis connection. Trying to reconnect in 1s... (0s/60s) {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

2026-08-11T12:54:55.536Z | info  | Recovered Redis connection {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

2026-08-11T12:54:59.355Z | warn  | Lost Redis connection. Trying to reconnect in 1s... (0s/60s) {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

2026-08-11T12:55:00.381Z | info  | Recovered Redis connection {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

2026-08-11T12:55:36.502Z | warn  | Lost Redis connection. Trying to reconnect in 1s... (0s/60s) {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

2026-08-11T12:55:37.525Z | info  | Recovered Redis connection {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

2026-08-11T12:59:41.469Z | warn  | Lost Redis connection. Trying to reconnect in 1s... (0s/60s) {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

2026-08-11T12:59:43.077Z | warn  | Lost Redis connection. Trying to reconnect in 1s... (0s/60s) {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

2026-08-11T12:59:44.103Z | info  | Recovered Redis connection {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

2026-08-11T12:59:56.775Z | warn  | Lost Redis connection. Trying to reconnect in 1s... (0s/60s) {"scopes":["redis","scaling"],"file":"redis-client.service.js"}

我從我的電腦和 redis-cli pod 中進行了測試

root@redis-test:/data# while true; do redis-cli -h ``XYZ-9605.l.aivencloud.com`` -p 21274 -a ZYX --no-auth-warning ping; sleep 2; done
PONG
PONG
PONG
PONG
PONG
PONG
PONG
PONG
PONG
PONG
PONG
PONG
PONG

它運作良好
只有從 n8n pod 它才會出現失去連接/恢復連接的情況

可以解決嗎？
有什麼建議嗎？

2

嘿 @Antonio1，在你等待回應的時候，這些東西可能會有幫助：

建議資源

自動匹配你的問題。

文檔：

論壇：

@JavierOrjNeq、@tridi、@rodolfo.saldanha - 你們之前幫助過類似的問題，能看一下嗎？

由 n8n 社區機器人自動建議。這是試點 - 請在此分享反饋。

3

嘿 @Antonio1

你的 PING 迴圈正是為什麼它在 n8n 外看起來很健康。它每 2 秒發送一個命令，所以連線永遠不會閒置。n8n 的佇列連線不同，BullMQ 持有阻塞和 pub/sub socket，它們經常會閒置數分鐘。

Aiven 預設將 redis_timeout（較新的服務上為 valkey_timeout）設定為 300 秒，並在該標記處關閉任何閒置連線。你的時間戳記與此相符，掉線聚集在 12:50、12:55 和 13:00 左右。

在 Aiven 控制台中修正此問題，進入「Service settings」>「Advanced configuration」，將 redis_timeout 設定為 0，或從 CLI 執行：

avn service update --project -c redis_timeout=0

兩點提醒。如果 Aiven 在你的方案上拒絕 0，只需將其設定為遠高於你最長的閒置間隔。你仍然會看到大約每 12 小時重新連線一次，Aiven 在該時刻強制關閉 SSL 連線，這是無法設定的。

值得修正，儘管它會自動恢復，但工作中途的掉線可能會失去 BullMQ 鎖，導致執行停滯。

4

嘿 @Antonio1

Aiven（以及大多數託管 Redis 服務）要求所有連線都使用 TLS/SSL。你的 redis-cli 測試命令沒有包含 --tls 旗標。如果該命令在沒有 --tls 的情況下可以運行，這可能是由於你的本地配置，但如果沒有明確啟用 TLS，n8n 的內部客戶端幾乎肯定會失敗或表現不穩定。

解決方案： 確保在你的 n8n Kubernetes 部署中設定了以下環境變數：

QUEUE_BULL_REDIS_TLS=true

如果 Aiven 需要特定的 CA 憑證（通常都需要），你可能還需要確保 n8n 容器信任 Aiven CA 或提供該憑證。

像 Aiven 這樣的託管提供商通常有激進的「閒置連線逾時」。如果 n8n 在短時間內沒有主動向 Redis 傳送命令，Aiven 防火牆/負載平衡器會悄悄斷開連線。你執行的 redis-cli 測試之所以成功，是因為你使用了帶有 2 秒睡眠的 while true 迴圈，這通過不斷傳送 ping 命令來保持連線「活躍」。

解決方案： 雖然 n8n 不會直接通過環境變數暴露每個 ioredis 選項，但你應該嘗試增加逾時閾值以使客戶端更具彈性：

QUEUE_BULL_REDIS_TIMEOUT_THRESHOLD=30000  # 增加到 30 秒

要完全排除 TLS 問題，請從你的 redis-test Pod 再次執行測試，但明確包含 TLS 旗標：

while true; do 
  redis-cli --tls -h XYZ-9605.l.aivencloud.com -p 21274 -a ZYX --no-auth-warning ping
  sleep 2
done
  • 如果此命令失敗或掛起： 那麼你的網路/Pod 肯定需要啟用 TLS 才能與 Aiven 通訊。
  • 如果此命令完美運行： 那麼問題特別是 n8n/Bull 客戶端如何處理連線生命週期（可能需要 QUEUE_BULL_REDIS_TLS=true 變數相匹配）。

這些有幫助嗎？

5

謝謝
沒有注意到
會試試看
祝你有美好的一天

6

謝謝
你的資訊已過時
現在他們支援不使用 TLS 的方式

7

奇怪，我的印象不是這樣

8

對 QUEUE_BULL_REDIS_TIMEOUT_THRESHOLD 的小更正，那個在這裡不會有幫助。它控制的是 n8n 在 Redis 消失後重試多久才會放棄，但不會阻止伺服器關閉閒置的通訊端。你的日誌已經顯示 (0s/60s)，所以你使用的是 60 秒閾值，是建議值的兩倍，但斷線仍然發生。

關閉是伺服器端的問題，所以必須在 Aiven 服務上修復，而不是在 n8n 環境變數上修復。

9

在我設定 valkey_timeout 900 之後
Lost/Recovered 出現的頻率降低了
非常感謝你!!!
:grinning_face:

10

image
image464×270 12.8 KB

11

感謝您讓我們了解這一點，我們已建立 CAT-4042 作為內部開發工單來進行調查。