kafka副本机制之数据可靠性

一、概述

  为了提升集群的HA,Kafka从0.8版本开始引入了副本(Replica)机制,增加副本机制后,每个副本可以有多个副本,针对每个分区,都会从副本集(Assigned Replica,AR)中,选取一个副本作为Leader副本,所有读写请求都由Leader副本处理,其余的副本被称为Follwer副本,其会从Leader副本拉取消息更新到本地。因此,Follower更像是Leader的热备。

  一般情况下,同一个分区的多个副本会被均匀的分配到集群中的不同Broker上,当leader副本所在机器出现故障后会重新选举出新的leader实现故障转移。(针对副本如何分配以避免单台机器上leader过多导致集群负载均衡不均及多副本在同一机器上等问题,不再本文的讨论范围内,感兴趣的小伙伴,可以参考下kafka-reassign-partitions脚本)。

二、关键术语

  • 副本:kafka对消息的冗余存储以提升容灾能力,以分区为单位。
  • Leader副本:每个分区都有多个副本,针对每个分区,都有一个唯一的一个Leader副本,负责该分区的读写请求处理。
  • Follower副本:从Leader副本拉取数据,作为Leader副本的热备。
  • AR:(Assigned Replica)副本集合(Leader+Follower的总和)
  • ISR:(In-Sync Replica)同步副本集合,与leader副本消息镜像“相差”不多的副本集合,又称为“核心副本集”,与kafka 发送端的ACK的几种语义有关,后面会详聊(注意这个集合是动态的,是会剔除和新增的)。
  • HW:(High Watermark)是一个特殊的标记,与ISR有关,用以标记该分区中哪些消息被“commit”了,自然的对于消费者来说,它只能看到被commit了的消息,也就是HW之前的消息,当ISR集合中的副本都从Leader拉取了HW之后的某些消息后,Leader才会递增HW,因此HW的概念仅存在与Leader副本中,Follower不存在这个概念。
  • 有的小伙伴可能会问了,那为何要有这个标记呢,这个标记是为了从语义的角度保证即使Leader副本所在的机器宕机了,也不会出现消息丢失,后面会详细介绍。
  • LEO:(Log End Offset)每个分区都会有的一个标记,标示当前分区的最后一条消息(针对Leader就是Leader上的最后一条消息,针对某个Follower,就是当前该Follower的最后一条消息)

三、图解AR、ISR、HW、LEO

这里我们假设每个副本有三个分区,副本被剔除和加入ISR的临界条件为落后leader 三条消息,kafka判断是否符合ISR的条件有两个:

  • Follower落后leader多少条消息,落后超过配置值后将踢出ISR
  • Follwer多久没从leader同步消息,超过配置时间没拉取数据将从ISR踢出(kafka0.9后删除了该判断,a为唯一判断标准)。

下面我们用图来表达下上面的概念的关系:

  1. 时刻t1该分区的情况如下,此时ISR与AR一致(Leader,follower1,follower2),follower2 和 leader的消息一致,LEO都为4,follower1的LEO为2,因此leader的HW为2.
  2. .时刻t2 follower full gc.
  3. 时刻t3,leader接受producer发送来的2条消息5、6,此时发现Follower1已经落后了自己4条消息,将follower1踢出ISR集合
  4. 时刻t4,follower2 从leader拉取到5这条消息,更新HW值。
  5. 时刻t5,follower1 full gc完成后,发现自己已经落后了很多消息,开始从leader追消息,待消息不落后leader太多时,申请加入ISR中。

经过上面的图解分析后,我们来看下几个需要注意的点

  • ISR是AR的一个自己,并且是不断伸缩的,变化的条件为“是否落后太多的消息”
  • HW之前的消息代表被集群“commit”的消息,只有commit的消息才对client端(consumer以及request.required.acks为-1时的producer),在前面我们说过,这样能够使kafka在语义上支持不丢消息。我们从producer和consumer两个维度来分析:

  在这之前,我们先说下request.required.acks的取值范围(1、0、-1)
  1:leader成功就返回
  0:无需等待leader响应
  -1:ISR都成功才返回

  1. 从producer的角度:当producer将request.required.acks设置为-1时候,保证了消息已经在多个副本中存在了,此时即便leader挂了,这个消息还是存在的(leader选举会从ISR中选举出新的leader),那么假如ISR迟迟同步不成功怎么办呢?
  2. 从consumer的角度:如果没有HW,consumer拉取到最新的消息后,而此时leader宕机,很有可能新的leader中并没有此消息。

  当然不能保证消息永远不会丢,极端的情况下,如ISR中只有leader的时候(当然可以配置集群可用的最小核心副本集个数,但会极大的损失可用性),或者所有副本都宕机了(这个。。。没办法。),消息还是会丢的。

原文地址:https://www.cnblogs.com/ucarinc/p/8167728.html

时间: 2024-10-11 23:41:50

kafka副本机制之数据可靠性的相关文章

Kafka副本机制

一.什么是副本机制: 通常是指分布式系统在多台网络互联的机器上保存有相同的数据拷贝 二.副本机制的好处: 1.提供数据冗余 系统部分组件失效,系统依然能够继续运转,因而增加了整体可用性以及数据持久性 2.提供高伸缩性 支持横向扩展,能够通过增加机器的方式来提升读性能,进而提高读操作吞吐量 3.改善数据局部性 允许将数据放入与用户地理位置相近的地方,从而降低系统延时. 三.kafka的副本 1.本质就是一个只能追加写消息的日志文件 2.同一个分区下的所有副本保存有相同的消息序列 3.副本分散保存在

kafka数据可靠性深度解读

Kafka起初是由LinkedIn公司开发的一个分布式的消息系统,后成为Apache的一部分,它使用Scala编写,以可水平扩展和高吞吐率而被广泛使用.目前越来越多的开源分布式处理系统如Cloudera.Apache Storm.Spark等都支持与Kafka集成. 1 概述 Kafka与传统消息系统相比,有以下不同: 它被设计为一个分布式系统,易于向外扩展: 它同时为发布和订阅提供高吞吐量: 它支持多订阅者,当失败时能自动平衡消费者: 它将消息持久化到磁盘,因此可用于批量消费,例如ETL以及实

大数据:Hadoop(HDFS 的设计思路、设计目标、架构、副本机制、副本存放策略)

一.HDFS 的设计思路 1)思路 切分数据,并进行多副本存储: 2)如果文件只以多副本进行存储,而不进行切分,会有什么问题 缺点 不管文件多大,都存储在一个节点上,在进行数据处理的时候很难进行并行处理,节点可能成为网络瓶颈,很难进行大数据的处理: 存储负载很难均衡,每个节点的利用率很低: 二.HDFS 的设计目标 Hadoop Distributed File System(HDFS):源于Google 的 GFS 论文: 设计目标 分布式存储:根据需要,水平横向增加节点: 运行在普通廉价的硬

Kafka— —副本(均衡负载)

创建一个副本数为3的topic Now create a new topic with a replication factor of three: > bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 3 --partitions 1 --topic my-replicated-topic 使用describe topics指令,查看副本在集群中每一个broker的分布情况. Okay bu

论SparkStreaming的数据可靠性和一致性

转自: http://www.csdn.net/article/2015-06-21/2825011 摘要:眼下大数据领域最热门的词汇之一便是流计算了,而其中最耀眼的无疑是来自Spark社区的SparkStreaming项目. 对于流计算而言,最核心的特点毫无疑问就是它对低时的需求,但这也带来了相关的数据可靠性问题. 2Driver HA 由于流计算系统是长期运行.且不断有数据流入,因此其Spark守护进程(Driver)的可靠性至关重要,它决定了Streaming程序能否一直正确地运行下去.

Kafka副本管理—— 为何去掉replica.lag.max.messages参数

今天查看Kafka 0.10.0的官方文档,发现了这样一句话:Configuration parameter replica.lag.max.messages was removed. Partition leaders will no longer consider the number of lagging messages when deciding which replicas are in sync. 即replica.lag.max.messages参数被正式地移除了,现在topic

Kafka在高并发的情况下,如何避免消息丢失和消息重复?kafka消费怎么保证数据消费一次?数据的一致性和统一性?数据的完整性?

1.kafka在高并发的情况下,如何避免消息丢失和消息重复? 消息丢失解决方案: 首先对kafka进行限速, 其次启用重试机制,重试间隔时间设置长一些,最后Kafka设置acks=all,即需要相应的所有处于ISR的分区都确认收到该消息后,才算发送成功 消息重复解决方案: 消息可以使用唯一id标识 生产者(ack=all 代表至少成功发送一次) 消费者 (offset手动提交,业务逻辑成功处理后,提交offset) 落表(主键或者唯一索引的方式,避免重复数据) 业务逻辑处理(选择唯一主键存储到R

面向数据可靠性存储系统设计思想探讨

存储系统的设计门槛是比较高的,和计算系统存在的最大区别在于存储系统所承载的是数据,一旦系统出现故障,不仅业务的连续性得不到保障,更为重要的是用户数据将会造成丢失.计算节点发生故障,最多造成业务连续性中断,这是与存储系统相比在可靠性要求方面最大的区别. 十几年前刚刚接触存储系统的研发,当时没有觉得存储有多复杂,不就是把数据按照一定规则存放在磁盘中,并且实现一定的功能,例如数据保护RAID.数据复制Replication.数据快照Snapshot以及文件系统嘛.感觉存储系统中最复杂的是各种功能,设计

HDFS副本机制&负载均衡&机架感知&访问方式&健壮性&删除恢复机制&HDFS缺点

副本机制 1.副本摆放策略 第一副本:放置在上传文件的DataNode上:如果是集群外提交,则随机挑选一台磁盘不太慢.CPU不太忙的节点上:第二副本:放置在于第一个副本不同的机架的节点上:第三副本:与第二个副本相同机架的不同节点上:如果还有更多的副本:随机放在节点中: 2.副本系数 1)对于上传文件到HDFS时,当时hadoop的副本系数是几,那么这个文件的块副本数就有几份,无论以后怎么更改系统副本系数,这个文件的副本数都不会改变,也就是说上传到HDFS系统的文件副本数是由当时的系统副本数决定的