Kafka3.0.0版本——Leader故障处理细节原理

这篇具有很好参考价值的文章主要介绍了Kafka3.0.0版本——Leader故障处理细节原理。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

一、服务器信息

  • 三台服务器
    原始服务器名称 原始服务器ip 节点
    centos7虚拟机1 192.168.136.27 broker0
    centos7虚拟机2 192.168.136.28 broker1
    centos7虚拟机3 192.168.136.29 broker2

二、服务器基本信息及相关概念

2.1、服务器基本信息

  • 首先,分别有3台服务器分别为broker0、broker1、broker2,其中一台为leader,2台follower服务器。每台服务器已经接收到数据,如下图所示:
    Kafka3.0.0版本——Leader故障处理细节原理,kafka,kafka

2.2、LEO的概念

  • LEO(Log End Offset):每个副本的最后一个offset,LEO其实就是最新的offset + 1
    Kafka3.0.0版本——Leader故障处理细节原理,kafka,kafka

2.3、HW的概念

  • HW(High Watermark ):高水位线,所有副本中最小的LEO+1。如下图中每个broker都有的数据是4(即最小的LEO为4),HW为最小的LEO+1,

    Kafka3.0.0版本——Leader故障处理细节原理,kafka,kafka文章来源地址https://www.toymoban.com/news/detail-681692.html

三、Leader故障处理细节

  • Leader发生故障之后,会从ISR中选出一个新的Leader,如下图所示:
    Kafka3.0.0版本——Leader故障处理细节原理,kafka,kafka
  • 为保证多个副本之间的数据一致性,其余的Follower会先将各自的log文件高于HW的部分截掉,然后从新的Leader同步数据。如下图所示:
    注意:这只能保证副本之间的数据一致性,并不能保证数据不丢失或者不重复。
    Kafka3.0.0版本——Leader故障处理细节原理,kafka,kafka

到了这里,关于Kafka3.0.0版本——Leader故障处理细节原理的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

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

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

相关文章

  • Kafka3.0.0版本——文件存储机制

    1.1、Topic 数据的存储机制的概述 Topic是逻辑上的概念,而partition是物理上的概念。 每个partition对应于一个log文件 ,该log文件中存储的就是Producer生产的数据。 Producer生产的数据会被不断追加到该log文件末端 ,为防止log文件过大导致数据定位效率低下, Kafka采取了 分片和 索引

    2024年02月09日
    浏览(39)
  • Kafka3.0.0版本——增加副本因子

    四台服务器 原始服务器名称 原始服务器ip 节点 centos7虚拟机1 192.168.136.27 broker0 centos7虚拟机2 192.168.136.28 broker1 centos7虚拟机3 192.168.136.29 broker2 centos7虚拟机4 192.168.136.30 broker3 2.1、先启动zookeeper集群 启动zookeeper集群 2.2、再启动kafka集群 启动kafka集群 3.1、增加副本因子的概述 在

    2024年02月09日
    浏览(34)
  • Kafka3.0.0版本——手动调整分区副本示例

    四台服务器 原始服务器名称 原始服务器ip 节点 centos7虚拟机1 192.168.136.27 broker0 centos7虚拟机2 192.168.136.28 broker1 centos7虚拟机3 192.168.136.29 broker2 centos7虚拟机4 192.168.136.30 broker3 2.1、先启动zookeeper集群 启动zookeeper集群 2.2、再启动kafka集群 启动kafka集群 3.1、手动调整分区副本的前提

    2024年02月11日
    浏览(56)
  • Kafka3.0.0版本——Broker( 退役旧节点)示例

    三台服务器 原始服务器名称 原始服务器ip centos7虚拟机1 192.168.136.27 centos7虚拟机2 192.168.136.28 centos7虚拟机3 192.168.136.29 centos7虚拟机4 192.168.136.30 分别启动4台zookeeper 再分别启动4台kafka brokers中的ids=0、1、2、3都存在,说明4台kafka启动正常,如下图: 查看kafka中的创建过的名称为

    2024年02月13日
    浏览(33)
  • Kafka3.0.0版本——生产者 数据去重

    1.1、至少一次 至少一次(At Least Once )的含义 生产者发送数据到kafka集群,kafka集群至少接收到一次数据。 至少一次的条件: ACK级别设置为-1 + 分区副本大于等于2 + ISR里应答的最小副本数量大于等于2 1.2、最多一次 最多一次(At Most Once )的含义 生产者发送数据到kafka集群,

    2024年02月01日
    浏览(38)
  • Kafka3.0.0版本——消费者(手动提交offset)

    1.1、手动提交offset的两种方式 commitSync(同步提交):必须等待offset提交完毕,再去消费下一批数据。 commitAsync(异步提交) :发送完提交offset请求后,就开始消费下一批数据了。 1.2、手动提交offset两种方式的区别 相同点:都会将本次提交的一批数据最高的偏移量提交。 不

    2024年02月09日
    浏览(44)
  • Kafka3.0.0版本——消费者(自动提交 offset)

    官网文档 参数解释 参数 描述 enable.auto.commi 默认值为 true,消费者会自动周期性地向服务器提交偏移量。 auto.commit.interval.ms 如果设置了 enable.auto.commit 的值为 true, 则该值定义了消费者偏移量向 Kafka 提交的频率,默认 5s。 图解分析 消费者自动提交 offset代码 消费者自动提交

    2024年02月09日
    浏览(37)
  • Kafka3.0.0版本——生产者数据有序与乱序

    单分区内,数据有序。如下图partion0、partion1、partion2分区内,各自分区内的数据有序。 2.1、kafka1.x版本之前保证数据单分区有序的条件 kafka在1.x版本之前保证数据单分区有序,条件如下: 2.2、kafka1.x版本及以后保证数据单分区有序的条件 未开启幂等性 开启幂等性 2.3、kafka1

    2023年04月27日
    浏览(43)
  • Kafka3.0.0版本——生产者如何提高吞吐量

    设置批次大小,batch.size 默认 16K。 设置等待时间,linger.ms 默认 0。 设置缓冲区大小,buffer.memory 默认 32M 设置压缩, compression.type 默认 none,可配置值 gzip、snappy、lz4 和 zstd。 代码 在kafka集群上开启 Kafka 消费者 在 IDEA 中执行代码,观察kafka集群控制台中是否接收到消息。 测试

    2023年04月10日
    浏览(40)
  • Kafka3.0.0版本——Broker(Zookeeper服务端存储的Kafka相关信息)

    1.1、先启动三台zookeeper集群服务,再启动三台kafka集群服务 启动三台zookeeper集群服务 启动三台kafka集群服务 1.2、使用PrettyZoo连接zookeeper客户端工具 PrettyZoo视化工具下载、安装、使用参考如下 Zookeeper可视化工具PrettyZoo的下载、安装链接:https://wwwxz.blog.csdn.net/article/details/1303

    2024年02月14日
    浏览(38)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包