Kafka消息丢失和消息重复的几种情况及解决方式

前言

kafka消息丢失会发生在Broker,Producer和Consumer三种中的任意一种。

---

Broker消息丢失：

Broker丢失消息是由Kafka自身原因造成的，也可以理解为由现有的操作系统组成方式造成的。kafka为了提高吞吐量和性能，采用异步批量的刷盘策略，也就是按照一定的消息量，和间隔时间进行刷盘。在之前讲解IO底层的文章中我们介绍过，我们将数据存储在Linux操作系统中，会先存储在也缓存中(Page Cache)中，之后由操作系统根据自己的策略进行刷盘或者通过fsync命令强制刷盘。数据在pageCache中，如果系统挂掉，数据就会丢失。pageCache到磁盘的更新操作是异步进行的。Page Cache中被修改的内存也(Dirty Page)，脏页在特定的时候被pdflush（Page Dirty Flush）的内核线程写入磁盘，写入时机和条件如下：

• 当空闲内存低于一个特定的阈值时，内核必须将脏页写回到磁盘，以便释放内存。
• 当脏页在内存中驻留时间超过一个特定阈值时，内核必须将超时的脏页写回到磁盘。
• 用户进程调用sync,fsync,fdatasync系统调用时，内核会执行相应的写回操作。

Broker配置刷盘机制，是通过fsync函数接管刷盘动作。从单个Broker来看，PageCahe会丢失数据。Kafka没有提供同步刷盘的方式，同步刷盘在RocketMq中有体现，实现原理就是将异步刷盘流程进行阻塞，等待刷到磁盘中再响应。也就是说，理论上，要完全让kafka保证单个broker不丢失消息是做不到的，只能通过调整刷盘机制的方式缓解这种情况。比如减少刷盘间隔，减少刷盘数据量大小。

为了解决单个broker数据丢失问题，kafka通过producer和brok