Kafka如何保证消息不丢失

Kafka的架构

Kafka是一个用来实现异步消息通讯的一个中间件，它的整个架构是由Producer、Consumer和Broker来组成。

所以对于Kafka如何去保证消息不丢失这个问题，可以从三个方面来回答。

1. Producer端

首先是Producer端，需要去确保消息能够到达Broker，并且能够实现消息的存储。

1.1 原因分析

在这个层面上有可能会出现网络问题导致消息发送失败。

1.2 解决方案

Producer默认是异步发送消息的，所以可以通过以下方式来避免消息丢失：

1. 把异步发送改成同步发送，这样producer就能实时知道消息发送的结果。
2. 添加异步回调函数来监听消息发送的结果，如果发送失败，可以在回调中重试。
3. Producer本身提供了一个重试参数retries，如果因为网络问题或者Broker故障导致发送失败，那么Producer会自动重试。

2. Broker端

Broker端需要确保Producer发送过来的消息是不会丢失的。

也就是说只需要去把这个消息持久化到磁盘就可以了。

2.1 原因分析

但是Kafka为了提升性能，采用了异步批量刷盘的实现机制，也就是说按照一定的消息量和时间间隔去刷盘。而最终刷新到磁盘这个动作是由操作系统来调度的，所以如果在刷盘之前系统崩溃了，就会导致数据丢失。

Kafa并没有提供同步刷盘的一个实现机制，所以针对这个问题需要通过Partition的副本机制和acks机制来解决。

2.2 解决方案

Partition副本机制，它是针对每个数据分区的高可用策略，每个Partition副本集会包含唯一的一个Leader和多个Follower。

Leader专门去处理事务类型的请求，而Follower负责同步leader的数据，那么在这样一个机制的基础上，Kafka提供了一个acks的参数，Producer
可以去设置acks参数去结合Broker的副本机制来共同保障数据的可靠性。

acks这个参数的值有几个选择：

1. acks=0,表示producer不需要等待Broker的响应，就认为消息就发送成功了。那么这种情况下会存在消息丢失。
2. acks=1,表示Broker中的Leader Partition收到消息之后不等待其他的Follower Partition的同步，就给Producer返回一个确认。这种情况下，假设Leader Partition挂了，就会存在数据丢失。
3. acks=-1,表示Broker中的Leader Partition收到消息之后，并且等待ISR列表中的follower同步完成，再去给Producer返回一个确认。那么这样一个配置是可以保证数据的一个可靠性的。

3. Consumer端

3.1 问题与解决

最后就是Consumer必须要能够消费这个消息，实际上只要producer和broker的消息可靠性得到保障。那么消费端是不太可能出现消息无法消费的问题的，除非是Consumer没有消费完这个消息，就已经提交了这样一个offset。但是即便是出现了这样一个情况，我们也可以通过重新调整offset的值来实现重新消费。

参考资料：Kafka如何保证消息不丢失