3.表示单个Acceptor创建Processor处理器的线程个数，默认为3。适当调到9。
1.表示follower副本用多少线程来拉取数据，默认一个线程;如果Broker端的CPU资源很充足的话可以适当增加这个参数值，但不要设置超过CPU核数，这样就可以加快follower副本的同步速度
如果这个参数设置的太小就会导致频繁的网络请求，吞吐量就会下降。如果设置的太长会导致一条消息等待很久才会被发送出去，也会增加网络延迟。建议设置在10-100ms之间。
2.RecordAccumulator：消息缓冲区的总大小 buffer.memory这个参数默认值32MB
3.linger.ms：表示批次的缓冲时间
4.开启压缩:compression.type=snappy默认none，不压缩
在设置好生产者和Broker端的参数后，就可以避免频繁的发生Full GC。接下来是消费者端的优化策略：
哪些手段可以提高吞吐量
如果数据迟迟没有达到一个batch.size大小，batch.size线程会等待linger.ms之后就会向broker上落地数据。这个参数的单位是毫秒。默认值是0。表示消息会被立即发出去。
设置好这些参数后，生产者会把数据不断堆积到batch.size中;然后数据以批次堆积到broker上
重试次数：如果允许丢数据可以设置为一个较小的值，比方0
从生产者、broker端、topic、消费者端一共四个方面来优化我们的Kafka集群！
适当增加到64MB
如果batch.size太小，就会导致频繁网络请求，吞吐量就会下降
消费者端一次拉取消息的最大条数，默认500条。可适当提高。
5.设置acks和retries
同时设置一个我们能够接受的低延迟
吞吐量
所以要适当增加这个参数值，以提高吞吐量：建议提高到512KB or 1MB
表示broker端积攒了多少数据就可以发给consumer端了，默认1字节。适当增大为1KB或者更大。
1.对于生产者来说，batch.size的大小表示消息批次的大小，默认是16KB
减少数据传输量，进而提高吞吐量。但是压缩也会增加生产端的CPU开销。
分区数多少需要搭建好集群后进行压测再灵活的调整分区数，可以用kafka官方自带的压测脚本
压缩格式：none、snappy、gzip、zstd等
如果batch.size太大，就会导致一条消息等待过久才会发出去，可能会增加网络延迟
acks=all级别最高，但是对于传输数据量大允许丢失数据的场景，可以设置acks=0/1 以提高响应速度
最后，对topic的优化：主要是设置合理的分区数
2.用来控制ISR列表的，如果某个follower副本长时间没有从leader副本同步数据的话，这个follower副本就会被踢出ISR列表。默认30s。如果设置过大，在ISR列表中复制数据慢的follower副本就会影响到整个集群的响应速度。
4.服务器用于处理请求的线程数，包括磁盘IO，默认值8，我们可以适当把这个值提升到32。
消费者获取服务器端一批数据的最大字节数。默认50M。一批次的大小主要受下面两个参数限制，一个是broker端的配置，一个是在topic级别的配置。
低延迟
如何优化线上Kafka系统？两个重要的优化指标
Broker的优化策略：
