kafka 消费能力小小见解及解决方案

1.kafka 消费能力低的原因

kafka的速度是很快，所以一般来说producer的生产消息的逻辑速度都会比consumer的消费消息的逻辑速度快,查看topic情况发现：

MUC_EMP_CHANGE_NOTIFY

MUC_ORG

app_action

h5_action

topic的分区数partitions都是1 副本数replication-factor都是1，如下图

查看topic情况

./kafka-topics.sh --zookeeper 172.28.21.250:2181,172.28.21.249:2181,172.28.21.248:2181 --topic MUC_ORG --describe

查看消费情况，lag出现延迟1万

./kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --zookeeper 172.28.21.250:2181,172.28.21.249:2181,172.28.21.248:2181 --group mop-consumer --topic MUC_ORG

但是新创建的topic DEMO_KAFKA_SERVICE，如下图

./kafka-topics.sh --zookeeper 172.28.21.250:2181,172.28.21.249:2181,172.28.21.248:2181 --topic DEMO_KAFKA_SERVICE --describe

造成这种现象是server.properties修改了，新的server.properties增加了如下配置：

default.replication.factor=3

replica.fetch.max.bytes=5242880

delete.topic.enable=true

增加了分区和副本数，但是旧的topic还是之前配置，造成了消费能力还是一样低

2.解决方案（提高了partition的数量）

提高了partition的数量，从而提高了consumer的并行能力，从而提高数据的消费能力
对于单partition的消费线程，增加了一个固定长度的阻塞队列和工作线程池进一步提高并行消费的能力（暂不考虑）
使用spring-kafka，则把kafka-client的enable.auto.commit设置成了false，表示禁止kafka-client自动提交offset，因为就是之前的自动提交失败，导致offset永远没更新，从而转向使用spring-kafka的offset提交机制。并且spring-kafka提供了多种提交策略（暂不考虑）

1） 修改server.properties配置，添加如下配置，重启kafka（已配置）

default.replication.factor=3

replica.fetch.max.bytes=5242880

delete.topic.enable=true

2） 删除topic，kafka暂时不支持修改topic的副本数

 ./kafka-topics.sh --zookeeper 172.28.21.250:2181,172.28.21.249:2181,172.28.21.248:2181 --delete –topic topicname

3) 修复后的消费情况

4）进入 ./zookeeper-shell.sh 172.28.21.250:2181 查看group

ls /consumers

删除 lag偏差的group rmr /consumers/group1

5）重启 mx-apps 服务重新创建group

6) 查看 消费情况

./kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --zookeeper 172.28.21.250:2181,172.28.21.249:2181,172.28.21.248:2181 --group apps-consumer --topic MUC_ORG