优化金字塔

应用程序层面

框架层面（Broker层面）

JVM层面

操作系统层面

应用程序层面：应当优化业务代码合理使用kafka，合理规划主题，合理规划分区，合理设计数据结构；

框架层面：在不改动源码的情况下，从kafka参数配置入手，结合业务体量和运行数据进行调优

JVM层面：在出现明显缓慢和可能的内存溢出的情况下，结合业务代码情况和服务器能力调优堆内存，非堆内存，GC方式等参数，非必要不更改过多参数

操作系统层面：在服务器操作系统层面调优尽量减少kafka程序运行限制，关注文件描述符限制，Selinux限制，JDK版本等情况

操作系统调优

文件系统的选择上，可选择XFS和EXT4，生产环境推荐XFS，具备高性能和高伸缩性优点，最新的报道显示具备多级缓存的ZFS针对高IO的kafka有不错的效果，但并未大规模验证

Swap空间参数设置：尽量设置小一点，修改/etc/sysctl.conf文件，增加vm.swappiness=，防止Linux OOM Killer线程随意杀线程

文件描述符：ulimit -n不能设置过小，在topic数量稍大时就会出现Too Many File Open报错情况

控制进程可以拥有的内存映射区域的最大数量：vm.max_map_count，设置过小会出现内存溢出情况

操作系统页缓存：由于Kafka存储数据时只要数据到来Page Cache页缓存就会返回Ack给生产者，并不会直接落盘，还需要等待触发或手动刷盘操作进行持久化刷盘，此时操作系统的Cached大小必须超过一个日志段大小，Broker上对应参数为log.segment.bytes，越大消费者在消费时有更大概率在缓存页命中，避免频繁IO从硬盘读取数据。

JVM层面调优

(1)堆内存参数设置：kafka本身并不占用过多堆内存，6-8G相对合适，在kafka-server-start.sh设置KAFKA_HEAP_OPTS参数即可；更精确可以查看KafkaServer-gc.log，关注Full GC之后堆上存活大小的总量，从而可以将堆内存设置为这个值的2-2.5倍，可以使用图上命令进行手动GC(2)GC选择器：博主kafka3.5.1版本的kafka集群使用openjdk11.0.X，默认G1收集器；在G1中Full GC是单线程运行，在生产环境中要尽量避免Full GC(3)JDK选择：至少JDK1.8，推荐JDK11，kafka3.0推荐至少使用JDK11

框架调优（Broker层面）

(1)版本适配：尽量保持客户端版本和Broker端版本一致或尽量适配，以避免版本之间不一致问题导致的性能优化损失，如零拷贝等特性(2)消息压缩方式：Broker端和Producer段的消息压缩方式应该保持一致，推荐lz4，第二选择gzip，如果设置得不一致会导致Broker付出大量额外的CPU性能用于解压和二次压缩(3)num.io.thread：Handler线程用于执行业务处理，Acceptor线程用于接收网络请求，Processor线程用于建立网络连接和分发网络请求，Handler线程才是执行业务请求处理的线程，由Broker参数num.io.thread决定，数量越大执行线程越多，处理速度更快(4)num.recovery.threads.per.data.dir：Broker重启后恢复线程数量，设置越大，追上数据进入ISR越快(5)num.network.thread：The number of threads that the server uses for receiving requests from the network and sending responses to the network，增加这个线程参数就是提高收发网络请求的速度(6)log.retention.bytes：日志保存时间，针对业务需求合理设置时间(7)message.max.bytes：针对消息集合打包的大消息体业务，需要设置更大的参数(8)num.replica.fetchers：副本数据同步线程，应当不超过cpu核数，通常设置为4-8即可

框架调优（Producer层面）

(1)消息发送确认机制：acks=all，通常情况下在生产环境设置为acks=1即Leader副本确认即可(2)批量发送消息大小：batch.size= 发送到同一个分区消息的批次大小限制(3)发送最大时延：linger.ms=,批量大小没有达到batch.size,最大允许时延

框架调优（Consumer层面）

(1)消息提交机制：如为保证消息不重复消费即手动提交消息(2)消息数据批量大小：fetch.min.bytes，如果时延不敏感追求吞吐量，可设置得大一点

应用程序层面调优

(1)保证业务代码健壮性，保证容器不会出现过多bug导致反复重启诱发Kafka集群Rebalance
(2)不要频繁创建Producer和Consumer，建立的连接要Close；
(3)合理创建线程池进行连接复用
(4)合理利用多线程进行推送，消费消息

文章转载自：付同學

原文链接：https://www.cnblogs.com/iamxiaofu/p/18243430

体验地址：引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构