1. 日记数据的存储
1.1 Partition
1. 为了实现横向扩展，把差别的数据存放在差别的 Broker 上，同时降低单台服务器的访问压力，我们把一个Topic 中的数据分隔成多个 Partition 2. 每个 Partition 中的消息是有序的，顺序写入，但是全局不肯定有序 3. 在服务器上，每个 Partition 都有一个物理目录（ TopicN ）后面的数字代表分区
1.2 Replica副本
1. 为了提高分区的可靠性， Kafka 计划了副本机制 2. 副本数必须小于便是节点数，而不能大于 Broker 的数量 3. Leader 对外提供读写服务， Follower 唯一的任务就是从 Leader 异步拉取数据
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
1.4 Sparse Index(希罕索引)
索引文件的检察可以通过以下命令进行检察
kfaka索引文件中记录的Offset不是连续的，而是采用了希罕索引。根据配置的大小，希罕索引记录的是从Log中的哪个位置开始检索，好比配置的是4kb，则当log文件中向下存储的数据达到4kb的话，就会记录一个索引值
1.5 分区副本在Broker上的分布
创建一个topic
./kafka-topics.sh--bootstrap-server192.168.61.101:9092--create--topic3p3r--partitions3--replication-factor3
假设配置的是3p3r，则我们看下服务器上的存储
检察Topic信息
./kafka-topics.sh--bootstrap-server192.168.61.101:9092--describe--topic3p3r 此中 Partition是分区，Leader后面代表的是在哪台服务器上，Replicas就是副本信息，ISR是个副本队列
假设配置的是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
假设我们配置的是6p2r
由以上我们可以看出，副天职配的两个基本原则和规律
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进行去重压缩）
3. Broker高可用架构
高可用，无非就是选举机制、数据的一致性也就是主从同步，以及对于故障的处理，由于kafka是直接数据存储在磁盘中的，因此无需思量长期化，Broker的高可用 涉及到一系列的动作
- 选举出一个Controller
- 从分区中选举出Leader角色
- 主从同步
- Replica故障处理
3.1 选举机制
3.1.1 Controller选举
Controller其实就是一个Broker,由它来负责选举出新的Leader,那么Controller是怎么选举出来的呢
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 完成数据同步 整体流程图如下所示:
Kafka计划的ISR复制，既可以在保障数据一致性，又可以提供高吞吐量(ISR队列中清除相应不积极的Follower节点)
3.3 Replica故障处理
- 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企服之家，中国第一个企服评测及商务社交产业平台。 |
