Kafka是大型架構(gòu)必備技能，下面我就重點(diǎn)詳解Kafka生產(chǎn)者如何實(shí)現(xiàn)高吞吐@mikechen

批量發(fā)送優(yōu)化

Kafka 的 Producer 并不是每寫(xiě)一條消息就立即發(fā)送，而是將多條消息收集起來(lái)。

組成一個(gè)批次（batch）一起發(fā)送，以減少網(wǎng)絡(luò)開(kāi)銷(xiāo)并提高吞吐。

最新文章

這里適當(dāng)增加 linger.ms 的值（例如：設(shè)置為幾毫秒…..到幾十毫秒）。

[ProducerRecord]
 ↓
 [BufferPool]←多條消息緩沖
 ↓
 [Batch formed ]←達(dá)到 batch.size 或 linger.ms 觸發(fā)發(fā)送
 ↓
 [KafkaBroker]

允許生產(chǎn)者收集更多消息形成更大的批次，從而提高吞吐量。

但需要注意，過(guò)高的 linger.ms 會(huì)增加消息的端到端延遲。

異步發(fā)送機(jī)制

Kafka Producer 的 send() 方法是異步的，調(diào)用后會(huì)立即返回一個(gè) Future<RecordMetadata> 對(duì)象。

最新文章

producer.send(record,(metadata, exception)->{
 if(exception ==null){
 System.out.println("Success: "+ metadata.offset());
 }else{
         exception.printStackTrace();
 }
 });

生產(chǎn)者發(fā)送消息后不立即等待 Broker 的響應(yīng)，而是繼續(xù)發(fā)送后續(xù)消息，通過(guò)回調(diào)機(jī)制處理發(fā)送結(jié)果。

這樣，生產(chǎn)者無(wú)需等待 Broker 的確認(rèn)，可以流水線(xiàn)式地發(fā)送消息，極大地提高了發(fā)送速率。

壓縮機(jī)制

在生產(chǎn)者端對(duì)消息數(shù)據(jù)進(jìn)行壓縮，減小網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量，從而提高有效吞吐量。

最新文章

比如：

gzip: 壓縮率高，但 CPU 消耗也相對(duì)較高。

snappy: 壓縮和解壓縮速度快，CPU 消耗較低，壓縮率適中。

在吞吐量和 CPU 利用率之間提供了較好的平衡，是常見(jiàn)的選擇。

lz4: 壓縮和解壓縮速度非常快，CPU 消耗很低，但壓縮率可能不如 gzip 或 snappy，適用于對(duì)延遲非常敏感的場(chǎng)景。

zstd: 提供比 gzip 更高的壓縮率，同時(shí)保持良好的壓縮和解壓縮速度，但 CPU 消耗可能略高。

在高吞吐場(chǎng)景中推薦使用 lz4 、或 zstd。

在對(duì) CPU 敏感的系統(tǒng)中可選擇 snappy。

并發(fā)發(fā)送能力

Kafka Broker 利用 Page Cache 順序?qū)懀岣邔?xiě)入效率。

最新文章

當(dāng) Kafka Broker 接收到生產(chǎn)者的消息并需要將其寫(xiě)入磁盤(pán)時(shí)，它首先將數(shù)據(jù)寫(xiě)入到操作系統(tǒng)為該日志文件維護(hù)的 Page Cache 中。

由于是順序?qū)懭耄碌臄?shù)據(jù)總是追加到 Page Cache 的尾部，這是一個(gè)非常快速的內(nèi)存操作。

順序?qū)憳O大地減少了磁盤(pán)尋道時(shí)間，而 Page Cache 的使用將大部分寫(xiě)操作變成了快速的內(nèi)存操作，只有在操作系統(tǒng)進(jìn)行刷盤(pán)時(shí)才會(huì)有磁盤(pán) I/O。

這種機(jī)制，使得 Kafka Broker 能夠承受非常高的寫(xiě)入吞吐量。