2.Kafka的工作原理及数据丢失、数据重复问题

一、概述

   一个分布式消息中间件,基于zookeeper的分布式日志系统。

  简单来讲,就是一个存储系统,起一个缓冲作用。

  所谓的消息系统,就是将数据从一个地方传递到另一个地方。消息传递模式有两种:点对点传递模式,发

布-订阅模式。Kafka是一种发布-订阅模式。

 

 


 

二、特点

  1.解耦:

    消息系统在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。

  2.异步:

    支持用户将消息放入队列中,不立刻处理,需要的时候再去处理。

  3.削峰:

    使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。

    举个例子:A系统高并发状态下,可能会出现连接异常甚至崩溃的情况,这个时候我们能选择一个中间件,将所有客户的请求都放入消息队列中,A系统只需要从消息队列中拉取消息再做处理即可。

 

 


 

三、角色

2.Kafka的工作原理及数据丢失、数据重复问题

1.Topic消息队列:

  发布到Kafka集群的消息的类别。(就看作是一个个的消息队列名,用来找到对应的消息队列)。

  (1)Partition:topic中数据的具体管理单元。   

   一个topic 可以划分为多个partition,分布到多个 broker上管理;

 

   partition 中的每条信息都会被分配一个递增的id(offset);

 

   每个 partition 是一个有序的队列,各个 partition 间是无序的。换句话讲,如果topic有多个partition,消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下,需要将  

partition数目设为1。

 

   每个partition都可以有多个副本;

 

  分区对于 kafka 集群的好处是:实现topic数据的负载均衡。分区对于消费者来说,可以提高并发度,提高效率。

 

  (2)Broker:

  Kafka集群包含一个或多个服务器,服务器节点称为Broker。容纳多个topic的多个Partition。

  (3)Offset:

  消息在这底层存储中的索引位置,看作一个游标,通过它来确定消息的位置。

 

 2.Producer生产者:

   数据的发布者,发送消息给Broker。

 

3.Consumer消费者:

   消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。

 

4.Leader和Follower:

   每个partition有多个副本,其中有且仅有一个作为Leader,Leader是当前负责数据的读写的partition。Follower跟随Leader,所有写请求都通过Leader路由,数据变更会广播给所有Follower,Follower与Leader保持数据同步。如果Leader失效,则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢,leader会把这个follower从“in sync replicas”(ISR)列表中删除,重新创建一个

Follower。

 


 

四、数据丢失和数据重复问题:

在处理这两个问题之前,先来了解两个机制:ACK应答机制RETIRES延迟重发机制。

  ACK应答机制:

  在生产者端:broker往内存中写数据时,同时也会进行数据持久化操作,并根据你有多少个Leader和Follower,生成副本。内存先向Leader传输,完成后由leader向Follower进行备份。

此时就要考虑到备份的副本是否完成的问题。这里ACK应答机制可设三个参数:

  * 设 0 :不等broker同步完成的确认,继续发送下一条信息。不管数据的持久化,只要内存已处理完,直接传输下一条 (速度快 但不稳定)

  * 设 1 :等broker同步完成1次,就继续发送下一条信息。数据持久化只要Leade一完成,就进行下一次传输,不管Leader向Follower的备份 (速度较快 但如果落盘位置挂掉,没有备份数据)

  * 设 -1 :等broker全部同步完成,再发送下一条信息。等到数据持久化全部完成(包括备份的),才进行下一次的传输 (稳定,全部落盘才进行下一次的数据传输)

   注意:ACK机制只保证写入端的数据安全问题(不丢失),不会去管你数据是否重复等等。

RETIRES延迟重发机制:
  ACK应答机制(即便选择-1完全同步)只能保证数据全部备份下来,但不能确定备份数据的节点是否活跃,假如某台机器宕机,这时就需要重复机制,隔段时间再次重新发送一遍。

    注意:这里虽避免了数据丢失,但可能会造成数据重复。而且,如果重发后还无

响应,就会跳过这条数据继续下一次的发送,造成该数据丢失


所以,总结如下:

造成数据丢失的原因:

  1.  ACK应答机制设置为0,数据没有落盘保存,只是在内存中走了一遭,此时内存中的数据一旦没了,那就会造成数据丢失。

    设置为1,那么数据只会落盘保存到Leader上,Leader还没向Follower中同步时,此时Leader挂掉,数据丢失。

  2.  Offset设置为自动提交,他的机制是定时自动提交,如果提交时,数据还没处理完,但数据偏移量已经改变,下次读取的是下一个位置处的数据,而这部分未处理的数据所在节点一旦出现故障,数据也会丢失。

解决办法:

  ACK应答机制设为-1(或者all),并且关闭手动提交,提交时采用同步模式

prop.put( ProducerConfig.ACKS_CONFIG, "all");

prop.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG,"false");
consumer.commitSync();

 

 

 

 造成数据重复的原因:

  1.延迟重发机制下,节点出现故障导致主从数据同步未完成,他会重新发送一遍

  2.已经消费完成,但是offset还未提交,此时节点挂掉,下一次还是会从之前的offset处里数据,重复消费。

解决办法:

   1.手动维护offset(但仍有风险);

  2.加大kafka.consumer.session.timeout参数,避免错误关闭的情况。

  3.在下游选择Hbase或者Hive等进行去重。

  

 

 

 

 

上一篇:聊一聊tcp 拥塞控制 三


下一篇:820-彻底弄懂TCP协议