业务过载处理建议

方案概述

Kafka业务过载，一般表现为CPU使用率高、磁盘写满的现象。

• 当CPU使用率过高时，系统的运行速度会降低，并有加速硬件损坏的风险。
• 当磁盘写满时，相应磁盘上的Kafka日志目录会出现offline问题。此时，该磁盘上的分区副本不可读写，降低了分区的可用性和容错能力。同时由于Leader分区迁移到其他节点，会增加其他节点的负载。

CPU使用率高的原因

• 数据操作相关线程数（num.io.threads、num.network.threads、num.replica.fetchers）过多，导致CPU繁忙。
• 分区设置不合理，所有的生产和消费都集中在某个节点上，导致CPU利用率高。

磁盘写满的原因

• 业务数据增长较快，已有的磁盘空间不能满足业务数据需要。
• 节点内磁盘使用率不均衡，生产的消息集中在某个分区，导致分区所在的磁盘写满。
• Topic的数据老化时间设置过大，保存了过多的历史数据，容易导致磁盘写满。

实施步骤

CPU使用率高的处理措施：

• 优化线程参数num.io.threads、num.network.threads和num.replica.fetchers的配置。
  • num.io.threads和num.network.threads建议配置为磁盘个数的倍数，但不能超过CPU核数。
  • num.replica.fetchers建议配置不超过5。
• 合理设置Topic的分区，分区一般设置为节点个数的倍数。
• 生产消息时，给消息Key加随机后缀，使消息均衡分布到不同分区上。
  

  在实际业务场景中，为消息Key加随机后缀，会导致消息全局不保序，需根据实际业务判断是否适合给消息Key加随机后缀。

磁盘写满的处理措施：

• 扩容磁盘，使磁盘具备更大的存储空间。
• 迁移分区，将已写满的磁盘中的分区迁移到本节点的其他磁盘中。
• 合理设置Topic的数据老化时间，减少历史数据的容量大小。
• 在CPU资源情况可控的情况下，使用压缩算法对数据进行压缩。

  常用的压缩算法包括：ZIP，GZIP，SNAPPY，LZ4等。选择压缩算法时，需考虑数据的压缩率和压缩耗时。通常压缩率越高的算法，压缩耗时也越高。对于性能要求高的系统，可以选择压缩速度快的算法，比如LZ4；对于需要更高压缩比的系统，可以选择压缩率高的算法，比如GZIP。

  可以在生产者端配置“compression.type”参数来启用指定类型的压缩算法。

  Properties props = new Properties();
  props.put("bootstrap.servers", "localhost:9092");
  props.put("acks", "all");
  props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
  props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
  // 开启GZIP压缩
  props.put("compression.type", "gzip");
   
  Producer<String, String> producer = new KafkaProducer<>(props);