Kafka丢失数据问题优化总结以及重复消费原因分析（一）

数据丢失是一件非常严重的事情事，针对数据丢失的问题我们需要有明确的思路来确定问题所在，针对这段时间的总结，我个人面对kafka数据丢失问题的解决思路如下：

1. 是否真正的存在数据丢失问题

比如有很多时候可能是其他同事操作了测试环境，所以首先确保数据没有第三方干扰。

2. 理清你的业务流程，数据流向

数据到底是在什么地方丢失的数据，在Kafka之前的环节或者Kafka之后的流程丢失？比如Kafka的数据是由flume提供的，也许是flume丢失了数据，Kafka自然就没有这一部分数据。

3. 如何发现有数据丢失，又是如何验证的？

从业务角度考虑，例如：教育行业，每年高考后数据量巨大，但是却反常的比高考前还少，或者源端数据量和目的端数据量不符。

4. 定位数据是否在Kafka之前就已经丢失还是消费端丢失数据的

Kafka支持数据的重新回放功能(换个消费group)，清空目的端所有数据，重新消费。

如果是在消费端丢失数据，那么多次消费结果完全一模一样的几率很低。

如果是在写入端丢失数据，那么每次结果应该完全一样(在写入端没有问题的前提下)。

5. Kafka环节丢失数据

常见的Kafka环节丢失数据的原因有：

如果auto.commit.enable=true，当consumer fetch了一些数据但还没有完全处理掉的时候，刚好到commit interval出发了提交offset操作，接着consumer crash掉了。这时已经fetch的数据还没有处理完成但已经被commit掉，因此没有机会再次被处理，数据丢失。

网络负载很高或者磁盘很忙写入失败的情况下，没有自动重试重发消息。没有做限速处理，超出了网络带宽限速。kafka一定要配置上消息重试的机制，并且重试的时间间隔一定要长一些，默认1秒钟并不符合生产环境（网络中断时间有可能超过1秒）。如果磁盘坏了，会丢失已经落盘的数据。

单批数据的长度超过限制会丢失数据，报kafka.common.MessageSizeTooLargeException异常解决：

Consumer side:fetch.message.max.bytes- this will determine the largest size of a message that can be fetched by the consumer.
Broker side:replica.fetch.max.bytes- this will allow for the replicas in the brokers to send messages within the cluster and make sure the messages are replicated correctly. If this is too small, then the message will never be replicated, and therefore, the consumer will never see the message because the message will never be committed (fully replicated).
Broker side:message.max.bytes- this is the largest size of the message that can be received by the broker from a producer.
Broker side (per topic):max.message.bytes- this is the largest size of the message the broker will allow to be appended to the topic. This size is validated pre-compression. (Defaults to broker'smessage.max.bytes.)