Kafka架构篇 - 多副本机制

这篇具有很好参考价值的文章主要介绍了Kafka架构篇 - 多副本机制。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

多副本机制

副本是分布式系统中对数据服务提供的一种冗余方式。为了对外提供可用的服务,往往会对数据服务进行副本处理。

  • 数据副本:在不同的节点持久化同一份数据,当某个节点存储的数据丢失时,可以从副本中读取数据,这是分布式系统解决数据丢失问题的最有效的手段。
  • 服务副本:多个节点提供相同的服务,每个节点都有能力接收外部的请求并进行相应的处理。

Kafka 从 0.8 版本开始为分区引入了多副本机制,通过增加副本数量提升数据容灾能力。同时,Kafka通过多副本机制实现了故障自动转移,在 Kafka 集群中的某个节点失效的情况下仍然保证服务可用。从生产者发出的一条消息,首先会被写入分区的 Leader 副本,然后需要等待 ISR 集合中的所有 Follower 副本同步完成之后才能被认为已经提交,接着更新分区的 HW,进而消费者可以消费到这条消息。

副本:相对于分区而言的,即副本是特定分区的副本。一个分区包含一个或者多个副本,其中一个为 Leader 副本,其余为 Follower 副本,各个副本位于不同的 broker 节点上。只有 Leader 副本对外提供服务,Follower 副本只负责与 Leader 副本进行数据同步。

AR:分区中的所有副本的统称。

ISR:所有与 Leader 副本保持同步状态的副本集合(Leader 副本也是 ISR 集合的一员)。

LEO:标识每个分区的最后一条消息的下一个位置,分区的每个副本都有自己的 LEO。

HW:ISR 中最小的 LEO,俗称高水位,消费者只能拉取到 HW 之前的消息。

失效副本

处于失效状态(同步失效或者功能失效)的副本会被剥离出 ISR 集合,失效副本对应的分区称为失效分区,即 under-replicated 分区

可以通过如下脚本命令查看失效分区:

bin/kafka-topics.sh --bootstrap-server 10.211.55.6:9092,10.211.55.7:9092,10.211.55.8:9092 --describe --topic thing1 --under-replicated-partitions
  • 功能失效:比如副本下线。

  • 同步失效:当 ISR 集合中的一个 Follower 副本滞后 Leader 副本的时间超过 broker 端参数 - replica.lag.time.max.ms(默认10000)就会判定为同步失效。 比如 Follower 副本的 I/O 开销过大导致 Follower 副本同步速度太慢,在一段时间内都无法追赶上 Leader 副本;频繁的 Full GC 导致进程卡住,在一段时间内没有向 Leader 副本发送同步请求。

ISR的伸缩与扩充

当检测到 ISR 集合中有失效副本时,就会收缩 ISR 集合。

ISR的收缩过程如下图:

Kafka架构篇 - 多副本机制

1、Kafka启动的时候会开启两个与 ISR 相关的定时任务 - “isr-expiration”、“isr-change-propagation”。

2、“isr-expiration” 任务 每隔 replica.lag.time.max.ms / 2 (默认5000ms)检测每个分区是否需要缩减其 ISR 集合,当检测到 ISR 集合中有失效副本时,就会收缩 ISR 集合。如果某个分区的 ISR 集合发生变更,则将变更后的数据记录到 ZooKeeper 的 /brokers/topics/<topic>/partition/<partition>/state 节点中。此外,还会将变更后的记录缓存到 isrChangeSet 中。

3、“isr-change-propagation” 任务 每隔 2500ms 检查 isrChangeSet,如果发现 isrChangeSet 中有 ISR 集合的变更记录,则在 ZooKeeper 的 “/isr_change_notification” 路径下创建一个以 “isr_change” 开头的持久顺序节点,并将 isrChangeSet 中的信息保存到这个节点中。

4、Kafka的控制器为 “/isr_change_notification” 添加一个 Watcher,当这个节点有子节点发生变化时,会触发 Watcher 的处理,通知控制器更新元数据并向它管理的 Kafka Broker 节点发送更新元数据的请求,最后删除 /isr_change_notification 路径下已经处理过的子节点。

Note:为了避免频繁触发 Watcher 的处理影响 Kafka 控制器、其它broker节点、ZooKeeper 的性能,Kafka 添加了限定条件,当检测到分区的 ISR 集合发生变化时,还需要检查以下两个条件:

(1)上一次 ISR 集合发生变化距离现在已经超过5s。

(2)上一次写入 ZooKeeper 的时间距离现在已经超过60s。

满足以上两个条件之一才可以将 ISR 集合的变化写入 ZooKeeper 中。

当 Follower 副本不断与 Leader 副本进行数据同步,并最终追赶上 Leader 副本(当前 Follower 副本的 LEO 大于等于 Leader 副本的 HW)时,Follower 副本就有资格进入 ISR 集合。ISR 集合的扩充过程与收缩过程相似,这里不再展开分析。

副本更新LEO、HW的过程

Kafka架构篇 - 多副本机制

生产者往 Leader 副本写入消息,消息被追加到 Leader 副本的本地日志,并且会更新 LEO。

Kafka架构篇 - 多副本机制

之后 Follower 副本向 Leader 副本拉取消息,并且带有自身的 LEO 信息。

Kafka架构篇 - 多副本机制

Leader 副本读取本地日志,返回给 Follower 副本对应的消息,并且带有自身的 HW 信息。

Follower 副本收到 Leader 副本返回的消息,会将消息追加到本地日志中,并且更新 LEO、HW。

Follower 副本更新 HW 的算法:比较当前 LEO 与 Leader 副本返回的 HW 的值,取较小值作为自己的 HW

Kafka架构篇 - 多副本机制

Follower 副本再次请求拉取 Leader 副本中的消息,并且带有更新后的 HW 的值。

Leader 副本收到 Follower 的请求后,选择最小的 LEO 作为 HW。

Kafka架构篇 - 多副本机制

Follower 副本收到 Leader 副本返回的消息,会接着将消息追加到本地日志中,并且更新 LEO、HW。

Leader Epoch 的引入

在 0.11.0.0 版本之前,Kafka 使用的是基于 HW 的同步方式。这种方式可能会出现 数据丢失 或者 Leader 副本和 Follower 副本数据不一致 的问题。

Kafka架构篇 - 多副本机制

Follower 副本在更新 LEO 为 2 和 更新 HW 为 2 之间存在一轮的 FetchRequest/FetchResponse。如果在这个过程中,Follower 副本宕机了,那么重启后会根据之前记录的 HW(读取 replication-offset-checkpoint 文件)进行日志截断,那么会导致 b 这条消息被删除。然后 Follower 副本再向 Leader 副本拉取消息,如果此时 Leader 副本宕机并且 Follower 副本被选举为新的 Leader,接着原来的 Leader 副本恢复后就会成为 Follower 副本,由于 Follower 副本的 HW 不能比 Leader 副本的 HW 高,所以还会进行一次日志截断,由此 b 这条消息就丢失了。或者原来的 Leader 副本无法恢复,b 这条消息也是会丢失的。

Kafka架构篇 - 多副本机制

如果 min.insync.replicas=1 的场景下,上述两个副本处于挂掉状态,Replica B 先恢复并成为 Leader 副本,接着写入消息 c 并更新 LEO、HW 为 2。此时 Replica A 也恢复过来了,成为 Follower 副本并且需要根据 HW 截断日志以及向 Leader 副本拉取数据,由于此时 Replica A 的 HW 也是 2,所以可以不做任何调整。如此一来,Replica A 和 Replica B 就会出现数据不一致的问题。

为了解决上述两个问题,Kafka 从0.11.0.0开始引入了 Leader Epoch 的概念,在需要截断数据的时候使用 Leader Epoch 作为参考依据。Leader Epoch 初始值为 0,代表 Leader 的纪元,每次 Leader 变更,该值都会加一。每个副本在本地的 leader-epoch-checkpoint 文件中记录 <LeaderEpoch => StartOffset> 信息。

  • 解决数据丢失问题:Follower 副本重启,先发送请求(包含 Leader Epoch 值)给 Leader 副本,如果 Leader 副本收到请求后发现当前的 Leader Epoch 与 Follower 传过来的 Leader Epoch 一致,则返回当前的 LEO;如果不一致,则 Leader 副本会查找 Follower 传过来的 Leader Epoch + 1 对应的 StartOffset 返回给 Follower 副本。Follower 副本根据 Leader 副本返回的 StartOffset 判断是否需要截断日志。

StartOffset:当前 Leader Epoch 下的写入的第一条消息的偏移量

Kafka架构篇 - 多副本机制

  • 解决数据不一致的问题:还是在 min.insync.replicas=1 的场景下,Replica A、Replica B 都处于挂掉的状态,Replica B 先恢复通过选举成为 Leader并更新 LE,然后写入 c 这条消息并更新 LEO、HW。这时 Replica A 恢复过来成为 Follower,向 Replica B 发送请求并携带自身的 LE。Replica B 接收到请求后,比较两者的 LE 发现不一致,然后返回 Replica B 当前 LE 对应的 StartOffset。Replica A 比较 Replica B 返回的 StartOffset 与自己的 LEO ,判断是否需要日志截断。

Kafka架构篇 - 多副本机制

Kafka架构篇 - 多副本机制文章来源地址https://www.toymoban.com/news/detail-475700.html

到了这里,关于Kafka架构篇 - 多副本机制的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【系统架构】分布式系统架构设计

    分布式系统是指由多个计算机节点组成的一个系统,这些节点通过网络互相连接,并协同工作完成某个任务。 与单个计算机相比,分布式系统具有更高的可扩展性、可靠性和性能等优势,因此广泛应用于大规模数据处理、高并发访问、分布式存储等领域。 分布式系统的设计

    2024年02月15日
    浏览(56)
  • 分布式系统架构设计之分布式缓存技术选型

    随着互联网业务的快速发展,分布式系统已经成为了解决大规模并发请求、高可用性、可扩展性等问题的重要手段。在分布式系统中,缓存作为提高系统性能的关键技术,能够显著降低数据库负载、减少网络延迟、提高数据访问速度。当面对大量并发请求时,如果每次都直接

    2024年02月03日
    浏览(119)
  • 分布式系统架构1

    目前比较成熟的分布式架构技术包括: J2EE, CORBA 和 .NET (本书于 2020.05 出版), 书重点讲述 J2EE, 一个由 Sun 公司推出的一项中间件技术 (或平台). 用于 简化 和 规范 多层分布式 企业 应用系统开发和部署 特点: 具有分布式的体系: 组件与服务器环境无关, 无需担心组件和资源的分布

    2024年01月22日
    浏览(62)
  • 【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下Saml协议的运作机制和流程模式

    传统上,企业应用程序在公司网络中部署和运行。为了获取有关用户的信息,如用户配置文件和组信息,这些应用程序中的许多都是为与公司目录(如Microsoft Active Directory)集成而构建的。更重要的是,通常使用目录存储和验证用户的凭据。例如,如果您使用在本地运行的Share

    2024年02月05日
    浏览(43)
  • Kafka架构篇 - 多副本机制

    副本是分布式系统中对 数据 和 服务 提供的一种冗余方式。为了对外提供可用的服务,往往会对 数据 和 服务 进行副本处理。 数据副本:在不同的节点持久化同一份数据,当某个节点存储的数据丢失时,可以从副本中读取数据,这是分布式系统解决数据丢失问题的最有效的

    2024年02月08日
    浏览(50)
  • 分布式系统共识机制:一致性算法设计思想

    这次以一个宏观的角度去总结 自己学习过的一致性算法。一致性算法的目标就是让分布式系统里的大部分节点 保持数据一致。 区块链中的共识算法,pow、pos这类就属于这个范围,但他们仅仅是在区块链领域内应用的,下面介绍一致性算法是在分布式系统中 应用广泛的,当然

    2023年04月16日
    浏览(56)
  • 分布式系统架构理论与组件

    在计算机发展的早期,一直都是集中式计算,计算能力依赖大型计算机。随着互联网的发展,繁重的业务需要巨大的计算能力才能完成,而集中式计算无法满足要求,大型计算机的价格也非常昂贵。分布式计算将任务分解成更小的部分,分配给多台计算机处理,这样可以节约

    2024年02月04日
    浏览(42)
  • 分布式系统架构设计之分布式数据存储的扩展方式、主从复制以及分布式一致性

    在分布式系统中,数据存储的扩展是为了适应业务的增长和提高系统的性能。分为水平扩展和垂直扩展两种方式,这两种方式在架构设计和应用场景上有着不同的优势和局限性。 水平扩展是通过增加节点或服务器的数量来扩大整个系统的容量和性能。在数据存储领域,水平扩

    2024年02月03日
    浏览(76)
  • 分布式系统架构设计之分布式数据存储的安全隐私和性能优化

    在前面分布式系统部分,有对安全性做过介绍,如前面所述,在分布式系统中,确保系统的安全性和隐私是至关重要的。安全性关注系统的防护措施,而隐私是关注用户的个人信息保护。 身份认证:确保用户和系统组件的身份是合法的,通过通过密码、令牌或证书实现 授权

    2024年02月02日
    浏览(61)
  • 【新星计划】Kafka分布式发布订阅消息系统

      目录 Kafka分布式发布订阅消息系统 1. 概述 1.1 点对点消息传递模式 1.2 发布-订阅消息传递模式 1.3 Kafka特点 1.4 kafka拓扑图 2. Kafka工作原理 2.1 Kafka核心组件介绍 2.2 Kafka工作流程分析 2.2.1 生产者生产消息过程 2.2.2 消费者消费消息过程 2.2.3 Kafka Topics 2.2.4 Kafka Partition 2.2.4 Kafka

    2024年02月08日
    浏览(46)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包