小编点评

本文主要讨论了优化金字塔应用程序框架层面、JVM层面以及操作系统层面的方法。具体内容包括： 1. **业务代码优化**： - 合理使用Kafka，合理规划主题和分区。 - 合理设计数据结构。 2. **框架层面调优**： - 不改动源码的前提下，从Kafka参数配置入手。 - 结合业务体量和运行数据进行调优。 3. **JVM层面调优**： - 在出现明显缓慢和可能的内存溢出的情况下进行调优。 - 调整堆内存、非堆内存、GC方式等参数。 4. **操作系统层面调优**： - 尽量减少Kafka程序运行限制。 - 关注文件描述符限制、Selinux限制、JDK版本等情况。 5. **文件系统选择**： - 生产环境推荐使用XFS，具备高性能和高伸缩性。 - ZFS针对高IO的Kafka有不错的效果，但未大规模验证。 6. **Swap空间参数设置**： - 设置小一点的Swap空间参数。 7. **控制进程可拥有的内存映射区域的最大数量**： - 设置一个合理的值。 8. **操作系统页缓存**： - 页缓存的大小应超过一个日志段大小。 9. **JVM层面调优(1)**： - 堆内存参数设置。 - GC选择器。 - JDK选择。 10. **框架调优（Broker层面）**： - 版本适配。 - 消息压缩方式。 - num.io.thread。 - num.recovery.threads.per.data.dir。 - num.network.thread。 - log.retention.bytes。 - message.max.bytes。 - num.replica.fetchers。 11. **框架调优（Producer层面）**： - 消息发送确认机制。 - 批量发送消息大小。 - 发送最大时延。 12. **框架调优（Consumer层面）**： - 消息提交机制。 - 消息数据批量大小。 - fetch.min.bytes。 13. **应用程序层面调优**： - 保证业务代码健壮性。 - 避免频繁创建Producer和Consumer。 - 合理创建线程池进行连接复用。 - 合理利用多线程进行推送，消费消息。 综上所述，通过以上方法的综合应用，可以有效提升金字塔应用程序的性能和稳定性。

正文

优化金字塔

应用程序层面
框架层面（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)合理利用多线程进行推送，消费消息