Kafka客戶端參數配置建議
更新時間 2025-06-06 17:00:11
最近更新時間: 2025-06-06 17:00:11
分享文章
本文主要 Kafka客戶端參數配置建議。
Kafka客戶端的配置參數很多，以下提供producer和consumer幾個常用參數配置。其他參數配置，請參考。
表 Producer參數
| 參數 | 默認值 | 推薦值 | 說明 |
|---|---|---|---|
| acks | 1 | 高可靠：all或者-1高吞吐：1 | 收到Server端確認信號個數，表示producer需要收到多少個這樣的確認信號，算消息發送成功。 acks參數代表了數據備份的可用性。常用選項：acks=0：表示producer不需要等待任何確認收到的信息，副本將立即加到socket buffer并認為已經發送。沒有任何保障可以保證此種情況下server已經成功接收數據，同時重試配置不會發生作用（因為客戶端不知道是否失敗）回饋的offset會總是設置為-1。 acks=1：這意味著至少要等待leader已經成功將數據寫入本地log，但是并沒有等待所有follower是否成功寫入。如果follower沒有成功備份數據，而此時leader又無法提供服務，則消息會丟失。 acks=all或者-1：這意味著leader需要等待ISR中所有備份都成功寫入日志。只要任何一個備份存活，數據都不會丟失。min.insync.replicas指定必須確認寫入才能被認為成功的副本的最小數量。 |
| retries | 0 | 結合實際業務調整 | 客戶端發送消息的重試次數。值大于0時，這些數據發送失敗后，客戶端會重新發送。 注意，這些重試與客戶端接收到發送錯誤時的重試沒有什么不同。允許重試將潛在的改變數據的順序，如果這兩個消息記錄都是發送到同一個partition，則第一個消息失敗第二個發送成功，則第二條消息會比第一條消息出現要早。針對網絡閃斷場景，生產者建議配置重試能力，推薦重試次數retries=3，重試間隔retry.backoff.ms=1000。 |
| request.timeout.ms | 30000 | 結合實際業務調整 | 設置一個請求最大等待時間，超過這個時間則會拋Timeout異常。超時時間如果設置大一些，如127000（127秒），高并發的場景中，能減少發送失敗的情況。 |
| block.on.buffer.full | TRUE | TRUE | TRUE表示當我們內存用盡時，停止接收新消息記錄或者拋出錯誤。默認情況下，這個設置為TRUE。 然而某些阻塞可能不值得期待，因此立即拋出錯誤更好。如果設置為false，則producer拋出一個異常錯誤：BufferExhaustedException |
| batch.size | 16384 | 262144 | 默認的批量處理消息字節數上限。producer將試圖批處理消息記錄，以減少請求次數。 這將改善client與server之間的性能。不會試圖處理大于這個字節數的消息字節數。 發送到brokers的請求將包含多個批量處理，其中會包含對每個partition的一個請求。較小的批量處理數值比較少用，并且可能降低吞吐量（0則會僅用批量處理）。 較大的批量處理數值將會浪費更多內存空間，這樣就需要分配特定批量處理數值的內存大小。 |
| buffer.memory | 33554432 | 67108864 | producer可以用來緩存數據的內存大小。如果數據產生速度大于向broker發送的速度，producer會阻塞或者拋出異常，以“block.on.buffer.full”來表明。 這項設置將和producer能夠使用的總內存相關，但并不是一個硬性的限制，因為不是producer使用的所有內存都是用于緩存。一些額外的內存會用于壓縮（如果引入壓縮機制），同樣還有一些用于維護請求。 |
表 Consumer參數
參數 默認值 推薦值 說明 auto.commit.enable TRUE FALSE 如果為真，consumer所fetch的消息的offset將會自動的同步到zookeeper。這項提交的offset將在進程無法提供服務時，由新的consumer使用。約束：設置為false后，需要先成功消費再提交，這樣可以避免消息丟失。 auto.offset.reset latest earliest 沒有初始化offset或者offset被刪除時，可以設置以下值：
earliest：自動復位offset為最早
latest：自動復位offset為最新
none：如果沒有發現offset則向消費者拋出異常
anything ? else：向消費者拋出異常。
說明如果將此配置設置為latest，新增分區時，生產者可能會在消費者重置初始偏移量之前開始向新增加的分區發送消息，從而導致部分消息丟失。connections.max.idle.ms 600000 30000 空連接的超時時間，設置為30000可以在網絡異常場景下減少請求卡頓的時間。
