Kafka包括Producer、Broker、Consumer，因此从这三个方面分析。

Producer端

丢失原因：Kafka在Producer端的消息发送采用的是异步发送的方式(还有同步发送，但是同步发送会导致消息阻塞、需要等待)，丢失数据是因为消息没有到达Broker端，原因可能是网络波动导致没有回调和数据消息太大超出Broker承受范围，导致Broker拒收消息。

解决方法：更换调用方式，不使用异步发送，使用带回调通知函数的方法进行发送消息，网络波动和消息过大，可以调整Producer端重试次数和消息大小。

丢失原因：Kafka默认ack设置为1，会存在数据丢失问题。(ack为0也会存在丢数据问题)

解决方法：修改ack设置为-1。(可以结合幂等性做到Exactly Once)

Broker端

丢失原因：数据从Producer端push过来后，Broker端需要将数据持久化存储到磁盘中，消息存储是异步存储的，即按照一定的消息数量和间隔时间进行存储，数据会先放在 PageCache 中，如果在存储的时候Broker宕机，此时选举了一个落后Leader Partition 很多的 Follower Partition 成为新的Lerder Partition，那么落后的消息就会丢失。

解决方法：修改参数，设置有资格成为Leader的Follower(落后太久的不要)，设置分区数≥3(Leader宕机后可以有Follower补上)，设置消息至少要被写入成功到ISR多少个副本才算“已提交”。

Consumer端

丢失原因：Consumer拉取消息后最终处理完需要提交 Offset，提交Offset有以下三种方式：

1. 自动提交Offset。
2. 拉取消息后，先提交offset、再处理消息，如果此时处理消息的时候宕机，由于Offset已提交，Consumer重启后会从之前已提交的offset 下一个位置开始消费，之前未处理的消息不会被再次处理，对于Consumer来说消息已经丢失。
3. 拉取消息后，先处理消息、再提交Offset，如果此时在提交之前宕机，由于Offset没有提交，Consumer重启后会从上次的Offset重新拉取消息，不会丢失数据，但会出现重复消费的情况，这里只能业务自己保证幂等性。

方式2会导致数据丢失。

解决方法：使用先拉取消息、再处理消息、再提交offset的方法，并且设置参数 enable.auto.commit = false 使用手动提交位移的方式。