kafka出现丢失数据的情况分析:

1:Kafka出现丢失数据情况可以大致分为3种情况

  • kafka生产者原因
  • kafka服务器原因
  • kafka消费者原因

1:当producer发送信息时,如何确定该条信息是否被服务器确认，kafka中有3中策略可供选择(request.required.acks属性确定:就是ack机制)。

第一种(request.required.acks=0)，即生产者发送消息(每条消息发送会根据指定的partition分区规则发送到指定broker中)，不管broker(对于消息的接收与保存都是由各partition中的leader处理)有没有收到消息就不再发送(不管成功不成功)。如果这条消息在写入到磁盘之前挂掉了，那么这条消息也就丢失了。此时该集群的延迟性最小，但数据可靠性很差

第二种(request.required.acks=1),生产者发送消息指定partition的leader中，leader收到消息并保存成功后告知生产者该条数据以保存成功。当使用这种策略时，但leader返回消息成功此时leader挂掉了，kafka从ISR列表中选取另外的节点作为leader(此时原leader中还没把消息更新到新leader中)，所有leader中并没有这条数据，导致消费者无法消费数据，对于应用层面来说就是丢失数据。这是一个适中方案，保证一定的数据可靠性与延迟性

第三种(request.required.acks=-1,同时需要设置min.insync.replicas=设置ISR列表最小副本数默认为1),生产者发送消息指定partition的leader中,leader收到消息并转发到所有到ISR中，只有当所有ISR中所有replica确定写入数据成功后，leader才会返回到生产者告知消息保存成功。Kafka保证是只要始终有至少一个同步副本处于活动状态，提交的消息就不会丢失(The guarantee that Kafka offers is that a committed message will not be lost, as long as there is at least one in sync replica alive, at all times. 来自kafka官网)此时该集群中保证数据不会丢失,但整体的延迟性较高。

注:ISR(in-sync Replica) 即与leader中记录的保持数据同步的replica列表。kafka对于每个topic进行分区处理。每个分区在创建时都会指定拥有多少个replica(默认为1),broker会从这些中指定一个leader，该leader负责接收和处理，响应producer与consumer的请求，而replica作为备份与leader数据保存同步，当leader挂掉时作为备用leader保存该partition的可用。1:replica挂掉(zk检测不到该replica所在broker心跳)。2:replica中落后leader中消息太多此时leader会将该replica从ISR列表中剔除

2:kafka为了写入效率，数据先会写入到系统的页缓存中，然后由其它线程定时的将数据flush到磁盘中。这里有kafka提供了两种策略:1.log.flush.interval.messages=100该值表明当内存中消息数据达到了100条数，触发写入磁盘动作。2:log.flush.interval.ms=1000该值表明没经过1000ms即1s时触发写入磁盘动作。该策略会导致在内存中数据还没写到磁盘时，该broker挂掉了，此时会丢失内存中数据。解决方案,结合生产环境设置上述两值并且对于每个topic设定大于1的replica，并配合request.required.acks=-1，保证即使该broker挂掉内存数据丢失，但其它broker中仍然存在该批数据。

3:当consumer开始消费数据时(实际上是通过offset去broker去获取offset对应message,每组消费者都会自身保存消费最近的offset值,kafka0.8版本之前offset保存到zk中,而后续版本都保存到kafka名为__consumer_offsets,partition为50的topic中),kafka默认是自动提交offset到kafka集群中，由enable.auto.commit 属性来确定，enable.auto.commit=true时，开启自动提交offset。此时会出现的情况如下:若consumer消费一批offset,因消费过慢,offset实际已经提交,此时consumer挂了,那么当consumer重启之后读取的最新的offset已是被提交了offset，那么就存在了有些数据是未被真正消费完成的，针对这种情况我们可以enable.auto.commit=false，启用低级API。由业务系统自身来保存offset(可用事务数据库保存)。

 

kafka会出现重复数据情况分析:

  • kafka生产者原因
  • kafka消费者原因

1:生产者产生重复数据是由于当producer发出一条消息broker收到消息并数据落盘 ,但由于网络等其它因素导致发送端得到一个失败的响应或者一个超时的响应这时producer收到一个可恢复的Exception重试消息导致了消息重复重试。解决方案：第一种启动kafka的幂等性，修改enable.idempotence=true(默认为false)，并且必须要保证以下属性max.in.flight.requests.per.connection

2:从上面我们可以知道,consumer默认设置为定时(由auto.commit.interval.ms属性控制，默认为5000ms)自动提交offset,如果我们应用程序在5s内消费来一批offset,在快要提交的过程中，consumer挂了,那么当consumer重启之后,重新消费数据的时候就会出现重复数据消费的问题。解决方案:应用系统通过kafka提供的低阶API来维护offset或者下游应用程序做幂等来解决问题。

3:max.poll.interval.ms，该属性表示consumer两次poll消息之间最大延迟 如果在此期间为进行poll 则认为消费者失败 group将重新平衡将分区重新分配到另外成员。如果某一个consumer在进行消费的时候因为执行时间过长会导致，下次poll时间超过了该值，就会触发consumer重平衡策略，这个时候如果该消息没被ack，则就会出现重复消费的情况。(涉及到重分区都会出现该情况)

4:session.timeout.ms 该属性来检测消费者是否失效的超时时间消费者发送周期性的心跳以向代理指示其活跃性。 如果在会话超时到期之前代理没有收到任何检测信号，则代理将从组中删除此使用者并启动重新平衡 默认10s,在debug调试时建议将该值与max.poll.interval.ms调大 避免因为debug问题导致session超时，使得重平衡

 

对于数据重复消费问题，从它发源点开始进行处理，例如kafka提供的生产者幂等功能(只保证一个partition内的数据幂等，不包含数据内容的幂等)。consumer消费数据时幂等控制，幂等控制有多重方案，例如基于redis+数据库主键方案(兜底方案)来保证不重复消费。如果数据量过多也可采用布隆过滤器来做(有一定误差率)，肯定需要有兜底方案来保证

 

同分区数据乱序

生产者在发送消息时，默认是批量发送，即不是等待收到一条数据的确认回复后才发送下一条数据，当生产者没有收到数据的确认后默认会重试，这可能导致同一分区内出现数据乱序，解决方案：

max.in.flight.requests.per.connection=1

表示client收到回复之前不能再向同一个broker发送请求，但吞吐量会下降。

 

参考

https://blog.csdn.net/F_Hello_World/article/details/103082369
https://blog.csdn.net/w372426096/article/details/81282320