kafka leader-epoch-checkpoint 文件结构

最新推荐文章于 2024-05-17 08:50:31 发布
最新推荐文章于 2024-05-17 08:50:31 发布
阅读量1.8k 收藏 6
点赞数 2
文章标签： kafka
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/HFUT_SIAS/article/details/120083611
版权

kafka partition files

引言

kafka的每个partition下都有以下5类文件

# 其中数字123456只是举个栗子
00000000000000123456.index
00000000000000123456.log
00000000000000123456.snapshot
00000000000000123456.timeindex
leader-epoch-checkpoint

下面根据我的查阅资料和理解，总结以下各个文件结构。其中index、log、timeindex文件是二进制文本，可以使用如下kafka工具查看内容。checkpoint文件可以直接查看

bin/kafka-run-class.sh kafka.tools.DumpLogSegments --files 00000000000000000000.log

index

TODO

log

TODO

snapshot

snapshot:是kafka对幂等型或者事务型producer所生成的快照文件。

#snapshot打开是如下字符，未知具体含义
HgK

timeindex

TODO

leader-epoch-checkpoint

0 #版本号
1 #下面的记录行数
29 2485991681 #leader epoch ，可以看到有两位值（epoch，offset）。
## epoch表示leader的版本号，从0开始，当leader变更过1次时epoch就会+1
## offset则对应于该epoch版本的leader写入第一条消息的位移。可以理解为用户可以消费到的最早数据位移。与kafka.tools.GetOffsetShell --time -2获取到的值是一致的。

文章参考及引用

  1. kafka Log存储解析以及索引机制
  2. Kafka水位(high watermark)与leader epoch的讨论
  3. 尝试深入理解Kafka的工作特性
别逗，写BUG呢
关注
  • 2
    点赞
  • 踩
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Kafka可靠性之HW与Leader Epoch
daima_caigou的博客
11-06 1627
《深入理解Kafka：核心设计与实现原理》是基于2.0.0版本的书 在这本书中，终于看懂了笔者之前提过的几个问题 准备知识 1、leader里存着4个数据：leader_LEO、leader_HW、remote_LEO集合、remote_HW集合 2、follower里只保存自身的：follower_LEO、follower_HW HW和LEO更新过程 假设： 1个leader 和 2个follower 此时：leader_LEO = 5、leader_HW = 0、所有follower.
kafka-schema-registry-client-6.2.2.jar
04-25
mvn install:install-file -DgroupId=io.confluent -DartifactId=kafka-schema-registry-client -Dversion=6.2.2 -Dfile=/root/kafka-schema-registry-client-6.2.2.jar -Dpackaging=jar 官网下载地址 packages....
kafka 请求 OffsetForLeaderEpoch 处理、epoch机制、副本截断
这个人很懒什么都没有~
03-01 1036
2、如果消息写入了follower副本B，则follower副本B的LEO与leader副本的LEO是一致的，对应的offset是最新的，即使此后follow副本B宕机也不受影响。这个LastOffset有两种可能，一种是比follower发送的请求中的Leader Epoch大1的开始offset，另一种是如果当前leader epoch与请求中的leader epoch相等，那么就返回当前leader的LEO。而在主副本处理请求时，请求中是携带了 Controller 分配的 epoch 值的。
Kafka-集群管理者（Controller）选举机制、任期（epoch）机制
最新发布
喻师傅的学习笔记
05-17 1238
Kafka-集群管理者（Controller）选举机制、任期（epoch）机制
Kafka 系统的 CAP 保证（HW，Leader-Epoch）
PAIN的博客
08-09 417
为了解决 HW 更新时机是异步延迟的，Kafka 引入了 leader epoch 机制；在每个副本日志目录下都创建一个 leader-epoch-checkpoint 文件，用于保存 leader 的 epoch 信息，。它的格式为 (epoch offset)，epoch 指的是 leader 版本，它是一个单调递增的一个正整数值，每次 leader变更，epoch 版本都会 +1，offset 是每一代 leader 写入的第一条消息的位移值，比如：(0,0)(1,300)
kafka2.2源码分析之leader epoch
lzf的博客
12-03 1339
概述 Kafka使用HW值来决定副本备份的进度，而HW值的更新通常需要额外一轮FETCH RPC才能完成，故而这种设计是有问题的。它们可能引起的问题包括： 备份数据丢失 备份数据不一致 Kafka 0.11版本之后引入了leader epoch来取代HW值。Leader端多开辟一段内存区域专门保存leader的epoch信息，这样即使出现上面的两个场景也能很好地规避这些问题。 Epoch...
Kafka核心原理
hermi0ne的博客
12-01 791
综述 1. Kafka 性能高的原因 日志文件追加写 文件写到内核缓冲区 零拷贝：从 broker 到 consumer Ⅱ. Broker 2.1 日志模块 2.1.1 日志文件 Kafka 日志在磁盘上的组织架构如下图所示： Kafka 日志对象由多个日志段对象组成，而每个日志段对象会在磁盘上创建一组文件，包括： 消息日志文件（.log） 位移索引文件（.index） 时间戳索引文件（.timeindex） 已中止（Aborted）事务的索引文件（.txnindex）。 一个 Kafka 主题
kafka-eagle-bin-2.1.0.tar.gz
07-05
kafka-eagle-bin-2.1.0.tar.gz 2022年7月份下载，最新版
kafka-schema-registry-client-3.2.0.jar
12-11
kafka-schema-registry-client-3.2.0.jar包，亲测可用，在aliyun仓库内找不到，可以下载此jar包来进行手动安装
kafka-2.13-3.4.0.tgz
02-10
Kafka是一种高吞吐量的分布式发布订阅消息系统
kafka-schema-registry-client-3.3.1.jar
12-11
kafka-schema-registry-client-3.3.1.jar包，在aliyun 仓库内无法下载，可以下载此jar包然后手动安装
kafka学习笔记（一）--脑裂
weixin_44988779的博客
11-26 1609
我知道你想裂，但你先别裂。
Kafka中主题和分区的概念
peihj的博客
09-08 1918
主题Topic可以理解成是一个类别的名称。主题-topic在kafka中是一个逻辑的概念，kafka通过topic将消息进行分类。不同的topic会被订阅该topic的消费者消费。但是有一个问题，如果说这个topic中的消息非常非常多，多到需要几T来存，因为消息是会被保存到log日志文件中的。为了解决这个文件过大的问题，kafka提出了Partition分区的概念。Kafka 中的消息以主题为单位进行归类，生产者负责将消息发送到特定的主题（发送到 Kafka。
Kafka基础入门篇
架构师小秘圈
11-16 143
1kafka简介 Kafka 是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用与大数据实时处理领域。其主要设计目标如下： 以时间复杂度为O(1)的...
深入理解Kafka
大数据
05-19 547
一、概述 Kafka是一个分布式的基于发布、订阅的消息系统，有着强大的消息处理能力，相比与其他消息系统，具有以下特性： 快速数据持久化，实现了O(1)时间复杂度的数据持久化能力。 高吞吐，能在普通的服务器上达到10W每秒的吞吐速率。 高可靠，消息持久化以及副本系统的机制保证了消息的可靠性，消息可以多次消费。 高扩展，与其他分布式系统一样，所有组件均支持分布式、自动实现负载均衡，可以快速便捷的扩容系统。 离线与实时处理能力并存，提供了在线与离线的消息处理能力。 正是因其具有这些的优秀特性而广泛用于
flink1.15消费kafka之checkpoint 一
yiweiyi329的博客
07-10 2174
flink1.15源码实践
Kafka 分区
Aeroever的博客
04-24 102
每一个分区都是一个有序、不可变的消息序列，后续新来的消息会源源不断、持续追加到分区的后面，这相当于一种结构化的提交日志（类似于Git的提交日志）分区中的每一条消息都会被分配一个连续的id 值（即 offset）, 该值用于唯一标识分区中的每一条消息。分区中的消息是存储到日志中的，而且同一个分区中的消息数据是按照发送顺序严格有序的。分区在逻辑上对应的日志，但生产者将消息写入分区中时， 实际上写到分区所对应的日志当中。而日志可以看作是一种逻辑上的概念，它对应于磁盘上的一个目录。
kafka日志分段（.log文件）及日志文件索引机制（偏移量索引、时间戳索引）
liu_feng_zi_的专栏
03-01 5143
Kafka版本：2.2.1 环境：CDH 日志分段(segment) 格式 在kafka数据存储的目录下，进入topic文件目录，可以看到多个文件，如下，从文件名可以看出，.log、.index、.timeindex文件一一对应： -rw-r--r--. 1 kafka kafka 245432 Feb 25 13:01 00000000000000000000.index -rw-r--r--. 1 kafka kafka 909769306 Feb 25 11:31 0000000000000.
【kafka原理】kafka Log存储解析以及索引机制
热门推荐
石臻臻的杂货铺(szzdzhp001)
10-26 1万+
本文设置到的配置项有 名称 描述 类型 默认 num.partitions topic的默认分区数 int 1 log.dirs 保存日志数据的目录。如果未设置，则使用log.dir中的值 string /tmp/kafka-logs offsets.topic.replication.factor offset topic复制因子（ps：就是备份数，设置的越高来确保可用性）。为了确保offset topic有效的复制因子，第一次请求offset topic时，活的broker的数量
kafka leader epoch 机制
10-15
Kafka leader epoch 机制是 Kafka 用来解决数据一致性问题的一种机制。在 Kafka 中，每个分区都有一个 leader 节点，负责处理该分区的读写请求。当 leader 节点发生故障时，Kafka 需要选举一个新的 leader 节点来...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值