一 ， broker優化：
優化處理消息的最大線程數 默認是3 可以調成CPU數+1
broker處理磁盤IO線程數 CUP數*2
調整log的文件刷盤策略 10000條或者1秒
日志保存策略調整為72小時 不建議過多
副本機制調整為2-3
根據業務量調整合適的partition數量
二，Producer優化：
調整未發送出去消息的緩沖區大小
默認發送不壓縮，可以配置合適的壓縮方式（Snappy）
三， Consumer優化：
1.啟動consumer的線程數適當的增加可以提高并發度 與分區數一致
Kafka內存：默認一個G可以適當的調高一些，一般不建議超過6個G
消息壓縮
壓縮的是使用時間換空間的思想，具體來說就是使用CPU的時間去換取空間或網絡I/0傳輸量。
怎么壓縮？
kafka是如何壓縮的消息的呢？目前，kafka共有倆大消息格式，社區分別稱之為V1版本和V2版本。V2B版本是在kafka0.11.0.0中正式引入的。
不論哪個版本，kafka的消息分為倆層：消息集合（message set）以及消息（message）。一個消息集合中包含若干條日志項（record item），而日志項才是真正封裝消息的地方。kafka底層的消息日志由一系列消息集合日志項組成。kafka通常不會直接操作具體的一條條消息，他總是在消息集合這個層面上進行寫入操作。
那么社區引入V2版本的目的是什么呢？主要是針對V1版本做了一些修改，先介紹一個，就是把消息的公共部分抽取出來放到外層消息集合里面，這樣就不用每條消息都保存這些信息了。
V2版本還有一個和壓縮息息相關的改進，就是保存壓縮消息的方法發生了改變。之前V1版本中保存壓縮消息的方法是把多條消息進行壓縮后保存到外層消息字段中；而V2版本的做法是對整個消息集合進行壓縮。顯然后者應該比前者有更好的性能。比較如下：
何時壓縮?
kafka中，壓縮可能發生在倆個地方：生產者和Broker端.
生產者程序中配置compression.type參數即表示啟用指定類型的壓縮算法（比如snappy）
在生產者端啟用壓縮是很自然的想法，那么為什么我說在Broker端也可以進行壓縮呢？其實大部分情況下Broker從Producer端接受消息后僅僅是原封不動的保存而不會對其進行任何修改，但這里的”大部分情況“也是要滿足一定條件的。有倆種例外的情況就可能讓Broker重新壓縮消息。
情況一：Broker端指定了和Producer端不同的壓縮算法。
當Broker和Product指定的壓縮算法不一致時，Broker接收到Product消息后解壓之后再用Broker指定的算法在壓縮，這樣就會到導致CPU壓力飆升。kafka服務端有指定壓縮算法的參數compression.type，這個參數默認是product意思是指定和product一樣的壓縮算法。
情況二：Broker端發生了消息格式轉換
所謂的消息格式轉換只要是為了兼容老版本的消費者程序。由于kafka現在有倆種消息格式V1版本和V2版本，為了兼容老版本的格式，Broker端會對新版消息執行想老版本格式的轉換。這個過程會涉及消息的解壓縮和重新壓縮。這種情況下對性能影響很大，除了這里的壓縮之外，它還會讓kafka失去引以為豪的Zero Copy （零拷貝）特性。
何時解壓?
通常來說解壓縮發生在消費者程序中，也就是說Produc發送壓縮消息到Broker后，Broker照單全收并原樣保存起來。當Consumer程序請求這部分消息時，Broker依然原樣發送出去，當消息到達Consumer端后，由Consumer自行解壓縮還原成之前的消息。
那么現在問題來了，Consumer怎么知道這些消息是用何種算法壓縮的呢？其實答案就在消息中。kafka會將啟用了那種壓縮算法封裝進行消息集合中，這樣Consumer收到消息集合時，它自然知道了這些消息使用的是那種算法。
壓縮解壓縮過程：Product端壓縮----Broker端保持----Consumer端解壓縮
除了在Consumer端解壓縮，Broker端也會進行解壓縮。注意了，這和前面提到的消息格式轉換時發生的解壓縮是不同的場景。每個壓縮過的消息集合在Broker端寫入時都要發生解壓縮操作，目的就是為了對消息進行各種驗證。但是必須承認這種解壓縮對Broker端性能是有一定影響的，特別是對CPU使用率而言。
各種壓縮算法對比
在kafka2.1.0版本之前，kafka支持3種壓縮算法：GZIP、Snappy和LZ4。從2.1.0開始，kafka正式支持Zstandard算法（簡稱：zstd）。這是一個Facebook開源的一個壓縮算法，能夠提供超高的壓縮比（compression ratio）
壓縮算法的優劣又來個重要的指標：壓縮比和吞吐量
下面是Facebook提供的壓縮算法對比圖：
