【Kafka】Producer配置

名稱 描述 類型 默認值
bootstrap.servers kafka集群地址，ip+端口，以逗號隔開。不管這邊配置的是什么服務(wù)器，客戶端會使用所有的服務(wù)器。配置的列表只會影響初始發(fā)現(xiàn)所有主機。配置的格式應(yīng)該是:ip:port,ip:port，因為配置的內(nèi)容只是用于服務(wù)集群的初始發(fā)現(xiàn)（集群地址可能會變化），配置可以不包含所有的服務(wù)器（你可能需要配置多于一個，防止某個服務(wù)掛掉） list
key.serializer 實現(xiàn)Serializer接口的序列化類鍵 class
value.serializer 實現(xiàn)Serializer接口的序列化類值 class
acks 生產(chǎn)者認為一個請求完成，所需要kafka集群主服務(wù)的應(yīng)答次數(shù)。這個配置控制已發(fā)送消息的持久性。下面是這個配置可能的值。acks=0：如果設(shè)置為0，生產(chǎn)者不會等待kafka的響應(yīng)。消息會被立刻加到發(fā)送緩沖通道中，并且認為已經(jīng)發(fā)送成功。這種情況下，不能保證kafka接收到了這條消息，retries配置不會生效，每條消息的偏移量都是1；acks=1：這個配置意味著kafka會把這條消息寫到本地日志文件中，但是不會等待集群中其他機器的成功響應(yīng)。這種情況下，在寫入日志成功后，集群主機器掛掉，同時從機器還沒來得及寫的話，消息就會丟失掉。acks=all：這個配置意味著leader會等待所有的follower同步完成。這個確保消息不會丟失，除非kafka集群中所有機器掛掉。這是最強的可用性保證。 string 1
buffer.memory 生產(chǎn)者等待發(fā)送到kafka的消息隊列占用內(nèi)容的大小。如果消息發(fā)送的速度比傳輸給kafka快，生產(chǎn)者會在拋出異常后，阻塞max.block.ms的時間。這個配置應(yīng)該大體與生產(chǎn)者用到的內(nèi)存差不多，但不全是，因為生產(chǎn)者使用的內(nèi)存不全部用于消息隊列。還有些內(nèi)存會被用于壓縮和保持長連接。 long 33554432
compression.type 生產(chǎn)者的數(shù)據(jù)壓縮類型。默認是不壓縮（no compression）。有效的配置可以是none，gzip，snappy或lz4。壓縮是數(shù)據(jù)的批量壓縮，所以批量的效果也就是壓縮的比例（壓縮的比例越好，數(shù)據(jù)量越小）。 string none
retries 配置為大于0的值的話，客戶端會在消息發(fā)送失敗時重新發(fā)送。重試等同于在發(fā)送有異常時重新發(fā)送消息。如果不把max.in.flight.requests.per.connection設(shè)為1，重試可能會改變消息的順序。兩條消息同時發(fā)送到同一個分區(qū)，第一條失敗了，并在第二條發(fā)送成功后重新發(fā)送，那么第二條消息可能在第一條消息前到達。 int 0
ssl.key.password 存在文件中的私鑰密碼，對于生產(chǎn)者來說可選。 password null
ssl.keystore.location 存儲私鑰的文件地址，可以用于不同客戶端的認證。 string null
ssl.keystore.password 私鑰文件存儲密碼。只有當(dāng)ssl.keystore.location配置了，才有用。 password null
ssl.truststore.location 信任存儲文件路徑。 string null
ssl.truststore.password 信任存儲文件密碼 password null
batch.size 當(dāng)多條消息需要發(fā)送到同一個分區(qū)時，生產(chǎn)者會嘗試合并網(wǎng)絡(luò)請求。這會提高client和生產(chǎn)者的效率。如果消息體大于這個配置，生產(chǎn)者不會嘗試發(fā)送消息。發(fā)送給kafka的消息包含不同的批次，每批發(fā)送給一個分區(qū)。批次大小太小的話可能會降低吞吐量。如果設(shè)為0，會禁用批處理功能。如果批次設(shè)置很大，可能會有些浪費內(nèi)存，因為我們會預(yù)留這部分內(nèi)存用于額外的消息。 int 16384
client.id 發(fā)送請求給kafka時帶上的生產(chǎn)者標識。目的是為了在ip+端口之外，通過邏輯上的應(yīng)用名稱跟蹤請求，以便記錄在kafka日志中。 string ""
connections.max.idle.ms 在配置項的時間之后，關(guān)閉空閑的鏈接 long 540000
linger.ms 消息延遲發(fā)送的毫秒數(shù)，目的是為了等待多個消息，在同一批次發(fā)送，減少網(wǎng)絡(luò)請求。 long 0
max.block.ms 這個配置控制KafkaProducer.send()和KafkaProducer.partitionsFor()的阻塞時間，當(dāng)緩沖區(qū)空間不夠或者源數(shù)據(jù)丟失時阻塞 int 60000
max.request.size 生產(chǎn)者一次請求的最大字節(jié)數(shù)，這也是一次消息體的最大值。注意到kafka集群有自己的消息限制，可能與這個值不一樣。這個配置限制的是生產(chǎn)者一次發(fā)送消息的大小，為的是避免發(fā)送大的數(shù)據(jù)量。 int 1048576
partitioner.class 實現(xiàn)Partitioner接口的分區(qū)類 class class org.apache.kafka.clients.producer.internals.DefaultPartitioner
receive.buffer.bytes socket接收緩存空間的大小，讀數(shù)據(jù)時用 int 32768
request.timeout.ms 生產(chǎn)者發(fā)送消息后等待響應(yīng)的最大時間，如果在配置時間內(nèi)沒有得到響應(yīng)，生產(chǎn)者會重試。 int 30000
timeout.ms kafka集群的leader等待follower響應(yīng)的超時時間。 int 30000
最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

推薦閱讀更多精彩內(nèi)容