我很好奇如何處理應用程序使用來自Google Pub / Sub的消息的升級/重新啟動情況。例如，我對開發一個Golang應用程序特別感興趣，該應用程序部署在運行多個 pod 的 Kubernetes 中，并使用來自 Google Pub/Sub 的消息。我關心的是，如何確保在升級 Pod 時不會遺漏任何消息（或處理兩次）。我知道應用程序會從訂閱中讀取消息，然后必須確認它已收到它。我覺得在確認消息和 Pod 關閉以進行升級之間可能存在爭用條件？我知道使用Dataflow作業可以執行類似操作，因為您可以停止流式處理作業并發出信號以清空消息。我假設必須有某種方式可以優雅地處理這個問題，或者這真的是數據流更適合的情況嗎？
1 回答
繁華開滿天機
TA貢獻1816條經驗 獲得超4個贊
Kubernetes 使用 SIGTERM，等待 30 秒，然后是 SIGKILL。這會在完全終止應用程序之前為應用程序提供適當的時間，如果 30 秒的默認值不夠，則可以使用該字段進行調整（鏈接 1）。terminationGracePeriodSeconds: 60
然后，您需要在 Golang 中添加邏輯以接收 SIGTERM 信號（鏈接 2）。
最后，假設你的隊列在這里是兔子（但其他隊列將具有類似的功能），在收到SIGTERM時，你可以將邏輯寫入A）停止接收新消息，然后B）（這是可選的，你可以讓他們完成）返回一個NACK和重新排隊信號，用于Pod當前已確認但未完成的所有消息， 將消息放回原處（鏈接 3 和 4）。
如果您可以避免實現 NACK/Requeue，只需通過關閉隊列偵聽器并完成當前保留消息的其余部分來處理 SIGTERM（并說 30 或 60 秒就足夠了），那就簡單多了，建議這樣做。
** 編輯 **
對于谷歌云發布/訂閱，您還可以發送Nack。
https://pkg.go.dev/cloud.google.com/go/pubsub#Message
“Ack 表示成功處理消息。如果消息確認失敗，將重新傳遞消息。Nack 表示客戶端不會或無法處理消息。Nack 將導致消息被重新傳遞的速度比允許它過期時更快。
- 1 回答
- 0 關注
- 96 瀏覽
添加回答
舉報
0/150
提交
取消