1. 日志数据的存储
1.1 Partition
1.2 Replica副本
1.3 Segment段
每一个segment都是由一个log文件和2个index文件组成的,其中时间戳索引的创建方式可以自定义的执行createTime或LogAppendTime.默认是creareTime
1.4 Sparse Index(稀疏索引)
索引文件的查看可以通过以下命令进行查看
kfaka索引文件中记录的Offset不是连续的，而是采用了稀疏索引。根据配置的大小，稀疏索引记录的是从Log中的哪个位置开始检索，比如配置的是4kb，则当log文件中向下存储的数据达到4kb的话，就会记录一个索引值
1.5 分区副本在Broker上的分布
创建一个topic
假设配置的是3p3r，则我们看下服务器上的存储
查看Topic信息
其中 Partition是分区，Leader后面代表的是在哪台服务器上，Replicas就是副本信息，ISR是个副本队列
假设配置的是4p2r，则物品们查看topic信息如图所示
创建、查看topic
假设我们配置的是6p2r
由以上我们可以看出，副本分配的两个基本原则和规律
基于上面的规则，分区副本最终落入哪个节点，还会收到两个随机数的影响
这样设计的目的在于提高Broker服务器的容灾能力
2. 消息保留与清理机制
对于一些太久的日志，我们需要一定的清理策略。
当开启清理策略后，有两种方式提供开发者选择
2.1 删除策略(delete)
kafka可以通过定时任务实现日志数据的删除，默认5分钟执行一次
那么要删除什么样的数据呢?kafka提供了两个纬度以及对应不同的配置
时间纬度
若产生消息的速度不均匀，有时多、有时少，就可以根据日志大小删除
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机制的几个概念
- 当Leader副本发生故障时，只有在ISR中的副本才能参与新Leader的选举
- 问题:如果ISR为空呢? unclean.leader.election.enable配置为false OSR也可以进行选举
- Kafka采用了类似于继位传嫡的选举协议，选择ISR中位置靠前的节点成为新的Leader.
3.2 主从同步
从节点和主节点的同步过程如下:
整体流程图如下所示:
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的消息全部截断。
