一 ， 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提供的压缩算法对比图：
