重試次數

Kafka 用戶端提供重新連接邏輯，但您必須明確地為生產者啟用重新連接。 如需詳細資訊，請參閱 retries 屬性。 連線會在 60 秒內重新進行。

重複項

啟用重試可能導致重複的訊息。 視連線遺失的時間而定，生產者可能無法判斷伺服器是否成功處理訊息，因此在重新連接時必須傳送訊息。 設計應用程式以預期訊息重複。

如果不能容忍重複，您可以使用 idempotent producer 功能 (來自 Kafka 1.1 )，以防止重試期間出現重複。 如需詳細資訊，請參閱 enable.idempotence 屬性。

標準計劃的具體指南

有關吞吐量指導資訊，請參閱 限制和配額 - 標準。

企業計劃的具體指南

如需傳輸量指引資訊，請參閱限制和配額 - 企業。

度量

檢測應用程式以瞭解它們的執行狀況。 例如，傳送及接收的訊息數目、訊息大小，以及回覆碼。 瞭解應用程式的用量有助於您適當地配置其資源，例如主題上的訊息保留時間。

飽和度

接近可以產生至叢集裡的資料流量限制時，生產者會開始節流控制、延遲會增加，且最後會發生像是逾時錯誤之類的錯誤。 視配置而定，訊息一致性及延續性也可能受到影響。 如需相關資訊，請參閱訊息的一致性及延續性。

生產者 acks 模式

雖然所有訊息都會被複製，但應用程式可以使用生產者的 acks mode 屬性來控制它們所產生的訊息傳輸到服務的穩健程度。 這個內容提供速度與訊息遺失風險之間的選擇。 使用 Kafka 3.0，預設用戶端設定為 acks=all (在此版本之前為 acks=1)。 acks=all 設定表示生產者只要在它所連接的分配管理系統及叢集中至少有一個其他分配管理系統確認收到訊息，即會傳回成功。 使用 acks=all 的優點是它提供最高層次的延續性，因此可防止訊息資料流失。

保持同步抄本

在 Event Streams 使用的配置中，Kafka 選擇一個分配管理系統作為每個分割區抄本的領導者，並選擇兩個其他分配管理系統作為追隨者。 來自用戶端的訊息資料會傳送至分割區的主導器，並抄寫至追蹤者。 如果追隨者與領導者保持一致，則會將他們視為「同步」抄本。 依定義，主導者一律視為處於同步狀態。

如果分割區的主導器變成無法使用 (可能是因為將維護套用至分配管理系統)，Kafka 會自動選取另一個同步抄本之一，以成為新的主導器。 此處理程序快速進行，並由 Kafka 用戶端自動處理。

不乾淨的領導人選舉

Event Streams 會停用不乾淨的領導者選舉。 此設定無法變更。

術語 不乾淨的主導者選擇 說明 Kafka 在分割區的所有同步抄本都變成無法使用的情況下如何回應。 啟用不乾淨的主導器選取時，不論 Kafka 是否同步，都會讓第一個抄本變成可用於分割區的主導器，以進行回復。 如果挑選為主導器的抄本尚未抄寫前一個主導器的所有訊息資料，這可能會導致訊息資料遺失。 當停用不乾淨的主導器選取 (如 Event Streams的情況) 時，Kafka 會等待同步抄本變成可用，並選擇它作為分割區的新主導器。 這可避免在啟用不乾淨的領導者選舉時可能發生的訊息資料流失。 取捨是回復可能需要更長時間，因為 Kafka 可能必須等待特定分配管理系統回到線上，然後分割區才可供用戶端產生及使用訊息資料。