Kafka producer config
（Kafka 0.10.1 Documentation）
1. 基本配置
發(fā)送設(shè)置
參數(shù)
說明
buffer.memory（32MB）
生產(chǎn)者用該內(nèi)存塊緩存app要發(fā)送給kafka的記錄（即消息），注意該內(nèi)存并非生產(chǎn)者使用的所有內(nèi)存。如果app發(fā)給客戶端庫的消息速率大于客戶端庫發(fā)給broker的速率，該內(nèi)存buffer會填滿，此處的行為，庫會阻塞max.block.ms（1min），1min后，報異常。
batch.size（16KB）
客戶端庫 會把去往同一分區(qū)去的記錄打成一批，注意一批是針對同一分區(qū)的吆。Size太小效率不高，當(dāng)為0時，即禁用批的功能，另外，size太大就也不好，因停留的延遲是一定的（linger.ms），在此延遲內(nèi)多半都達(dá)不到這個size，對應(yīng)固定的buffer[size]，是浪費(fèi)的。
linger.ms（0）
在生產(chǎn)者重負(fù)載情況下，app到客戶端庫的消息速率大于客戶端庫到服務(wù)器的速率，生產(chǎn)者會使用批傳輸消息，甚至在生產(chǎn)者一般負(fù)載情況下，客戶端庫也想降低發(fā)送請求的次數(shù)，這個設(shè)置為此目的，當(dāng)客戶端庫收到app的一條記錄時候，并不立即發(fā)送出去，而是要等這個時間，以允許有更多的記錄打成批送出去，類似nagle，這個時間就給了把多久的記錄打成一批的上限。當(dāng)然如果在等的過程中，滿足了一批，就會立即送出去，不管該時間設(shè)置，然而如果一直不到一批（batchsize，如果負(fù)載很輕）就在該時間超時后送出，哪怕一個小批。
max.request.size（1MB）
生產(chǎn)者發(fā)送一次數(shù)據(jù)的最大大小（即一個kafka 格式的request，一個kafka protocol unit，在進(jìn)入OS內(nèi)核之前，一旦進(jìn)入內(nèi)核就是流了，因此服務(wù)器收到后，需要根據(jù)kafka自己的協(xié)議進(jìn)行解析），一個request可以包括多個批，1個批可以包括多個記錄（消息），因此本設(shè)置也暗指生產(chǎn)者所認(rèn)為的一個記錄的最大大小， 另外，服務(wù)器也有自己允許的一個記錄的最大大小，該大小可以不同于此 max request size。 因為一個批有自己的最大大小（bashsize），因此本設(shè)置其實也是上限了在一次發(fā)送中批的數(shù)量。
max.in.flight.requests.per.connection（5）
每個連接上，允許多少在飛行中的request數(shù)，即發(fā)送了多少次，這些次至今未被確認(rèn)，至今沒有結(jié)果，這些次的數(shù)據(jù)可能在生產(chǎn)者的OS 內(nèi)核中、可能在線上、可能在服務(wù)器的內(nèi)核中、可能在kafka server app中但尚未被處理完，相當(dāng)于 tcp sliding window中可以發(fā)送的數(shù)據(jù)大小。一旦超過這個發(fā)送次數(shù)，生產(chǎn)者的發(fā)送就被阻塞，為此阻塞多少時間沒有說明。需要注意的是：如果這個發(fā)送次數(shù)設(shè)為大于1，即可以有至少兩個發(fā)送在進(jìn)行中，如果兩次發(fā)送中都有一個批目標(biāo)是相同分區(qū)、第一次發(fā)送失敗、第二次發(fā)送成功，且開啟失敗重發(fā)的開關(guān)，這樣就會導(dǎo)致記錄的失序，在目標(biāo)分區(qū)上的記錄失序。
max.block.ms（1min）
如果內(nèi)存滿了（buffer memory 32M）或元數(shù)據(jù)不可用（比如：leader不可用），KafkaProducer.send()或KafkaProducer.partitionsFor()就會被阻塞，阻塞的時間就是 max block ms。
等待確認(rèn)配置
配置
說明
acks（1）
假定一個數(shù)據(jù)在集群存3份，分布在一個主片（即主分區(qū)）、兩個從片（副本分區(qū)）上，主片存在于一個節(jié)點（簡稱點）上，兩個從片可以分布在兩個點上或一個點上。生產(chǎn)者發(fā)一個數(shù)據(jù)到某個主分所在的點上，該點處理完后，如果直接返回生產(chǎn)者，ack為1，如果兩個從點，都返給主點，然后，主點返給生產(chǎn)者則ack為-1，ack為0即不要求服務(wù)端返回。
timeout.ms（30s）
為了1.1acks，主節(jié)點最長等待N個從節(jié)點的時間，如果acks=0、1，不用考慮該設(shè)置（此情況下，與從節(jié)點無關(guān)），其他需要考慮最長等待從節(jié)點多久為了來自從節(jié)點的確認(rèn)，在此前從節(jié)點從主節(jié)點主動pull了數(shù)據(jù)（為了數(shù)據(jù)同步），從要對數(shù)據(jù)進(jìn)行處理，處理到合適的地方，給主發(fā)確認(rèn)。如果超時后，主仍未收到正確的確認(rèn)數(shù)目，就給生產(chǎn)者返回錯誤。注意，此項僅為服務(wù)端使用。
request.timeout.ms（30s）
生產(chǎn)者等待響應(yīng)的超時，在未超時時，如果沒收到響應(yīng)，生產(chǎn)者會重發(fā)該發(fā)送，如果重發(fā)次數(shù)用完了，則發(fā)送最終宣告失敗。重發(fā)有關(guān)的：重發(fā)次數(shù)（retries），重發(fā)間隔（retry.backoff.ms：100ms）。
內(nèi)核緩沖配置
配置
說明
send.buffer.bytes（128KB）
該socket內(nèi)核SO_SNDBUF的大小。
receive.buffer.bytes（32KB）
該socket內(nèi)核 SO_RCVBUF的大小。
集群元數(shù)據(jù)設(shè)置
配置
說明
metadata.fetch.timeout.ms（1min）
生產(chǎn)者第一次發(fā)送數(shù)據(jù)時，要取回該topic所有分區(qū)位于哪些節(jié)點上的元數(shù)據(jù)，需要最多多長時間達(dá)成這個動作，就是本項的目的，超時后，拋異常給生產(chǎn)者。
metadata.max.age.ms（5min）
生產(chǎn)者多久需要刷一次元數(shù)據(jù)，定時刷，第一次的獲取通過 metadata fetch timeout流程。
連接設(shè)置
配置
說明
connections.max.idle.ms（9min）
生產(chǎn)者在最后一次發(fā)流量之后 多久關(guān)閉該連接。
reconnect.backoff.ms（50ms）
生產(chǎn)者重連間隔，如果上次連接失敗。
重發(fā)請求設(shè)置
配置
說明
retry.backoff.ms（100ms）
生產(chǎn)者重發(fā)間隔，如果上次發(fā)送失敗。
retries（0）
生產(chǎn)者發(fā)送失敗時，最多重發(fā)次數(shù)，它>1與 max in flight requests per connection>1 配合時，可以導(dǎo)致 多次發(fā)送之間的失序， 對于 目標(biāo)是 同分區(qū)的情況會導(dǎo)致 記錄的的失序，當(dāng)然，如果是有相同記錄key的情況，會帶來問題。
壓縮設(shè)置
compression.type（none）
壓縮源有兩處可以設(shè)置：生產(chǎn)者、server，如果生產(chǎn)者開啟壓縮，你會注意到：變小了的生產(chǎn)者吐率和（或）更低的server壓縮率，當(dāng)收到壓縮消息時，0.10.0server不會再壓了，此舉比再壓相比會降低時延和提高吞吐率。然而，這會降低生產(chǎn)者的批大小（以前夠一批的，一他媽壓縮變半批了，又要馬上送走），因此，這會導(dǎo)致更差的吞吐率，不過這沒關(guān)系，可以調(diào)整linger（比如1ms）和batchsize，來提上去吞吐率。
此外，在生產(chǎn)者上壓縮消息所用的內(nèi)存buffer比在server上壓縮消息所用的內(nèi)存buffer小，因此，對于在logfile中壓縮比來說，其實在生產(chǎn)者壓縮不如在server上壓縮更好，在未來版本中 這個用于壓縮的 內(nèi)存的大小 變成配置項。
另外，端到端的批量壓縮概念，生產(chǎn)者壓縮，server存log的是壓縮之后東西，消費(fèi)者解壓縮，另外，最好讓kafka壓縮（不要使用跟kafka無關(guān)的壓縮，需要kafka感知壓縮才行，即可以生產(chǎn)者可以server），kafka可以批量壓縮，批的越好壓縮比越高，反之越差，切記。
加密設(shè)置
最后編輯于 ：2021.01.24 11:29:18
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
