Producer Configs 配置
| 屬性 | 描述 | 類型 | 默認值 |
|---|---|---|---|
| bootstrap.servers | 用於建立與kafka集羣的連接，這個list僅僅影響用於初始化的hosts，來發現全部的servers。 格式：host1:port1,host2:port2,…，數量儘量不止一個，以防其中一個down了 |
list | |
| acks | Server完成 producer request 前需要確認的數量。acks=0時，producer不會等待確認，直接添加到socket等待發送；acks=1時，等待leader寫到local log就行；acks=all或acks=-1時，等待isr中所有副本確認（注意：確認都是 broker 接收到消息放入內存就直接返回確認，不是需要等待數據寫入磁盤後才返回確認，這也是kafka快的原因） |
string | 1 |
| buffer.memory | Producer可以用來緩存數據的內存大小。該值實際爲RecordAccumulator類中的BufferPool，即Producer所管理的最大內存。 如果數據產生速度大於向broker發送的速度，producer會阻塞 max.block.ms，超時則拋出異常 |
long | 33554432 |
| compression.type | Producer用於壓縮數據的壓縮類型，取值：none, gzip, snappy, or lz4 |
string | none |
| batch.size | Producer可以將發往同一個Partition的數據做成一個Produce Request發送請求，即Batch批處理，以減少請求次數，該值即爲每次批處理的大小。 另外每個Request請求包含多個Batch，每個Batch對應一個Partition，且一個Request發送的目的Broker均爲這些partition的leader副本。 若將該值設爲0，則不會進行批處理 |
int | 16384 |
| linger.ms | Producer默認會把兩次發送時間間隔內收集到的所有Requests進行一次聚合然後再發送，以此提高吞吐量，而linger.ms則更進一步，這個參數爲每次發送增加一些delay，以此來聚合更多的Message。 官網解釋翻譯：producer會將request傳輸之間到達的所有records聚合到一個批請求。通常這個值發生在欠負載情況下，record到達速度快於發送。但是在某些場景下，client即使在正常負載下也期望減少請求數量。這個設置就是如此，通過人工添加少量時延，而不是立馬發送一個record，producer會等待所給的時延，以讓其他records發送出去，這樣就會被聚合在一起。這個類似於TCP的Nagle算法。該設置給了batch的時延上限：當我們獲得一個partition的 batch.size大小的records，就會立即發送出去，而不管該設置；但是如果對於這個partition沒有累積到足夠的record，會linger指定的時間等待更多的records出現。該設置的默認值爲0(無時延)。例如，設置linger.ms=5，會減少request發送的數量，但是在無負載下會增加5ms的發送時延。 |
long | 0 |
| max.request.size | 請求的最大字節數。這也是對最大消息大小的有效限制。注意：server具有自己對消息大小的限制，這些大小和這個設置不同。此項設置將會限制producer每次批量發送請求的數目，以防發出巨量的請求。 | int | 1048576 |
| receive.buffer.bytes | TCP的接收緩存 SO_RCVBUF 空間大小，用於讀取數據 | int | 32768 |
| request.timeout.ms | client等待請求響應的最大時間,如果在這個時間內沒有收到響應，客戶端將重發請求，超過重試次數發送失敗 | int | 30000 |
| send.buffer.bytes | TCP的發送緩存 SO_SNDBUF 空間大小，用於發送數據 | int | 131072 |
| timeout.ms | 指定server等待來自followers的確認的最大時間，根據acks的設置，超時則返回error |
int | 30000 |
| max.in.flight.requests.per.connection | 在block前一個connection上允許最大未確認的requests數量。 當設爲1時，即是消息保證有序模式，注意：這裏的消息保證有序是指對於單個Partition的消息有順序，因此若要保證全局消息有序，可以只使用一個Partition，當然也會降低性能 |
int | 5 |
| metadata.fetch.timeout.ms | 在第一次將數據發送到某topic時，需先fetch該topic的metadata，得知哪些服務器持有該topic的partition，該值爲最長獲取metadata時間 | long | 60000 |
| reconnect.backoff.ms | 連接失敗時，當我們重新連接時的等待時間 | long | 50 |
| retry.backoff.ms | 在重試發送失敗的request前的等待時間，防止若目的Broker完全掛掉的情況下Producer一直陷入死循環發送，折中的方法 | long | 100 |
其餘參數（注：以下均爲默認值）
生產者配置參數釋義
1.bootstrap.servers 指定Kafka集羣所需的broker地址清單，默認 ""
2.metadata.max.age.ms 強制刷新元數據時間，毫秒，默認300000，5分鐘
3.batch.size 指定ProducerBatch內存區域的大小，默認16kb
4.acks 指定分區中必須有多少個副本收到這條消息，纔算消息發送成功，默認值1，字符串類型
5.linger.ms 指定ProducerBatch在延遲多少毫秒後再發送，但如果在延遲的這段時間內batch的大小已經到了batch.size設置的大小，那麼消息會被立即發送，不會再等待，默認值0
6.client.id 用戶設定，用於跟蹤記錄消息，默認 ""
7.send.buffer.bytes Socket發送緩衝區大小，默認128kb,-1將使用操作系統的設置
8.receive.buffer.bytes Socket接收緩衝區大小，默認32kb,-1將使用操作系統的設置
9.max.request.size 限制生產者客戶端發送消息的最大值，默認1MB
10.reconnect.backoff.ms 連接失敗後，嘗試連接Kafka的時間間隔，默認50ms
11.reconnect.backoff.max.ms 嘗試連接到Kafka，生產者客戶端等待的最大時間，默認1000ms
12.max.block.ms 控制生產者客戶端send()方法和partitionsFor()方法的阻塞時間。當生產者的發送緩存區已滿，或者沒有可用元數據時，這些方法就會阻塞,默認60s
13.buffer.memory 生產者客戶端中用於緩存消息的緩存區大小，默認32MB
14.retry.backoff.ms 消息發送失敗重試時間間隔，默認100ms
15.compression.type 指定消息的壓縮方式，默認不壓縮
16.metrics.sample.window.ms 樣本計算時間窗口，默認30000ms
17.metrics.num.samples 用於維護metrics的樣本數量，默認2
18.metrics.log.level metrics日誌記錄級別，默認info
19.metric.reporters 類的列表，用於衡量指標，默認空list
20.max.in.flight.requests.per.connection 可以在一個connection中發送多個請求，叫作一個flight,這樣可以減少開銷，但是如果產生錯誤，可能會造成數據的發送順序改變,默認5
21.retries 消息發送失敗重試次數，默認0
22.key.serializer key的序列化方式
23.value.serializer value序列化類方式
24.connections.max.idle.ms 設置多久之後關閉空閒連接，默認540000ms
25.partitioner.class 分區類,實現Partitioner接口，可以自定義分區規則
26.request.timeout.ms 客戶端將等待請求的響應的最大時間,如果在這個時間內沒有收到響應，客戶端將重發請求，超過重試次數將拋異常，默認30000ms
27.interceptor.classes 攔截器類，實現ProducerInterceptor接口，自定義攔截器
28.enable.idempotence true爲開啓冪等性
29.transaction.timeout.ms 事務超時時間，默認60000ms
30.transactional.id 設置事務id，必須唯一
消費者配置參數釋義
1.group.id 消費者所屬消費組的唯一標識
2.max.poll.records 一次拉取請求的最大消息數，默認500條
3.max.poll.interval.ms 指定拉取消息線程最長空閒時間，默認300000ms
4.session.timeout.ms 檢測消費者是否失效的超時時間，默認10000ms
5.heartbeat.interval.ms 消費者心跳時間，默認3000ms
6.bootstrap.servers 連接集羣broker地址
7.enable.auto.commit 是否開啓自動提交消費位移的功能，默認true
8.auto.commit.interval.ms 自動提交消費位移的時間間隔，默認5000ms
9.partition.assignment.strategy 消費者的分區配置策略, 默認 RangeAssignor
10.auto.offset.reset 如果分區沒有初始偏移量，或者當前偏移量服務器上不存在時，將使用的偏移量設置，earliest從頭開始消費，latest從最近的開始消費，none拋出異常
11.fetch.min.bytes 消費者客戶端一次請求從Kafka拉取消息的最小數據量，如果Kafka返回的數據量小於該值，會一直等待，直到滿足這個配置大小，默認1b
12.fetch.max.bytes 消費者客戶端一次請求從Kafka拉取消息的最大數據量，默認50MB
13.fetch.max.wait.ms 從Kafka拉取消息時，在不滿足fetch.min.bytes條件時，等待的最大時間，默認500ms
14.metadata.max.age.ms 強制刷新元數據時間，毫秒，默認300000，5分鐘
15.max.partition.fetch.bytes 設置從每個分區裏返回給消費者的最大數據量，區別於fetch.max.bytes，默認1MB
16.send.buffer.bytes Socket發送緩衝區大小，默認128kb,-1將使用操作系統的設置
17.receive.buffer.bytes Socket發送緩衝區大小，默認64kb,-1將使用操作系統的設置
18.client.id 消費者客戶端的id
19.reconnect.backoff.ms 連接失敗後，嘗試連接Kafka的時間間隔，默認50ms
20.reconnect.backoff.max.ms 嘗試連接到Kafka，生產者客戶端等待的最大時間，默認1000ms
21.retry.backoff.ms 消息發送失敗重試時間間隔，默認100ms
22.metrics.sample.window.ms 樣本計算時間窗口，默認30000ms
23.metrics.num.samples 用於維護metrics的樣本數量，默認2
24.metrics.log.level metrics日誌記錄級別，默認info
25.metric.reporters 類的列表，用於衡量指標，默認空list
26.check.crcs 自動檢查CRC32記錄的消耗
27.key.deserializer key反序列化方式
28.value.deserializer value反序列化方式
29.connections.max.idle.ms 設置多久之後關閉空閒連接，默認540000ms
30.request.timeout.ms 客戶端將等待請求的響應的最大時間,如果在這個時間內沒有收到響應，客戶端將重發請求，超過重試次數將拋異常，默認30000ms
31.default.api.timeout.ms 設置消費者api超時時間，默認60000ms
32.interceptor.classes 自定義攔截器
33.exclude.internal.topics 內部的主題:一consumer_offsets 和一transaction_state。該參數用來指定 Kafka 中的內部主題是否可以向消費者公開，默認值爲 true。如果設置爲 true，那麼只能使用 subscribe(Collection)的方式而不能使用 subscribe(Pattern)的方式來訂閱內部主題，設置爲 false 則沒有這個限制。
34.isolation.level 用來配置消費者的事務隔離級別。如果設置爲“read committed”，那麼消費者就會忽略事務未提交的消息，即只能消 費到 LSO (LastStableOffset)的位置，默認情況下爲 “read_uncommitted”，即可以消 費到 HW (High Watermark)處的位置
