flume数据丢失与重复_Kafka精通：Producer发送数据丢失、重复、乱序原因及解决方案...

    生产环境对于生产者来说，Kafka集群发送消息经常会遇到消息丢失、重复、乱序等问题，下面我们来讲解一下出现这些问题的原因及解决方案。

1.我们知道Kafka为保障数据的可靠性，采用了多副本的存储机制

    假设一个Topic拆分为了3个Partition，分别是PartitionA，PartitonB，PartitionC，此时每个Partition都有2个副本。比如PartitionA有一个副本是leader，另外一个副本是follower，leader和follower两个副本是分布在不同机器上的。

    一般生产环境我们都会指定Topic的数据有3个副本，即使一台broker挂掉以后，数据也不会彻底丢失，因为其他broker还存在另外的副本数据。

2.副本数据是如何进行同步的呢？

    对于多个副本的topic来说，只有分区leader提供读写服务的，follower只是不停的尝试从leader拉取最新的数据到本地，不提供读写服务，跟leader数据保持同步的数据有哪些呢？就是通过ISRl来管理的。

    ISR全称是“In-Sync Replicas”,就是能跟首领副本基本保持一致的跟随副本，如果同步的速度太慢的话，就会被踢出ISR副本。

3.说一下Kafka的Producer端消息传递语义，由参数"acks"控制，分三种：

a.acks=all

    意味着当Producer发送消息时，leader接收到消息之后，还必须要求ISR列表里跟leader保持同步的那些follower都要把消息同步过去，才能认为这条消息是写入成功了,这种效率最低，但是可靠性最高。

b.acks=1：

    意味着当Producer发送消息时，leader接收到消息而且写入本地磁盘了，就认为成功了，不管他其他的follower有没有同步过去这条消息了,acks默认值为1。

c.acks=0：

    意味着当Producer发送消息时，producer发送一次就不再发送了，不管是否发送成功,这种情况下没有任何的确认，可能存在消息的丢失；这种效率最高，但是可靠性最低。

4.Producer端引起数据丢失、重复、乱序的原因及解决方案

1).Producer发送数据分为同步、异步两种模式，由参数producer.type控制，一般生产采用异步模式批量发送，提高Kafka系统的吞吐率。

a同步模式 producer.type = sync：

    当acks=0，不进行消息接收的确认，那么当网络异常时，就会造成数据丢失，一般生产不建议设置为0；

    当acks=1，在只有leader接收成功并发送ack确认后，leader宕机，副本没有同步完成，也会造成数据丢失；

    上面两种数据丢失，我们可以设置acks=all，保证produce 写入所有副本算成功,效率比较低。

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

‍

b.异步模式 producer.type = async：

    异步模式下的有个buffer，通过buffer来进行控制数据的发送，有两个值来进行控制，时间阈值与消息的数量阈值，如果buffer满了数据还没有发送出去，如果设置的是立即清理模式，风险很大，容易造成数据丢失。一般设置为阻塞模式：queue.enqueue.timeout.ms = -1表示后台消息queue积压到上限后将一直阻塞,直到queue空间释放；

producer.type = asyncrequest.required.acks=1queue.buffering.max.ms=6000queue.buffering.max.messages=10000queue.enqueue.timeout.ms = -1batch.num.messages=500

3).acks = all时，数据发送到 leader 后 ，数据发送到 leader 后 ，部分 ISR 的副本同步，leader 此时挂掉。比如 follower1 和 follower2 都有可能变成新的 leader, producer 端会得到返回异常，producer 端会重新发送数据，可能会造成数据重复,这种可通过幂等性和事务解决，后续会讲；

4).acks=all时，当isr列表为空，如果unclean.leader.election.enable为true，则会选择其他存活的副本作为新的leader，也会存在消息丢失的问题

可通过设置参数：

unclean.leader.election.enable=false

    这个参数在0.11.0之前其默认值为true，而之后的版本其默认值为false。意思是，在leader选举时是否在没有活着的ISR副本时从OSR中的最早follower选举，如果为true可能会造成数据的丢失；

5).异步发送消息时,有两条数据数据准备发送到相同的Partition,第一条消息写入失败,第二条消息写入失败,经过重试后第一批次写入成功,这时就会造成发送数据的乱序，这种情况我们可以通过设置参数进行限制:

参数：max.in.flight.requests.per.connection

    表示请求队列大小，默认5，请求队列中存放的是在发送途中的请求，包括：正在发送的请求和已经发送的但还没有接收到response的请求;请求队列满了，发送消息将会发生阻塞。也就是发往同一个node的最大未响应请求。设置此值是1，表示kafka broker在响应请求之前client不能再向同一个broker发送请求，这样便可以避免消息乱序。

    这是我总结的几种原因和处理方式，可能不全，后面如果有了新的领悟，我会进行更新和补充。

5.未完待续

    通过4的分析发现kafka在两端的默认配置都是at least once，可能重复，通过配置也不能做到exactly once，好像kafka的消息一定会丢失或者重复，在kafka 0.11.0.0版本之后，开始引入了幂等性和事务机制来解决上述问题，下一篇文章我将详细讲解幂等性原理及实现剖析。

---

扩充知识点：

1.Kafka发送数据过快，导致服务器网卡流量暴增。或磁盘过忙，出现丢包，造成。这时候我们采取以下措施：

     a.首先，对kafka进行限速；

     b.其次启用重试机制，使重试间隔变长；

     c.Kafka设置ack=all,即需要处于ISR(副本列表)的分区都确认，才算发送成功。

  如果觉得我的文章能帮到您，请关注微信公众号“大数据开发运维架构”，并转发朋友圈，谢谢支持！！！