Kafka如何保证「消息不丢失」，「顺序传输」，「不重复消费」，以及为什么会发生重平衡（reblanace） - 纪莫 - 博客园

如何保证消息不丢失

生产者到broker消息不丢失

通过设置acks参数来解决

acks=0:表示Producer请求立即返回，不需要等待Leader的任何确认。这种方案有最高的吞吐率，但是不保证消息是否真的发送成功。
acks =-1: 表示分区Leader必须等待消息被成功写入到所有的ISR副本(同步副本)中才认为Producer请求成功。这种方案提供最高的消息持久性保证，但是理论上吞吐率也是最差的。
acks=1: 表示Leader副本必须应答此Producer请求并写入消息到本地日志，之后Producer请求被认为成功。如果此时Leader副本应答请求之后挂掉了，消息会丢失。这个方案，提供了不错的持久性保证和吞吐。

broker到磁盘丢消息

Broker丢失消息是由于Kafka本身的原因造成的，kafka为了得到更高的性能和吞吐量，将数据异步批量的存储在磁盘中。消息的刷盘过程，为了提高性能，减少刷盘次数，kafka采用了批量刷盘的做法。即，按照一定的消息量，和时间间隔进行刷盘。这种机制也是由于linux操作系统决定的。将数据存储到linux操作系统种，会先存储到页缓存（Page cache）中，按照时间或者其他条件进行刷盘（从page cache到file），或者通过fsync命令强制刷盘。数据在page cache中时，如果系统挂掉，数据会丢失。

Kafka没有提供同步刷盘的方式。同步刷盘在RocketMQ中有实现，实现原理是将异步刷盘的流程进行阻塞，等待响应，类似ajax的callback或者是java的future。

如果broker发生故障，那么此时page cache的数据就会丢失，broker端可以设置刷盘的参数，比如多久刷盘一次，不过这个参数不建议去修改，最好的方案还是设置多副本，一个分区设置几个副本，当broker故障的时候，如果还有其他副本，那么数据就不会丢失。

消费者丢消息

Consumer消费消息有下面几个步骤：

• 接收消息

• 处理消息

• 反馈“处理完毕”（commited）

Consumer的消费方式主要分为两种：

• 自动提交offset，Automatic Offset Committing

• 手动提交offset，Manual Offset Control

Consumer自动提交的机制是根据一定的时间间隔，将收到的消息进行commit。commit过程和消费消息的过程是异步的。也就是说，可能存在消费过程未成功（比如抛出异常），commit消息已经提交了。此时消息就丢失了。

为了避免消息丢失，建议使用手动提交偏移量的方式，防止消息的业务逻辑未处理完，提交偏移量后消费者挂了的问题。

enable.auto.commit=false

如何保证消息不重复消费

什么情况下会导致消息被重复消费呢？

1、生产者，生产者可能重复推送了一条消息到kafka，例如：某接口未做幂等处理，接口中会发送kafka消息。
2、kafka，在消费者消费完消息后，提交offset时，kafka突然挂了，导致kafka认为此消息还未消费，又重新推送了该条消息，导致了重复消费消息。
3、消费者，在消费者消费完消息后，提交offset时，Consumer突然宕机挂掉，这个时候，kafka未接收到已处理的offset值，当Consumer恢复后，会重新消费此部分消息。
4、还有一种情况，Kafka 存在 Partition Balance 机制，会将多个 Partition 均衡分配给多个消费者。若 Consumer 在默认 5 分钟内未处理完一批消息，会触发 Rebalance 机制，导致 offset 自动提交失败，重新 Rebalance 后，消费者会从之前未提交的 offset 位置开始消费，从而造成消息重复消费。

那么我们该如何防止消息被重复消费呢

其实上面的1、2、3、4这些情况都可以用幂等机制来防止消息被重复消费。为消息生成 一个唯一标识，并保存到 mysql 或 redis 中，处理消息前先到 mysql 或 redis 中判断该消息是否已被消费过。

但是第4种情况，前提是要先优化消费端处理性能，避免触发 Rebalance，例如：采用异步方式处理消息、缩短单个消息消费时长、调整消息处理超时时间、减少一次性从 Broker 拉取的数据条数等。