Kafka中的消息是否会丢失和重复消费（转）

在以前的基础上，基本搞清楚了Kafka的机制及如何运用。这里思考一下：Kafka中的消息会不会丢失或重复消费呢？为何呢？

        要肯定Kafka的消息是否丢失或重复，从两个方面分析入手：消息发送和消息消费

一、消息发送

         Kafka消息发送有两种方式：同步（sync）和异步（async），默认是同步方式，可经过producer.type属性进行配置。Kafka经过配置request.required.acks属性来确认消息的生产：

0---表示不进行消息接收是否成功的确认；

1---表示当Leader接收成功时确认；

-1---表示Leader和Follower都接收成功时确认；

综上所述，有6种消息生产的状况，下面分状况来分析消息丢失的场景：

（1）acks=0，不和Kafka集群进行消息接收确认，则当网络异常、缓冲区满了等状况时，消息可能丢失；

（2）acks=一、同步模式下，只有Leader确认接收成功后但挂掉了，副本没有同步，数据可能丢失；

二、消息消费

        Kafka消息消费有两个consumer接口，Low-level API和High-level API：

Low-level API：消费者本身维护offset等值，能够实现对Kafka的彻底控制；

High-level API：封装了对parition和offset的管理，使用简单；

若是使用高级接口High-level API，可能存在一个问题就是当消息消费者从集群中把消息取出来、并提交了新的消息offset值后，还没来得及消费就挂掉了，那么下次再消费时以前没消费成功的消息就“诡异”的消失了；    

解决办法：

        针对消息丢失：同步模式下，确认机制设置为-1，即让消息写入Leader和Follower以后再确认消息发送成功；异步模式下，为防止缓冲区满，能够在配置文件设置不限制阻塞超时时间，当缓冲区满时让生产者一直处于阻塞状态；

        针对消息重复：将消息的惟一标识保存到外部介质中，每次消费时判断是否处理过便可。

        

Kafka的Leader选举机制

        Kafka将每一个Topic进行分区Patition，以提升消息的并行处理，同时为保证高可用性，每一个分区都有必定数量的副本 Replica，这样当部分服务器不可用时副本所在服务器就能够接替上来，保证系统可用性。在Leader上负责读写，Follower负责数据的同步。当一个Leader发生故障如何从Follower中选择新Leader呢？

        Kafka在Zookeeper上针对每一个Topic都维护了一个ISR（in-sync replica---已同步的副本）的集合，集合的增减Kafka都会更新该记录。若是某分区的Leader不可用，Kafka就从ISR集合中选择一个副本做为新的Leader。这样就能够容忍的失败数比较高，假如某Topic有N+1个副本，则能够容忍N个服务器不可用。

        若是ISR中副本都不可用，有两种处理方法：

（1）等待ISR集合中副本复活后选择一个可用的副本；

（2）选择集群中其余可用副本；

具体可参考：http://www.jasongj.com/2015/04/24/KafkaColumn2/————————————————版权声明：本文为CSDN博主「行者小朱」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处连接及本声明。原文连接：https://blog.csdn.net/u012050154/article/details/78592854