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

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

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

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

最新文章

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

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

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

但需要注意，過高的 linger.ms 會增加消息的端到端延遲。

異步發(fā)送機制

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

最新文章

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ù)消息，通過回調(diào)機制處理發(fā)送結(jié)果。

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

壓縮機制

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

最新文章

比如：

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

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

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

lz4: 壓縮和解壓縮速度非?？欤珻PU 消耗很低，但壓縮率可能不如 gzip 或 snappy，適用于對延遲非常敏感的場景。

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

在高吞吐場景中推薦使用 lz4 、或 zstd。

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

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

Kafka Broker 利用 Page Cache 順序?qū)?，提高寫入效率?/span>

最新文章

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

由于是順序?qū)懭?，新的?shù)據(jù)總是追加到 Page Cache 的尾部，這是一個非?？焖俚膬?nèi)存操作。

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

這種機制，使得 Kafka Broker 能夠承受非常高的寫入吞吐量。