代理程式離線和用戶端容錯移轉 - Amazon Managed Streaming for Apache Kafka

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

代理程式離線和用戶端容錯移轉

Kafka 允許離線代理程式；根據最佳實務，運作狀態良好且平衡的叢集中的單一離線代理程式不會看到影響或導致無法產生或消耗。這是因為另一個代理程式會接管分割區領導，而且 Kafka 用戶端 lib 會自動容錯移轉，並開始傳送請求給新的領導者代理程式。

用戶端伺服器合約

這會導致用戶端程式庫與伺服器端行為之間的共用合約；伺服器必須成功指派一或多個新領導者，而且用戶端必須變更代理程式，以及時將請求傳送給新領導者。

Kafka 使用例外狀況來控制此流程：

程序範例

  1. 代理程式 A 進入離線狀態。

  2. Kafka 用戶端會收到例外狀況 （通常是網路中斷連線或 not_leader_for_partition)。

  3. 這些例外狀況會觸發 Kafka 用戶端更新其中繼資料，使其了解最新的領導者。

  4. Kafka 用戶端會繼續將請求傳送至其他代理程式的新分割區領導者。

此程序通常需要不到 2 秒的時間，搭配 的 Java 用戶端和預設組態。用戶端錯誤是詳細且重複的，但不會引起疑慮，如「WARN」層級所示。

範例：例外狀況 1

10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Got error produce response with correlation id 864845 on topic-partition msk-test-topic-1-0, retrying (2147483646 attempts left). Error: NETWORK_EXCEPTION. Error Message: Disconnected from node 2

範例：例外狀況 2

10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Received invalid metadata error in produce request on partition msk-test-topic-1-41 due to org.apache.kafka.common.errors.NotLeaderOrFollowerException: For requests intended only for the leader, this error indicates that the broker is not the current leader. For requests intended for any replica, this error indicates that the broker is not a replica of the topic partition.. Going to request metadata update now"

Kafka 用戶端通常會在 1 秒內和最多 3 秒內自動解決這些錯誤。這在用戶端指標中顯示為 p99 的生產/使用延遲 （在 100 年代通常是高毫秒）。超過此長度通常表示用戶端組態或伺服器端控制器載入發生問題。請參閱疑難排解一節。

檢查其他代理程式上的 BytesInPerSec和 LeaderCount指標增加，證明流量和領導如預期般移動，即可驗證成功的容錯移轉。您也將觀察到UnderReplicatedPartitions指標增加，當複本與關機代理程式離線時，預期會增加。

故障診斷

上述流程可能會因為中斷用戶端伺服器合約而中斷。最常見的問題原因包括：

  • Kafka 用戶端 libs 的設定錯誤或不正確使用。

  • 使用第三方用戶端 libs 的非預期預設行為和錯誤。

  • 控制器過載導致分割區領導指派速度變慢。

  • 正在選擇新的控制器，導致分割區領導指派速度變慢。

為了確保正確的行為來處理領導容錯移轉，我們建議：

  • 必須遵循伺服器端最佳實務，以確保控制器代理程式適當擴展，以避免領導指派緩慢。

  • 用戶端程式庫必須啟用重試，以確保用戶端處理容錯移轉。

  • 用戶端程式庫必須設定 retry.backoff.ms （預設 100)，以避免連線/請求風暴。

  • 用戶端程式庫必須將 request.timeout.ms 和 delivery.timeout.ms 設定為與應用程式的 SLA 內嵌的值。較高的值會導致特定失敗類型的容錯移轉速度變慢。

  • 用戶端程式庫必須確保 bootstrap.servers 包含至少 3 個隨機代理程式，以避免對初始探索造成可用性影響。

  • 有些用戶端程式庫的層級低於其他程式庫，並希望應用程式開發人員自行實作重試邏輯和例外狀況處理。請參閱用戶端 lib 特定文件，了解使用範例，並確保遵循正確的重新連線/重試邏輯。

  • 我們建議監控生產的用戶端延遲、成功的請求計數，以及不可重試錯誤的錯誤計數。

  • 我們觀察到，較舊的第三方 golang 和 ruby 程式庫在整個代理程式離線期間仍保持詳細，儘管 會產生和取用不受影響的請求。我們建議您除了請求成功和錯誤的指標之外，一律監控您的業務層級指標，以判斷日誌中是否存在實際影響與雜訊。

  • 客戶不應對網路/not_leader 的暫時性例外狀況發出警示，因為它們是正常的、不影響的，且預期會作為 kafka 通訊協定的一部分。

  • 客戶不應在 UnderReplicatedPartitions 上發出警示，因為它們在單一離線代理程式期間是正常、無影響且預期的。