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