Kafka 读写原理与存储结构

1. Kafka消息存储

我么知道,Kafka中一个Topic由多个partition组成。Kafka会为每个partition按照topicName-partitionNumber的方式创建文件夹(文件夹位于log.dir属性定义的目录下)。例如有一个名为report的topic,它拥有4个partition,那么Kafka会为其创建4个数据文件夹:

report-0
report-1
report-2
report-3

其中每个文件夹下都存储着对应partition的数据文件。

1.1 Segment

在物理上partition中的数据是存储在Segment文件中的。一个partition拥有多个Segment文件。每个Segment文件存储着partition中的部分数据。如下图所示:


Segment.JPG
  • Segment文件:Segment并不是一个单一的文件,它包括一个.index文件(存储数据索引)和一个.log(存储真实数据)文件。这两个文件一一对应。
  • Segment命名规则:partion全局的第一个segment从0开始,后续每个segment文件名为上一个全局partion的最大offset值。数值最大为64位long大小,19位数字字符长度,没有数字用0填充。

例如:

0000000000000000000.index
0000000000000000000.log (存储着offset在0~67892的数据)
0000000000000067892.index
0000000000000067892.log (存储着offset从67893开始的数据)

可以看到,.log数据文件按照offset序号命名,这样根据offset读取message时,可以快速定位到对应的.log文件。同时每一个.log文件都对应着一个同名的.index文件,它存储着对应的.log文件中数据的索引。如图所示:

index.JPG

.index文件中存储的格式为offset-address,例如3, 497代表着对应.log文件中offset为3的message,它的物理偏移地址为497。这儿的3代表着这条message在此log中的相对offset,而不是真实的message的offset。真实的message的offset应该是 368769 + 3,即.index文件名序号 + 相对offset。index文件中只存储相对offset的目的是节省存储空间。

因此,Broker根据offset查找message的流程如下:

  • 通过offset定位到对应的.index文件和.log文件
  • 查找对应的.index文件,找出该消息的物理偏移地址
  • 读取.log文件,根据物理偏移地址找到该条消息

2. Controller对象

Kafka集群中在启动时,会从Broker中选取一个成为Controller。Controller主要负责partition管理和replica管理。具体的选举方案是Broker自动向ZooKeeper注册宣布成为Controller,最先成功的Broker就成为了Controller对象。

下面是Controller的主要职责:

  • Broker 的上线、下线处理
  • 新创建的 topic 或已有 topic 的分区扩容,处理分区副本的分配、leader 选举
  • topic 删除、副本迁移、leader 切换等处理

客户端创建一个topic时,只需要和zookeeper通信,在对应的znode节点新建一个子节点即可。但是有了topic,还需要分配partition和replica,还要选出partition的leader,以及ISR(In-sync replicas)等,而这些工作,都是由controller来完成。

Controller创建partition和replica的过程如下:

  1. Controller 在 ZooKeeper 的 /brokers/topics 节点上注册 watcher,当检测到新的topic 被创建,则 controller 会从 /brokers/ids 读取当前所有可用的 broker 列表,为这个topic创建partition和replica对象。
  2. 对于每一个partition,从分配给该 partition 的所有 replica中任选一个可用的 broker 作为新的 leader,并将其他broker设置为ISR(In-sync replicas)
  3. 将新的 leader 和 ISR 写入 /brokers/topics/[topic]/partitions/[partition]/state

从上述的流程可以看出,Controller利用了zookeeper的watcher机制,动态监听topic节点的改变,从而进行分配partition和replica,选择leader,设置ISR并将这些信息存储到到zookeeper中。

3. Kafka replica机制

Leader会维护一个与其保持同步的Replica列表,该列表称为ISR(in-sync Replica)。如果一个Follower复制的Offset落后于Leader太多(落后数量上限由replica.lag.max.messages决定),或者超过一段时间内未发起数据复制请求(由replica.lag.time.max.ms决定),Leader会将该Follower从ISR中移除。

Producer在向某个partition写入一条消息时,先通过 Metadata (通过 Broker 获取并且缓存在 Producer 内) 找到该 Partition 的Leader。然后只向Leader发送消息写入的请求。之后Leader会将消息写入本地log(但不commit),之后每个Follower都从Leader pull数据。Follower在收到该消息并写入其Log后,向Leader发送ACK。一旦Leader收到了ISR中的所有Replica的ACK,该消息就被认为已经commit了,Leader将增加HW(high watermark,表示已经commit的消息的位置,只有Offset小于HW的消息才会暴露给Consumer消费)表示该消息提交成功。

4. Producer写消息

因此,Producer写一条消息的流程如下:

  1. Producer查询ZooKeeper,获得对应partition的leader
  2. Producer向该leader写一条消息,Leader收到后写入本地
  3. 该Leader的follwer会持续的从leader处pull消息,收到后写入本地,然后返回ack给leader
  4. leader收到ISR中所有的follower的ack消息后,返回ack消息给producer

上述流程针对于配置了ack = all的Producer,如果ack = 1,那么leader就不会等待follower的应答而直接返回ack给Producer。这两种方式也被称为Synchronous replication和Asynchronous replication。

5. Kafka如何选举Leader

最简单最直观的方案是,所有 Follower 都在 ZooKeeper 上设置一个 Watch,一旦 Leader 宕机,其对应的 ephemeral znode(临时节点) 会自动删除,此时所有 Follower 都尝试创建该节点,而创建成功者(ZooKeeper 保证只有一个能创建成功)即是新的 Leader,其它 Replica 即为 Follower。

但是该方法会有 3 个问题:

  • split-brain 这是由 ZooKeeper 的特性引起的,虽然 ZooKeeper 能保证所有 Watch 按顺序触发,但并不能保证同一时刻所有 Replica“看”到的状态是一样的,这就可能造成不同 Replica 的响应不一致
  • herd effect 如果宕机的那个 Broker 上的 Partition 比较多,会造成多个 Watch 被触发,造成集群内大量的调整
  • ZooKeeper 负载过重 每个 Replica 都要为此在 ZooKeeper 上注册一个 Watch,当集群规模增加到几千个 Partition 时 ZooKeeper 负载会过重。

Kafka 0.8 的 Leader Election 方案解决了上述问题,它在所有 broker 中选出一个 controller,所有 Partition 的 Leader 选举都由 controller 决定。controller 会将 Leader 的改变直接通过 RPC 的方式(比 ZooKeeper Queue 的方式更高效)通知需为为此作为响应的 Broker。同时 controller 也负责增删 Topic 以及 Replica 的重新分配。

参考文章

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,829评论 1 331
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,603评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,846评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,600评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,780评论 3 272
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,695评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,136评论 2 293
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,862评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,453评论 0 229
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,942评论 2 233
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,347评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,790评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,293评论 3 221
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,839评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,448评论 0 181
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,564评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,623评论 2 249

推荐阅读更多精彩内容