講解樣例代碼中的參數(shù)含義：
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("buffer.memory", 67108864);
props.put("batch.size", 131072);
props.put("linger.ms", 100);
props.put("max.request.size", 10485760);
props.put("acks", "1");
props.put("retries", 10);
props.put("retry.backoff.ms", 500);
KafkaProducer<String, String> producer = new KafkaProducer<String, String>(props);
buffer.memory 參數(shù)是什么意思？
Kafka的客戶端發(fā)送數(shù)據(jù)到服務(wù)器，一般都是要經(jīng)過緩沖的，也就是說，你通過KafkaProducer發(fā)送出去的消息都是先進(jìn)入到客戶端本地的內(nèi)存緩沖里，然后把很多消息收集成一個一個的Batch，再發(fā)送到Broker上去的。
所以這個“buffer.memory”的本質(zhì)就是用來約束KafkaProducer能夠使用的內(nèi)存緩沖的大小的，他的默認(rèn)值是32MB。
那么既然了解了這個含義，大家想一下，在生產(chǎn)項目里，這個參數(shù)應(yīng)該怎么來設(shè)置呢？
你可以先想一下，如果這個內(nèi)存緩沖設(shè)置的過小的話，可能會導(dǎo)致一個什么問題？
首先要明確一點，那就是在內(nèi)存緩沖里大量的消息會緩沖在里面，形成一個一個的Batch，每個Batch里包含多條消息。
然后KafkaProducer有一個Sender線程會把多個Batch打包成一個Request發(fā)送到Kafka服務(wù)器上去。
那么如果要是內(nèi)存設(shè)置的太小，可能導(dǎo)致一個問題：消息快速的寫入內(nèi)存緩沖里面，但是Sender線程來不及把Request發(fā)送到Kafka服務(wù)器。
這樣是不是會造成內(nèi)存緩沖很快就被寫滿？一旦被寫滿，就會阻塞用戶線程，不讓繼續(xù)往Kafka寫消息了。
所以對于“buffer.memory”這個參數(shù)應(yīng)該結(jié)合自己的實際情況來進(jìn)行壓測，你需要測算一下在生產(chǎn)環(huán)境，你的用戶線程會以每秒多少消息的頻率來寫入內(nèi)存緩沖。
比如說每秒300條消息，那么你就需要壓測一下，假設(shè)內(nèi)存緩沖就32MB，每秒寫300條消息到內(nèi)存緩沖，是否會經(jīng)常把內(nèi)存緩沖寫滿？經(jīng)過這樣的壓測，你可以調(diào)試出來一個合理的內(nèi)存大小。
batch.size 參數(shù)
這個東西是決定了你的每個Batch要存放多少數(shù)據(jù)就可以發(fā)送出去了。
比如說你要是給一個Batch設(shè)置成是16KB的大小，那么里面湊夠16KB的數(shù)據(jù)就可以發(fā)送了。
這個參數(shù)的默認(rèn)值是16KB，一般可以嘗試把這個參數(shù)調(diào)節(jié)大一些，然后利用自己的生產(chǎn)環(huán)境發(fā)消息的負(fù)載來測試一下。
比如說發(fā)送消息的頻率就是每秒300條，那么如果比如“batch.size”調(diào)節(jié)到了32KB，或者64KB，是否可以提升發(fā)送消息的整體吞吐量。
因為理論上來說，提升batch的大小，可以允許更多的數(shù)據(jù)緩沖在里面，那么一次Request發(fā)送出去的數(shù)據(jù)量就更多了，這樣吞吐量可能會有所提升。
但是這個東西也不能無限的大，過于大了之后，要是數(shù)據(jù)老是緩沖在Batch里遲遲不發(fā)送出去，那么豈不是你發(fā)送消息的延遲就會很高。
比如說，一條消息進(jìn)入了Batch，但是要等待5秒鐘Batch才湊滿了64KB，才能發(fā)送出去。那這條消息的延遲就是5秒鐘。
所以需要在這里按照生產(chǎn)環(huán)境的發(fā)消息的速率，調(diào)節(jié)不同的Batch大小自己測試一下最終出去的吞吐量以及消息的 延遲，設(shè)置一個最合理的參數(shù)。
linger.ms，解決一個Batch遲遲無法湊滿情況
他的含義就是說一個Batch被創(chuàng)建之后，最多過多久，不管這個Batch有沒有寫滿，都必須發(fā)送出去了。
給大家舉個例子，比如說batch.size是16kb，但是現(xiàn)在某個低峰時間段，發(fā)送消息很慢。
這就導(dǎo)致可能Batch被創(chuàng)建之后，陸陸續(xù)續(xù)有消息進(jìn)來，但是遲遲無法湊夠16KB，難道此時就一直等著嗎？
當(dāng)然不是，假設(shè)你現(xiàn)在設(shè)置“l(fā)inger.ms”是50ms，那么只要這個Batch從創(chuàng)建開始到現(xiàn)在已經(jīng)過了50ms了，哪怕他還沒滿16KB，也要發(fā)送他出去了。
所以“l(fā)inger.ms”決定了你的消息一旦寫入一個Batch，最多等待這么多時間，他一定會跟著Batch一起發(fā)送出去。
避免一個Batch遲遲湊不滿，導(dǎo)致消息一直積壓在內(nèi)存里發(fā)送不出去的情況。這是一個很關(guān)鍵的參數(shù)。
這個參數(shù)一般要非常慎重的來設(shè)置，要配合batch.size一起來設(shè)置。
舉個例子，首先假設(shè)你的Batch是32KB，那么你得估算一下，正常情況下，一般多久會湊夠一個Batch，比如正常來說可能20ms就會湊夠一個Batch。
那么你的linger.ms就可以設(shè)置為25ms，也就是說，正常來說，大部分的Batch在20ms內(nèi)都會湊滿，但是你的linger.ms可以保證，哪怕遇到低峰時期，20ms湊不滿一個Batch，還是會在25ms之后強(qiáng)制Batch發(fā)送出去。
如果要是你把linger.ms設(shè)置的太小了，比如說默認(rèn)就是0ms，或者你設(shè)置個5ms，那可能導(dǎo)致你的Batch雖然設(shè)置了32KB，但是經(jīng)常是還沒湊夠32KB的數(shù)據(jù)，5ms之后就直接強(qiáng)制Batch發(fā)送出去，這樣也不太好其實，會導(dǎo)致你的Batch形同虛設(shè)，一直湊不滿數(shù)據(jù)。
重試機(jī)制
“retries”和“retries.backoff.ms”決定了重試機(jī)制，也就是如果一個請求失敗了可以重試幾次，每次重試的間隔是多少毫秒。
這個大家適當(dāng)設(shè)置幾次重試的機(jī)會，給一定的重試間隔即可，比如給100ms的重試間隔。
持久化機(jī)制
Ack三個選項，0表示不需要任何分區(qū)確認(rèn)收到，發(fā)送端就認(rèn)為是成功的，1表示只要主分區(qū)確認(rèn)接收成功就認(rèn)為是成功的，all表示主分區(qū)和從分區(qū)都確認(rèn)收到請求才認(rèn)為是成功的
