1：kafka问题总结

1：消费者消费消息失败

查看topic的副本同步机制是否一致

kafka-topics.sh --describe --zookeeper hdp01:2181,hdp02:2181,hdp03:2181 --topic kafka_test

HW俗称高水位，HighWatermark的缩写，取一个partition对应的ISR中最小的LEO作为HW，consumer最多只能消费到HW所在的位置。
另外每个replica都有HW,leader和follower各自负责更新自己的HW的状态。对于leader新写入的消息，consumer不能立刻消费，
leader会等待该消息被所有ISR中的replicas同步后更新HW，此时消息才能被consumer消费。这样就保证了如果leader所在的broker
失效，该消息仍然可以从新选举的leader中获取。对于来自内部broker的读取请求，没有HW的限制

2：分区数据倾斜

topic重建，保证分区均衡

3：消费异常：Error sending fetch request to node 3: org.apache.kafka.common.errors.DisconnectException

这是发生在消费kafka数据时的info级别异常信息，可能影响消费速度。

• 1：一般排查消费者和kafka集群间的网络信息，是否有丢包延迟过大等信息。ping kafka_ip
• 2：查看消费过程书否存在数据积压，数据处理过程或者网络通信是否超过了session.timeout.ms会话时间，超过会话时间会导致重平衡过程，原有的请求信息可能已经发生了变化，即消费者订阅的分区信息发生了变化，无法获取分区信息了，所以导致的不能发送消费请求。
  解决：增加session.timeout.ms时间，可以有效延长触发reblance。增加request.timeout.ms，设置合适的max.poll.records值。
  request.timeout.ms为组协调组向kafak发送心跳的时间，证明消费者组中的消费者保持活动状态，三次请求后判定消费者离线触发重平衡机制。所以request.timeout.ms时间建议为不超过session.timeout.ms的1/3且必须不能超过session.timeout.ms。
  max.poll.records：设置一次poll最大消息记录数，避免poll的数据一直消费不完，超过session.timeout.ms时间触发relance。

4：消费异常：java.lang.IllegalStateException: No current assignment for partition topic

原因：同一groupid在消费同一topic导致额偏移量问题。
解决：停止程序修改groupid

5：生产或消费单条大记录失败

生产时：，Kafka客户端会先比较配置项“max.request.size ”值和本次写入数据大小，若写入数据大小超过此配置项“max.request.size ”的缺省值，则抛出上述异常。

• 解决：max.request.size 调大 props.put(“max.request.size”, “5252880”);
• 配置文件server.properties中message.max.bytes调大

消费时：Kafka客户端会比较待读取数据大小和配置项“max.partition.fetch.bytes”值，若超过此配置项值，则抛出上述异常。
解决：props.put(“max.partition.fetch.bytes”,“5252880”);

6：Kafka集群节点内多磁盘数据量占用高处理办法

Kafka流式集群节点内有多块磁盘，由于分区不合理及业务原因导致某几个磁盘的使用量很高。当达到100%时就会造成kafka不可用。
df -h查看磁盘利用率

• 需要提前干预处理磁盘数据，全局的log.retention.hours修改需要重启服务。为了不断服，可以将数据量大的单个topic老化时间根据需要改短。
• 设置单个topic的老化时间：kafka-topics.sh --zookeeper <ZooKeeper集群业务IP>:2181/kafka --alter --topic kktest --config retention.ms=1000000