Kubernetes 上的 Kafka 流：重新部署后的長時間重新平衡

Question

問題

我們使用 StatefulSet 在 Kubernetes 上部署 Scala Kafka Streams 應用程序。 這些實例具有單獨的applicationId ，因此它們每個都復制完整的輸入主題以實現容錯。 它們本質上是只讀服務，僅讀取 state 主題並將其寫入 state 存儲區，從該存儲區通過 REST 處理客戶請求。 這意味着，在任何給定時間，消費者組始終只包含一個 Kafka Streams 實例。

我們現在的問題是，當觸發滾動重啟時，每個實例大約需要 5 分鍾才能啟動，其中大部分時間都花在了REBALANCING state 中等待。 我在這里讀到 Kafka Streams 不會發送LeaveGroup請求以便在容器重新啟動后快速返回，而無需重新平衡。 為什么這對我們不起作用？為什么重新平衡需要這么長時間，即使applicationId是相同的？ 理想情況下，為了最大限度地減少停機時間，應用程序應該立即從它重新啟動時離開的位置接管。

配置

以下是我們從默認值更改的一些配置：

properties.put(StreamsConfig.consumerPrefix(ConsumerConfig.MAX_POLL_RECORDS_CONFIG), "1000")
properties.put(StreamsConfig.consumerPrefix(ConsumerConfig.SESSION_TIMEOUT_MS_CONFIG), "300000")
properties.put(StreamsConfig.consumerPrefix(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG), "earliest")
// RocksDB config, see https://docs.confluent.io/current/streams/developer-guide/memory-mgmt.html
properties.put(StreamsConfig.ROCKSDB_CONFIG_SETTER_CLASS_CONFIG, classOf[BoundedMemoryRocksDBConfig])    

問題/相關配置

• 減少session.timeout.ms會有所幫助嗎？ 我們將其設置為相當大的值，因為 Kafka 代理位於不同的數據中心，並且網絡連接有時不是超級可靠。
• 這個答案建議減少max.poll.interval.ms ，因為它與重新平衡超時有關。 那是對的嗎？ 我猶豫要不要更改它，因為它可能會對我們應用程序的正常運行模式產生影響。
• 提到了一個配置group.initial.rebalance.delay.ms在部署期間延遲重新平衡 - 但這也會在從崩潰中恢復后導致延遲，不是嗎？
• 我還偶然發現了KIP-345 ，它旨在完全通過group.instance.id消除 static 會員資格的消費者再平衡，這非常適合我們的用戶案例，但它似乎還沒有在我們的經紀人上可用。

我對大量配置以及如何使用它們在更新后啟用快速恢復感到困惑。 誰能解釋一下他們是怎么一起玩的？

Answer 1

您引用的另一個問題並沒有說在重新啟動時避免重新平衡。 不發送LeaveGroupRequest只會在您停止應用程序時避免重新平衡。 因此，重新平衡的數量從兩個減少到一個。 當然，對於你有點不尋常的單實例部署，你在這里沒有任何收獲（事實上，它實際上可能會“傷害”你......）a

減少 session.timeout.ms 會有所幫助嗎？ 我們將其設置為相當大的值，因為 Kafka 代理位於不同的數據中心，並且網絡連接有時不是超級可靠。

可能是，取決於您重新啟動應用程序的速度。 （下面有更多詳細信息。）也許只是嘗試一下（即，將其設置為 3 分鍾以仍然具有較高的穩定性值，並看到重新平衡時間下降到 3 分鍾？

這個答案建議減少 max.poll.interval.ms，因為它與重新平衡超時有關。 那是對的嗎？ 我猶豫要不要更改它，因為它可能會對我們應用程序的正常運行模式產生影響。

max.poll.interval.ms也會影響重新平衡時間（下面有更多詳細信息）。 但是，默認值為 30 秒，因此不應導致 5 分鍾的重新平衡時間。

提到了一個配置 group.initial.rebalance.delay.ms 在部署期間延遲重新平衡 - 但這也會在從崩潰中恢復后導致延遲，不是嗎？

這僅適用於空消費者組，默認值僅為 3 秒。 所以它不應該影響你。

我還偶然發現了 KIP-345，它旨在完全通過 group.instance.id 消除 static 會員資格的消費者重新平衡，這非常適合我們的用戶案例，但它似乎還沒有在我們的經紀人上可用。

使用 static 組成員身份實際上可能是最好的選擇。 也許值得升級您的經紀人以獲得此功能。

順便說一句， session.timeout.ms和max.poll.interval.ms之間的區別在另一個問題中解釋： Difference between session.timeout.ms and max.poll.interval.ms for Kafka 0.10.0.0 and later versions

通常，代理端組協調器維護每個“組生成”所有成員的列表。 如果成員主動離開組（通過發送LeaveGroupRequest ）、超時（通過session.timeout.ms或max.poll.interval.ms ）或新成員加入組，則會觸發重新平衡。 如果發生重新平衡，每個成員都有機會重新加入該組以包含在下一代中。

對於您的情況，該組只有一名成員。 當您停止應用程序時，不會發送LeaveGroupRequest ，因此組協調器僅在session.timeout.ms過去后才會刪除此成員。

如果您重新啟動應用程序，它會作為“新”成員返回（從組協調員的角度來看）。 這將觸發重新平衡，使該組的所有成員都可以更改以重新加入該組。 對於您的情況，“舊”實例可能仍在組中，因此重新平衡只會在組協調器從組中刪除舊成員后繼續進行。 問題可能是，組協調員認為該組從一個成員擴展到兩個成員......（這就是我上面的意思：如果發送LeaveGroupRequest ，當您停止應用程序時，該組將變為空，並且在重新啟動時，只有新成員會在組中，並且重新平衡將立即進行。）

使用 static 組成員身份可以避免該問題，因為在重新啟動時，可以將實例重新識別為“舊”實例，並且組協調器不需要等待舊組成員過期。