java api kafka配置信息分析
producer 配置可選參數(shù)
acks
配置表示 producer 發(fā)送消息到 broker 上以后的確認值。有三個可選項
1. acks=0表示 producer 不需要等待 broker 的消息確認，發(fā)出消息那么就認為消息已成功寫入Kafka，時效率高，但同時風險最大，server 宕機時，數(shù)據(jù)將會丟失
2. acks=1 表示 producer 只需要獲得 kafka 集群中的 leader 節(jié)點確認即可，這個選擇時延較小同時確保了 leader 節(jié)點確認接收成功
3. acks=all leader 節(jié)點在返回確認或錯誤響應(yīng)之前，會等待所有同步副本都收到消息。如果和min.insync.replicas參數(shù)結(jié)合起來，就可以決定在返回確認前至少有多個副本能夠收到消息。比如min.insync.replicas=1就需要至少一個follwer確認收到消息。相對安全，但是效率較低。但是由于 ISR 可能會縮小到僅包含一個 Replica，所以設(shè)置參數(shù)為all并不能一定避免數(shù)據(jù)丟失
batch.size
生產(chǎn)者發(fā)送多個消息到 broker 上的同一個分區(qū)時，為了減少網(wǎng)絡(luò)請求帶來的 性能開銷，通過批量的方式來提交消息，可以通過這個參數(shù)來控制批量提交的 字節(jié)數(shù)大小，默認大小是 16384byte,也就是 16kb，意味著當一批消息大小達 到指定的 batch.size 的時候會統(tǒng)一發(fā)送
linger.ms
Producer 默認會把兩次發(fā)送時間間隔內(nèi)收集到的所有 Requests 進行一次聚合 然后再發(fā)送，以此提高吞吐量，而 linger.ms 就是為每次發(fā)送到 broker 的請求 增加一些 delay，以此來聚合更多的 Message 請求。 這個有點想 TCP 里面的 Nagle 算法，在 TCP 協(xié)議的傳輸中，為了減少大量小數(shù)據(jù)包的發(fā)送，采用了 Nagle 算法，也就是基于小包的等-停協(xié)議。
默認情況即使緩沖區(qū)有剩余的空間，也會立即發(fā)送請求，設(shè)置一段時間用來等待從而將緩沖區(qū)填的更多，單位為毫秒，producer發(fā)送數(shù)據(jù)會延遲1ms，可以減少發(fā)送到kafka服務(wù)器的請求數(shù)據(jù)
batch.size 和 linger.ms 這兩個參數(shù)是 kafka 性能優(yōu)化的關(guān)鍵參數(shù)當二者都配置的時候，只要滿足其中一個要 求，就會發(fā)送請求到 broker 上
max.request.size
設(shè)置請求的數(shù)據(jù)的最大字節(jié)數(shù)，為了防止發(fā)生較大的數(shù)據(jù)包影響到吞吐量，默認值為 1MB
consumer配置可選參數(shù)
group.id
當producer發(fā)送一條消息，相同group.id的多個consumer只有其中一個consumer能消費到
(比如 topic=hehe的主題發(fā)送了一條消息，group.id=666的組，有三個消費者監(jiān)聽了這個主題，但這條消息只會被其中一個consumer消費到)，group.id=999的一個consumer也能消費這條消息。
enable.auto.commit
消費者消費消息以后自動提交，只有當消息提交以后，該消息才不會被再次接 收到，還可以配合 auto.commit.interval.ms 控制自動提交的頻率。 當然，我們也可以通過 consumer.commitSync()的方式實現(xiàn)手動提交
auto.offset.reset
這個參數(shù)是針對新的 groupid 中的消費者而言的，當有新 groupid 的消費者來 消費指定的 topic 時，對于該參數(shù)的配置，會有不同的語義
auto.offset.reset=latest 情況下，新的消費者將會從其他消費者最后消費的 offset 處開始消費 Topic 下的消息
auto.offset.reset= earliest 情況下，新的消費者會從該 topic 最早的消息開始 消費
auto.offset.reset=none 情況下，新的消費者加入以后，由于之前不存在 offset，則會直接拋出異常。
max.poll.records
此設(shè)置限制每次調(diào)用 poll 返回的消息數(shù)，這樣可以更容易的預測每次 poll 間隔 要處理的最大值。通過調(diào)整此值，可以減少 poll 間隔
