Kafka之Broker原理
1. 日记数据的存储1.1 Partition
1. 为了实现横向扩展，把差别的数据存放在差别的 Broker 上，同时降低单台服务器的访问压力，我们把一个Topic 中的数据分隔成多个 Partition 2. 每个 Partition 中的消息是有序的，顺序写入，但是全局不肯定有序 3. 在服务器上，每个 Partition 都有一个物理目录（ TopicN ）后面的数字代表分区 https://img-blog.csdnimg.cn/direct/34f69f77ee1540a1af84b21d2e183775.png
1.2 Replica副本
1. 为了提高分区的可靠性， Kafka 计划了副本机制 2. 副本数必须小于便是节点数，而不能大于 Broker 的数量 3. Leader 对外提供读写服务， Follower 唯一的任务就是从 Leader 异步拉取数据 https://img-blog.csdnimg.cn/direct/3173942ee60b4a898fdd6862edabd654.png
1.3 Segment段
1. 为了防止Log不停追加导致文件过大，导致检索消息效率变低，一个Partition又 被划分成多个Segment来组织数据.
在这里会有3个配置，也就是log的阈值配置。什么时候下进行分段
[*] log.segment.bytes ：根据日记文件大小
[*] log.roll.hours 、 log.roll.ms ：根据时间戳差值 log.index.size.max.bytes：根据索引文件大小
每一个segment都是由一个log文件和2个index文件组成的,此中时间戳索引的创建方式可以自定义的实行createTime或LogAppendTime.默认是creareTime
https://img-blog.csdnimg.cn/direct/807e1b708336456a95194b232a6f7c5e.png
1.4 Sparse Index(希罕索引)
索引文件的检察可以通过以下命令进行检察
https://img-blog.csdnimg.cn/direct/805216cdf7664a338356fa45d8f7e91b.png
kfaka索引文件中记录的Offset不是连续的，而是采用了希罕索引。根据配置的大小，希罕索引记录的是从Log中的哪个位置开始检索，好比配置的是4kb，则当log文件中向下存储的数据达到4kb的话，就会记录一个索引值
https://img-blog.csdnimg.cn/direct/f6bc1836527f46258c36ec3403477a3d.png
1.5 分区副本在Broker上的分布
创建一个topic
./kafka-topics.sh--bootstrap-server192.168.61.101:9092--create--topic3p3r--partitions3--replication-factor3 https://img-blog.csdnimg.cn/direct/3fb9d6db51c047bfb86b5fe35dcbafbe.png
假设配置的是3p3r，则我们看下服务器上的存储
检察Topic信息
./kafka-topics.sh--bootstrap-server192.168.61.101:9092--describe--topic3p3r 此中 Partition是分区，Leader后面代表的是在哪台服务器上，Replicas就是副本信息，ISR是个副本队列https://img-blog.csdnimg.cn/direct/71139dc86e0940cca8a4af44034c1772.png
https://img-blog.csdnimg.cn/direct/ebf5143f6fbc4404af620c33a255e946.png
假设配置的是4p2r，则物品们检察topic信息如图所示
创建、检察topic
./kafka-topics.sh --bootstrap-server 192.168.61.101:9092 --create --topic 4p2r --partitions 4 --replication-factor 2 ./kafka-topics.sh --bootstrap-server 192.168.61.101:9092 --describe --topic 4p2r https://img-blog.csdnimg.cn/direct/f36a69cf3837468ba5f662a1956e1ac6.png
https://img-blog.csdnimg.cn/direct/b1594a9cc1ce44bca18c5665620038f6.png
假设我们配置的是6p2r
https://img-blog.csdnimg.cn/direct/447c8d61b6ef4f3f81ebdf4911774ae4.png
https://img-blog.csdnimg.cn/direct/253c10934b2c49848de6eda9b3f6d750.png
由以上我们可以看出，副天职配的两个基本原则和规律
1、副本会被均匀分布在所有的Broker之上
2 、 partition 的多个副本应该分配在差别的 Broker 上 基于上面的规则，分区副本最终落入哪个节点，还会收到两个随机数的影响
1、第一个随机数：startIndex，决定了第一个分区的第一个副本的放置位置
2 、第二个随机数： nextReplicaShift ，决定了分区中，副本跟副本的间距nextReplicaShift%(BrokerSize-1) 这样计划的目标在于提高Broker服务器的容灾本事
2. 消息保留与清理机制
对于一些太久的日记，我们必要肯定的清理计谋。
当开启清理计谋后，有两种方式提供开发者选择
log.cleanup.policy=delete （默认项） // 删除计谋 log.cleanup.policy=compact // 压缩计谋 2.1 删除计谋(delete)
kafka可以通过定时任务实现日记数据的删除，默认5分钟实行一次
log.retention.check.interval.ms=300000 那么要删除什么样的数据呢?kafka提供了两个纬度以及对应差别的配置
时间纬度
log.retention.hours（默认值是168个小时，时间戳高出的数据会被删除）
log.retention.minutes （默认值是空，优先级比小时高） log.retention.ms （默认值是空，优先级比分钟高） 若产生消息的速率不均匀，偶然多、偶然少，就可以根据日记大小删除
log.retention.bytes （表示所有日记文件的总大小，默认值是 -1 ，代表不限定大小） log.segment.bytes （对单个 Segment 文件大小进行限定，默认值 1G ） 2.2 压缩计谋(compact)
若设置为压缩计谋compact,则表示不清楚日记，只对日记数据进行压缩处理
思考题目: 假犹如一个key重复写入多次，是会存储多次?照旧会更新?
kafka中是存储多次的，如: _ _consumer_offsets
那么压缩计谋是怎么做的呢?（将雷同的key进行去重压缩）
https://img-blog.csdnimg.cn/direct/01411d1ce88f42c3aac45a8c1d2a9507.png
3. Broker高可用架构
高可用，无非就是选举机制、数据的一致性也就是主从同步，以及对于故障的处理，由于kafka是直接数据存储在磁盘中的，因此无需思量长期化，Broker的高可用 涉及到一系列的动作
[*]选举出一个Controller
[*]从分区中选举出Leader角色
[*]主从同步
[*]Replica故障处理
3.1 选举机制
3.1.1 Controller选举
Controller其实就是一个Broker,由它来负责选举出新的Leader,那么Controller是怎么选举出来的呢
https://img-blog.csdnimg.cn/direct/9b08e9c0b3ad4eb58bf630fe40bfe7af.png
3.1.2 分区副本Leader的选举
在解说Leader选举前，我们先复习以下博客Kafka之Producer原理-CSDN博客中提到的ISR机制的几个概念
AR （ Assigned-Replicas ），一个分区所有的副本 ISR （ In-Sync Replicas ），在 AR 中，跟 Leader 保持积极同步数据的副本 OSR （ Out-Sync-Replicas ），在 AR 中，跟 Leader 同步滞后的副本 AR = ISR + OSR
[*] 当Leader副本发生故障时，只有在ISR中的副本才气参与新Leader的选举
[*]题目:如果ISR为空呢? unclean.leader.election.enable配置为false OSR也可以进行选举
[*]Kafka采用了雷同于继位传嫡的选举协议，选择ISR中位置靠前的节点成为新的Leader.
3.2 主从同步
从节点和主节点的同步过程如下:
1 、起首， Follower 节点向 Leader 发送一个 fetch 请求 2 、然后， Leader 向 Follower 发送数据 3 、接着， Follower 接收到数据相应后，依次写入消息、并更新 LEO 值 4 、末了， Leader 更新 HW （ ISR 最小的 LEO ） 5 、循环上述过程，直至所有 Follower 完成数据同步 整体流程图如下所示:
https://img-blog.csdnimg.cn/direct/ff20f6f79a4d49789eab00301d1d9aac.png
https://img-blog.csdnimg.cn/direct/5383e6de7dc241118e8474b517500bea.png
https://img-blog.csdnimg.cn/direct/ffe1558d5f1f4812a236dc2c2c3fb601.png
Kafka计划的ISR复制，既可以在保障数据一致性，又可以提供高吞吐量(ISR队列中清除相应不积极的Follower节点)
3.3 Replica故障处理
https://img-blog.csdnimg.cn/direct/25cc2f52c16d43ba9ff4e7454e85daf3.png
[*]Follower发生故障，会被先提出ISR，Follower规复之后，从HW开始同步数据
[*]Leader发生故障，会先选举出一个新的Leader,其它的Follower将高于HW的消息截取掉，然后重新的Leader同步数据
4. 总结
本文介绍Broker服务器，主要讲了Broker中日记的存储，从大到小依次为Partition、Segment，副本机制的具体存储形式，是怎么进行负载均衡和容灾保障的，在Segment中我们直到了Segment是由一个Log文件和两个索引文件组成的，索引文件主要起的是一个提拔查询效率的作用。随后当kafka中log文件过大的时候，kagka中提供了两种维度上的删除计谋以及雷同key去重压缩的compact计谋。末了，kafka高可用中的选举机制是先到先得选举Controller,再根据ISR副本队列嫡长子继位的算法进行Leader的选举；以及Kafka中的主从同步是以高水位HW为边界，不停的同步数据，直到LEO值相称完成数据的同步。末了讲到了副本故障的处理，针对follwe节点故障，则直接踢出ISR队列，Leader故障，就会触发选举机制，选举出一个新的Leader，末了数据从LEO处以上的开始同步，高于HW的消息全部截断。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]