kafka消息丢失解决方案

一条消息从生产到消费完成这个过程，可以划分三个阶段，为了方便描述，我给每个阶段分别起了个名字。

• 生产阶段: 在这个阶段，从消息在 Producer 创建出来，经过网络传输发送到 Broker 端。
• 存储阶段: 在这个阶段，消息在 Broker 端存储，如果是集群，消息会在这个阶段被复制到其他的副本上。
• 消费阶段: 在这个阶段，Consumer 从 Broker 上拉取消息，经过网络传输发送到 Consumer 上。

一、生产端数据丢失

kafka的ack机制：在kafka发送数据的时候，每次发送消息都会有一个确认反馈机制，确保消息正常的能够被收到。

ack=0时，生产者无需等待brokder的ack，一直发送消息
ack=1时，生产者接收到leader的ack信号，就会发送下一条数据
ack=-1时，生产者必须等到所有broker返回ack信号，才会发送下一条数据

当ack=0时，如果有一台broker挂掉，那么那台broker就会接收不到这条消息

当ack=1时，如果有一台follower挂掉，那么这台follower也会丢失这条消息，或者follower还未同步leader的数据，leader挂了，也会丢失消息。

1）如果是同步模式

ack机制能够保证数据的不丢失，如果ack设置为0，风险很大，一般不建议设置为0

producer.type=sync 
request.required.acks=1

2）如果是异步模式

通过buffer来进行控制数据的发送，有两个值来进行控制，时间阈值与消息的数量阈值，如果buffer满了数据还没有发送出去，如果设置的是立即清理模式，风险很大，一定要设置为阻塞模式

producer.type=async 
request.required.acks=1 
queue.buffering.max.ms=5000 
queue.buffering.max.messages=10000 
queue.enqueue.timeout.ms = -1 
batch.num.messages=200

结论：producer有丢数据的可能，但是可以通过配置保证消息的不丢失

二、存储端消息丢失

如何保证存储端的消息不丢失呢？ 确保消息持久化到磁盘。大家很容易想到就是刷盘机制。

刷盘机制分同步刷盘和异步刷盘：

• 生产者消息发过来时，只有持久化到磁盘，存储端Broker才返回一个成功的ACK响应，这就是同步刷盘。它保证消息不丢失，但是影响了性能。
• 异步刷盘的话，只要消息写入PageCache缓存，就返回一个成功的ACK响应。这样提高了MQ的性能，但是如果这时候机器断电了，就会丢失消息。

Broker一般是集群部署的，有master主节点和slave从节点。消息到Broker存储端，只有主节点和从节点都写入成功，才反馈成功的ack给生产者，这就是同步复制，它保证了消息不丢失，但是降低了系统的吞吐量。与之对应的就是异步复制，只要消息写入主节点成功，就返回成功的ack，它速度快，但是会有性能问题。

在kafka中避免broker宕机，可以设置多副本冗余的高可用机制

三、消费端数据丢失

auto.commit.enable=true，消费端自动提交offersets设置为true时，当消费者拉到消息之后还没有处理完而commit interval 提交间隔就到了，提交了offersets。这时consummer又挂了，重启后，从下一个offersets开始消费，之前的消息丢失了

四、小结

kafka数据丢失整体的解决方案：

1）设置消息应答重试机制，保证在生产端不会造成数据丢失

2）设置auto.commit.enable=false 消费端手动提交，确保消息真的被消费并处理完成