一 ， broker優(yōu)化：

1. 優(yōu)化處理消息的最大線程數(shù) 默認(rèn)是3 可以調(diào)成CPU數(shù)+1

2. broker處理磁盤(pán)IO線程數(shù) CUP數(shù)*2

3. 調(diào)整log的文件刷盤(pán)策略 10000條或者1秒

4. 日志保存策略調(diào)整為72小時(shí) 不建議過(guò)多

5. 副本機(jī)制調(diào)整為2-3

6. 根據(jù)業(yè)務(wù)量調(diào)整合適的partition數(shù)量

二，Producer優(yōu)化：

1. 調(diào)整未發(fā)送出去消息的緩沖區(qū)大小

2. 默認(rèn)發(fā)送不壓縮，可以配置合適的壓縮方式（Snappy）

三， Consumer優(yōu)化：

1.啟動(dòng)consumer的線程數(shù)適當(dāng)?shù)脑黾涌梢蕴岣卟l(fā)度 與分區(qū)數(shù)一致

Kafka內(nèi)存：默認(rèn)一個(gè)G可以適當(dāng)?shù)恼{(diào)高一些，一般不建議超過(guò)6個(gè)G

消息壓縮

壓縮的是使用時(shí)間換空間的思想，具體來(lái)說(shuō)就是使用CPU的時(shí)間去換取空間或網(wǎng)絡(luò)I/0傳輸量。

怎么壓縮？

kafka是如何壓縮的消息的呢？目前，kafka共有倆大消息格式，社區(qū)分別稱(chēng)之為V1版本和V2版本。V2B版本是在kafka0.11.0.0中正式引入的。

不論哪個(gè)版本，kafka的消息分為倆層：消息集合（message set）以及消息（message）。一個(gè)消息集合中包含若干條日志項(xiàng)（record item），而日志項(xiàng)才是真正封裝消息的地方。kafka底層的消息日志由一系列消息集合日志項(xiàng)組成。kafka通常不會(huì)直接操作具體的一條條消息，他總是在消息集合這個(gè)層面上進(jìn)行寫(xiě)入操作。

那么社區(qū)引入V2版本的目的是什么呢？主要是針對(duì)V1版本做了一些修改，先介紹一個(gè)，就是把消息的公共部分抽取出來(lái)放到外層消息集合里面，這樣就不用每條消息都保存這些信息了。

V2版本還有一個(gè)和壓縮息息相關(guān)的改進(jìn)，就是保存壓縮消息的方法發(fā)生了改變。之前V1版本中保存壓縮消息的方法是把多條消息進(jìn)行壓縮后保存到外層消息字段中；而V2版本的做法是對(duì)整個(gè)消息集合進(jìn)行壓縮。顯然后者應(yīng)該比前者有更好的性能。比較如下：

圖片.png

何時(shí)壓縮?

kafka中，壓縮可能發(fā)生在倆個(gè)地方：生產(chǎn)者和Broker端.

生產(chǎn)者程序中配置compression.type參數(shù)即表示啟用指定類(lèi)型的壓縮算法（比如snappy）

在生產(chǎn)者端啟用壓縮是很自然的想法，那么為什么我說(shuō)在Broker端也可以進(jìn)行壓縮呢？其實(shí)大部分情況下Broker從Producer端接受消息后僅僅是原封不動(dòng)的保存而不會(huì)對(duì)其進(jìn)行任何修改，但這里的”大部分情況“也是要滿足一定條件的。有倆種例外的情況就可能讓Broker重新壓縮消息。

情況一：Broker端指定了和Producer端不同的壓縮算法。

當(dāng)Broker和Product指定的壓縮算法不一致時(shí)，Broker接收到Product消息后解壓之后再用Broker指定的算法在壓縮，這樣就會(huì)到導(dǎo)致CPU壓力飆升。kafka服務(wù)端有指定壓縮算法的參數(shù)compression.type，這個(gè)參數(shù)默認(rèn)是product意思是指定和product一樣的壓縮算法。

情況二：Broker端發(fā)生了消息格式轉(zhuǎn)換

所謂的消息格式轉(zhuǎn)換只要是為了兼容老版本的消費(fèi)者程序。由于kafka現(xiàn)在有倆種消息格式V1版本和V2版本，為了兼容老版本的格式，Broker端會(huì)對(duì)新版消息執(zhí)行想老版本格式的轉(zhuǎn)換。這個(gè)過(guò)程會(huì)涉及消息的解壓縮和重新壓縮。這種情況下對(duì)性能影響很大，除了這里的壓縮之外，它還會(huì)讓kafka失去引以為豪的Zero Copy （零拷貝）特性。

何時(shí)解壓?

通常來(lái)說(shuō)解壓縮發(fā)生在消費(fèi)者程序中，也就是說(shuō)Produc發(fā)送壓縮消息到Broker后，Broker照單全收并原樣保存起來(lái)。當(dāng)Consumer程序請(qǐng)求這部分消息時(shí)，Broker依然原樣發(fā)送出去，當(dāng)消息到達(dá)Consumer端后，由Consumer自行解壓縮還原成之前的消息。

那么現(xiàn)在問(wèn)題來(lái)了，Consumer怎么知道這些消息是用何種算法壓縮的呢？其實(shí)答案就在消息中。kafka會(huì)將啟用了那種壓縮算法封裝進(jìn)行消息集合中，這樣Consumer收到消息集合時(shí)，它自然知道了這些消息使用的是那種算法。

壓縮解壓縮過(guò)程：Product端壓縮----Broker端保持----Consumer端解壓縮

除了在Consumer端解壓縮，Broker端也會(huì)進(jìn)行解壓縮。注意了，這和前面提到的消息格式轉(zhuǎn)換時(shí)發(fā)生的解壓縮是不同的場(chǎng)景。每個(gè)壓縮過(guò)的消息集合在Broker端寫(xiě)入時(shí)都要發(fā)生解壓縮操作，目的就是為了對(duì)消息進(jìn)行各種驗(yàn)證。但是必須承認(rèn)這種解壓縮對(duì)Broker端性能是有一定影響的，特別是對(duì)CPU使用率而言。

各種壓縮算法對(duì)比

在kafka2.1.0版本之前，kafka支持3種壓縮算法：GZIP、Snappy和LZ4。從2.1.0開(kāi)始，kafka正式支持Zstandard算法（簡(jiǎn)稱(chēng)：zstd）。這是一個(gè)Facebook開(kāi)源的一個(gè)壓縮算法，能夠提供超高的壓縮比（compression ratio）

壓縮算法的優(yōu)劣又來(lái)個(gè)重要的指標(biāo)：壓縮比和吞吐量

下面是Facebook提供的壓縮算法對(duì)比圖：

圖片.png