Kafka运维 - 运维常见

分区数不足：

1. 吞吐量限制：Kafka的分区数决定了集群的并行处理能力。如果分区数不足，可能会导致集群无法处理高并发的生产者和消费者请求，从而限制了整体的吞吐量。
2. 负载不均衡：Kafka 使用分区来实现消息的负载均衡。如果分区数不足，可能会导致某些分区上的消息量过大，而其他分区上的消息量较少。这会导致一些消费者负载过重，而其他消费者负载较轻，从而影响系统的整体性能和稳定性。

解决方案：修改分区数

kafka-topics.sh --zookeeper <zookeeper_address> --alter --topic topic_name --partitions 3

一旦修改了 Topic 的分区数，Kafka 会触发分区的重新分配过程

副本数不足：

1. 可用性降低：Kafka 使用副本来提供数据的冗余和容错能力。如果副本数不足，系统的可用性可能会降低。当某个副本所在的节点或者磁盘发生故障时，可能会导致数据丢失或者无法访问。
2. 容错性下降：副本数不足也会降低系统的容错性。如果副本数不足，当某个副本不可用时，无法通过其他副本来提供数据服务。这可能导致消息丢失或者无法正常处理。

解决方案：修改副本数

kafka-topics.sh --zookeeper <zookeeper_address> --alter --topic topic_name --replication-factor 3

一旦修改了 Topic 的分区数，Kafka 会触发副本的重新分配过程

topic数据迁移（切换集群）：

• 使用kafka-console：可以使用 Kafka 提供的工具，如kafka-console-consumer和kafka-console-producer，通过消费源 Topic 的数据，然后将其生产到目标 Topic 中。这种方法适用于数据量较小的情况。
• 使用 MirrorMaker：MirrorMaker 是 Kafka 提供的一个工具，用于在不同的 Kafka 集群之间进行数据复制。你可以配置 MirrorMaker，使其从源 Kafka 集群消费数据，并将其生产到目标 Kafka 集群的目标 Topic 中。这种方法适用于大规模数据迁移和跨数据中心的情况。

你可以使用以下命令启动 MirrorMaker 进行数据复制：

kafka-run-class.sh kafka.tools.MirrorMaker --consumer.config <source_consumer_properties> --producer.config <target_producer_properties> --whitelist <source_topic> --num.streams <num_streams>

其中，<source_consumer_properties> 是源 Kafka 集群的消费者配置文件，<target_producer_properties> 是目标 Kafka 集群的生产者配置文件，<source_topic> 是要迁移的源 Topic 名称，<num_streams> 是并行处理数据的流的数量。

手动topic重分配（拓展/减少broker，或者分区分配不均匀）

# 执行分区计划

kafka-reassign-partitions.sh --zookeeper <zookeeper_address> --reassignment-json-file reassignment.json --execute

# 验证分区计划进度

kafka-reassign-partitions.sh --zookeeper <zookeeper_address> --reassignment-json-file reassignment.json --verify

reassignment.json

{

  "version":1,

  "partitions":[

    {"topic":"my_topic","partition":0,"replicas":[1,2,3]},

    {"topic":"my_topic","partition":1,"replicas":[2,3,4]},

    ...

  ]

}

默认情况下：添加或删除 Broker，修改 Topic 的分区数或副本数会自动触发分区重分配，由controller监测/控制

消息积压

1. 生产环境处理

• 分区数大于消费者消费数量时，一个消费者消费几个分区，消费速度会变慢。此时可以通过增加消费者处理。如果分区数<=消费者数，并且容忍一定程度的消息丢失，不一致，重复消费问题，可以拓展分区并增加消费者（拓展分区数量可能会导致消费者重新平衡和重新分配分区）
• 如果是下游的数据处理不及时：可以消费者提高每批次拉取的数量。每批次拉取的数据过少（拉取的数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。

1. 优化

• 拓展集群、增加分区数量，副本数
• 增加消费者数量
• 优化代码，降低生产者的发送速率以及提升消费者消费速率。
• 堆硬件资源

broker挂掉

解决方案：尝试重新启动宕机的 broker。在启动之前，确保检查并修复可能导致宕机的问题，如磁盘空间不足、内存问题等。监控集群状态：监控集群状态，确保宕机的 broker 已经重新加入集群，并且集群的健康状态恢复正常。

原因分析：

• 查看日志文件：在日志文件中查找与宕机相关的错误消息。这些消息可能包含有关宕机原因的信息，如网络连接问题、磁盘故障、内存不足等。
• 检查系统资源：如果发现资源不足或达到极限，可以考虑增加硬件资源或优化 Kafka 配置。
• 检查网络连接：使用命令行工具检查宕机 broker 与其他 broker 和 ZooKeeper 的网络连接是否正常。保证kafka-zookeeper可以相互通信。
• 检查topic/consumer组配置信息：

tail -100 ~/kafka/logs/server.log
kafka-topics.sh --describe --topic <topic_name> --bootstrap-server <broker_host>:<broker_port>

kafka-consumer-groups.sh --describe --group <consumer_group> --bootstrap-server <broker_host>:<broker_port>