生產者參數優化 · Hadoop2.x

1. **`bootstrap.servers`** 無需添加所有的集群地址，Kafka 會根據提供的地址發現其他的地址，但盡量多提供幾個，以防提供的服務器關閉。 2. **`acks`** acks=0 如果設置為 0，那么生產者將不等待任何消息確認。消息將立刻添加到 socket 緩沖區并考慮發送。在這種情況下不能保障消息被服務器接收到。并且重試機制不會生效（因為客戶端不知道故障了沒有）。每個消息返回的 offset 始終設置為-1。 acks=1，這意味著 leader 寫入消息到本地日志就立即響應，而不等待所有follower 應答。在這種情況下，如果響應消息之后但 follower 還未復制之前 leader立即故障，那么消息將會丟失。 acks=all 這意味著 leader 將等待所有副本同步后應答消息。此配置保障消息不會丟失（只要至少有一個同步的副本）。這是最強壯的可用性保障。等價于acks=-1。 3. **`buffer.memory`** 生產者用來緩存等待發送到服務器的消息的內存總字節數。如果消息發送比可傳遞到服務器的快，生產者將阻塞 max.block.ms 之后，拋出異常。此設置應該大致對應生產者將要使用的總內存，但不是硬約束，因為生產者所使用的所有內存都用于緩沖。一些額外的內存將用于壓縮（如果啟動壓縮），以及用于保持發送中的請求。 首先要明確一點，那就是在內存緩沖里大量的消息會緩沖在里面，形成一個一個的 Batch，每個 Batch 里包含多條消息。然后 KafkaProducer 有一個 Sender線程會把多個 Batch 打包成一個 Request 發送到 Kafka 服務器上去。那么如果要是內存設置的太小，可能導致一個問題：消息快速的寫入內存緩沖里面，但是Sender 線程來不及把 Request 發送到 Kafka 服務器。這樣是不是會造成內存緩沖很快就被寫滿？一旦被寫滿，就會阻塞用戶線程，不讓繼續往 Kafka 寫消息了。 所以對于“buffer.memory”這個參數應該結合自己的實際情況來進行壓測，你需要測算一下在生產環境，你的用戶線程會以每秒多少消息的頻率來寫入內存緩沖。比如說每秒 300 條消息，那么你就需要壓測一下，假設內存緩沖就 32MB，每秒寫 300 條消息到內存緩沖，是否會經常把內存緩沖寫滿？經過這樣的壓測，你可以調試出來一個合理的內存大小。 4. **`batch.size`** 當多個消息要發送到相同分區的時，生產者嘗試將消息批量打包在一起，以減少請求交互。這樣有助于客戶端和服務端的性能提升。該配置的默認批次大小（以字節為單位）：16384，即 16KB。不會打包大于此配置大小的消息，發送到broker 的請求將包含多個批次，每個分區一個，用于發送數據。較小的批次大小有可能降低吞吐量（批次大小為 0 則完全禁用批處理）。一個非常大的批次大小可能更浪費內存，因為我們會預先分配這個資源。比如說發送消息的頻率就是每秒 300 條，那么如果 batch.size 調節到了 32KB，或者 64KB，也不會提升發送消息的整體吞吐量。 理論上來說，提升 batch 的大小，可以允許更多的數據緩沖在里面，那么一次 Request 發送出去的數據量就更多了，這樣吞吐量可能會有所提升。但是也不能無限的大，過于大了之后，要是數據老是緩沖在 Batch 里遲遲不發送出去，那么豈不是你發送消息的延遲就會很高。比如說，一條消息進入了 Batch，但是要等待 5 秒鐘 Batch 才湊滿了 64KB，才能發送出去。那這條消息的延遲就是 5 秒鐘。 所以需要在這里按照生產環境的發消息的速率，調節不同的 Batch 大小自己測試一下最終出去的吞吐量以及消息的延遲，設置一個最合理的參數。 5. **`compression.type`** 數據壓縮的類型。默認為空（就是不壓縮）。有效的值有 none，gzip，snappy, 或 lz4。壓縮全部的數據批，因此批的效果也將影響壓縮的比率（更多的批次意味著更好的壓縮）。 6. **`retries`** 設置一個比零大的值，客戶端如果發送失敗則會重新發送。注意，這個重試功能和客戶端在接到錯誤之后重新發送沒什么不同。如果max.in.flight.requests.per.connection 沒有設置為 1，有可能改變消息發送的順序，因為如果 2 個批次發送到一個分區中，并第一個失敗了并重試，但是第二個成功了，那么第二個批次將超過第一個。 `retries`和`retries.backoff.ms`決定了重試機制，也就是如果一個請求失敗了可以重試幾次，每次重試的間隔是多少毫秒。這個大家適當設置幾次重試的機會，給一定的重試間隔即可，比如給 100ms 的重試間隔。 7. **`linger.ms`** 指逗留時間，這個逗留指的是消息不立即發送，而是逗留這個時間后一塊發送。這個設置是比較有用的，有時候消息產生的要比能夠發送的要快，這個參數完美的實現了一個人工的延遲，使得大批量可以聚合到一個 Batch 里一塊發送，當 Batch 慢了的話，會忽略這個參數立即發送。默認值 : 0。 8. **`client.id`** 當發出請求時傳遞給服務器的 id 字符串。這樣做的目的是允許服務器請求記錄這個“邏輯應用名”，這樣能夠追蹤請求的源，而不僅僅只是 ip:port。