【kafka】——Broker
Kfaka Broker
1. Zookeeper 存储的kafka信息
<1> /kafka/brokers/dis
存储broker的id，记录有哪些服务器
<2> /kafka/brokers/topics
存储topic 相关信息
<3> /kafka/consumers
Kafka 0.9 版本之前 用于保存offset信息
Kafka 0.9 版本之后offser存储在Kafka主题中
<4> /kafka/controller
辅助选举Leader
2. Broker工作流程
<1> Broker 启动后在Zookeeper中注册
<2> 每个节点中的Contoller 抢先在Zookeeper中注册，谁抢先注册，谁负责Leader选举
<3> 由选举出来的Controller 监听brokers节点的变化
<4> 选举规则：在ISR中存活为前提，按照AR（Kafka分区中的所有副本统称）中排在前面的优先，例如：AR[1,0,2]，ISR[0,1,2],那么Leader就会按照1，0，2 的顺序轮询
<5> Controller将节点信息上传到ZK
<6> 其他Controller从zk同步相关信息
<7> 生产者发送数据到Leader ，Follower 主动从Leader 拉取信息。
<8> 底层通过Segment存储，一个Segment默认大小1G。.log文件存储信息。.index文件存储索引，加快检索速度。
<9> 如果Ledaer 宕机。Controller监听到brokers节点发生变化，从ZK拉取Leader 和ISR信息，然后重新选举Leader（ISR中存活为前提。按照AR中排在前面的有限）。更新Leader 和ISR
3. 模拟Kafka上下线
<1> 原始状态
-
查看/kafka/brokers/ids 路径上的节点。
-
查看/kafka/controller 路径上的数据。
-
查看/kafka/brokers/topics/test_topic/partitions/0/state 路径上的数据
<2> 停止 Follower节点后状态
-
再次查看/kafka/brokers/ids 路径上的节点
-
查看/kafka/controller 路径上的数据。
-
查看/kafka/brokers/topics/test_topic/partitions/0/state 路径上的数据
<3> 停止 Leader节点后状态
-
再次查看/kafka/brokers/ids 路径上的节点
-
查看/kafka/controller 路径上的数据。
-
查看/kafka/brokers/topics/test_topic/partitions/0/state 路径上的数据
4. 新增和减少节点
<1> 新节点准备
1. 修改IP 地址和主机名
2. 安装JDK和Kakfa
kafka 需要修改配置文件，brokerid 需要全局唯一
如果是从其他服务器克隆，则需要删除datas目录我logs目录下的内容。
3. 启动新增节点上的Kafka
bin/kafka-server-start.sh - daemon ./config/server.properties
<2> 新增节点
如果只是作为新topic 使用，则不需要以下操作。如果想要将旧topic 的数据迁移到新增节点上，因为已经创建的topic主题的分区和副本只在旧的节点上，那么需要以下操作。可见 test_topic 的分区和副本都在 0，1，2 三个broker中。
通过命令，可见 test_topic 的分区和副本都在 0，1，2 三个broker中。
1. 创建一个要均衡的主题
在Kafka根目录下创建文件 topics-to-move.json
{
"topics": [
{
"topic": "test_topic"
}
],
"version": 1
}
test_topic 为测试节点，如果是多个topic ，只需要在json串中并列添加。“version”: 1是固定写法
2. 生成一个负载均衡的计划
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --topics-to-move-json-file topics-to-move.json --broker-list "0,1,2,3" --generate
3 为新增的节点的brokerID
Current partition replica assignment（当前的分区和副本规划）
{"version":1,"partitions":[{"topic":"test_topic","partition":0,"replicas":[0,2,1],"log_dirs":["any","any","any"]},{"topic":"test_topic","partition":1,"replicas":[1,2,0],"log_dirs":["any","any"test_topic","partition":2,"replicas":[2,0,1],"log_dirs":["any","any","any"]}]}
Proposed partition reassignment configuration（新提出的分区和副本计划）
{"version":1,"partitions":[{"topic":"test_topic","partition":0,"replicas":[3,0,1],"log_dirs":["any","any","any"]},{"topic":"test_topic","partition":1,"replicas":[0,1,2],"log_dirs":["any","any"test_topic","partition":2,"replicas":[1,2,3],"log_dirs":["any","any","any"]}]}
可见在新提出的分区和副本计划中添加了brokerid=3的新增节点。
3. 创建副本存储计划
在Kafka根目录下创建文件vim increase-replication-factor.json，将新提出的分区和副本计划写入文件。
{
"version": 1,
"partitions": [
{
"topic": "test_topic",
"partition": 0,
"replicas": [
3,
0,
1
],
"log_dirs": [
"any",
"any",
"any"
]
},
{
"topic": "test_topic",
"partition": 1,
"replicas": [
0,
1,
2
],
"log_dirs": [
"any",
"any",
"any"
]
},
{
"topic": "test_topic",
"partition": 2,
"replicas": [
1,
2,
3
],
"log_dirs": [
"any",
"any",
"any"
]
}
]
}
4. 执行副本存储计划
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --reassignment-json-file increase-replication-factor.json --execute
5. 验证副本存储计划
<1> 方式一
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --reassignment-json-file increase-replication-factor.json --verify
<2> 方式二
bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --topic test_topic --describe
<3> 减少节点
当减少一个kafka集群节点的时候，不能简单粗暴的将节点停止，因为有的topic的分区和副本在节点上，如果直接停止会造成数据丢失，需要进行以下操作。
1. 创建一个要均衡的主题
在Kafka根目录下创建文件 topics-to-move.json
{
"topics": [
{
"topic": "test_topic"
}
],
"version": 1
}
test_topic 为测试节点，如果是多个topic ，只需要在json串中并列添加。“version”: 1是固定写法
2. 生成一个负载均衡的计划
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --topics-to-move-json-file topics-to-move.json --broker-list "0,1,2" --generate
broker-list只保留要留存的节点
Current partition replica assignment（当前的分区和副本规划）
{"version":1,"partitions":[{"topic":"test_topic","partition":0,"replicas":[3,0,1],"log_dirs":["any","any","any"]},{"topic":"test_topic","partition":1,"replicas":[0,1,2],"log_dirs":["any","any","any"]},{"topic":"test_topic","partition":2,"replicas":[1,2,3],"log_dirs":["any","any","any"]}]}
Proposed partition reassignment configuration（新提出的分区和副本计划）
{"version":1,"partitions":[{"topic":"test_topic","partition":0,"replicas":[0,1,2],"log_dirs":["any","any","any"]},{"topic":"test_topic","partition":1,"replicas":[1,2,0],"log_dirs":["any","any","any"]},{"topic":"test_topic","partition":2,"replicas":[2,0,1],"log_dirs":["any","any","any"]}]}
可见在新提出的分区和副本计划中 只保留要留存的节点。
3. 创建副本存储计划
在Kafka根目录下创建文件vim increase-replication-factor.json，将新提出的分区和副本计划写入文件。
{
"version": 1,
"partitions": [
{
"topic": "test_topic",
"partition": 0,
"replicas": [
0,
1,
2
],
"log_dirs": [
"any",
"any",
"any"
]
},
{
"topic": "test_topic",
"partition": 1,
"replicas": [
1,
2,
0
],
"log_dirs": [
"any",
"any",
"any"
]
},
{
"topic": "test_topic",
"partition": 2,
"replicas": [
2,
0,
1
],
"log_dirs": [
"any",
"any",
"any"
]
}
]
}
4. 执行副本存储计划
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --reassignment-json-file increase-replication-factor.json --execute
5. 验证副本存储计划
<1> 方式一
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --reassignment-json-file increase-replication-factor.json --verify
<2> 方式二
bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092 --topic test_topic --describe
6. 停止节点
bin/kafka-server-stop.sh
5. Kafka副本
<1> 基本信息
- 作用：提高数据可靠性
- 默认一个副本，生产环境一般配置2个。保证数据可靠性；太多副本会增加磁盘空间，增加网络上数据传输，降低效率。
- 分为Leader 和Follower。kafka生产者只会把数据发送给Leader。饭后Follower找Leader进行同步数据。
- ISR：标识和Leader保持同步的Follower集合，如果长时间未向Leader发送通讯请求或同步数据，则Follower将被提出ISR。该时间阈值由replica.time.max.ms 参数设定，默认30s。Leader发生故障之后，就会从ISR中选举新的Leader。
- SR：表示Follower与Leader副本同步时，延迟过多
- AR：Kafka分区中所有副本的统称 O的副本。
<2> Leader选举流程
Kafka集群中有个一broker的Controller 会被选举为Controller Leader。负责管理集群broker的上下线，所有topic的分区副本分配和Leader选举等工作。Controller的信息同步工作是依赖于Zookeeper的。
- Broker 启动后在Zookeeper中注册
- 每个节点中的Contoller 抢先在Zookeeper中注册，谁抢先注册，谁负责Leader选举
- 由选举出来的Controller 监听brokers节点的变化
- 选举规则：在ISR中存活为前提，按照AR（Kafka分区中的所有副本统称）中排在前面的优先，例如：AR[1,0,2]，ISR[0,1,2],那么Leader就会按照1，0，2 的顺序轮询
- 如果Ledaer 宕机。Controller监听到brokers节点发生变化，从ZK拉取Leader 和ISR信息，然后重新选举Leader（ISR中存活为前提，按照AR中排在前面的有限）。
<3> Leader 和Follower 故障处理细节
1. LEO（Log End Offset）
每个副本的最后一个offset ，LEO其实就是最新的offset +1 。
2. HW（High Watermark）
所有副本中最小的LEO。
3. Follower 故障
<1> Follower 发生故障后，会被临时踢出ISR。
<2> 这个期间Leader和Follower继续接受数据。
<3> 待该Follower恢复后，Follower 会读取本地磁盘记录的上次的HW。并将log文件高于HW的部分截取掉，从HW开始向Leader进行同步。
<4> 待该Follower的LEO大于等于该Partition的HW。即Follower追上Leader之后，就可以重新加入ISR了。
4. Leader故障
<1> Leader发生故障后，会被临时踢出ISR。
<2> 从ISR 中选出一个新的Leader。
<3> 为保证多个副本之间的数据一致性，其余的Follower会先将各自的log 文件高于HW的部分接截掉，然后从新的Leader同步数据。（只能保证副本之间的数据一致的，并不能保证数据不丢失或者不重复）
<4> 分区副本分配
1. 默认分配
如果kafka分区数大于服务器台数默认情况下， kafka分区分配时候，底层实现是尽量均匀分布的。
2. 手动分配
在生产环境中，每台服务器的配置和性能不一致，但是Kafka只会根据自己的代码规则创建对应的分区副本，就会导致个别服务器存储压力较大。所有需要手动调整分区副本的存储。
3. 实例
创建一个新的主题，4个分区，每个分区2个副本。默认情况下分区和副本会分布在四个节点上，再手动改为broker0 和broker1上。
<1> 创建主题
bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --topic test_assign_topic --create --partitions 4 --replication-factor 2
<2> 查看分区和副本分布情况
bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --topic test_assign_topic --describe
<3> 创建副本存储计划
在Kafka根目录下创建文件vim increase-replication-factor.json，将新提出的分区和副本计划写入文件。
{
"version": 1,
"partitions": [
{
"topic": "test_assign_topic",
"partition": 0,
"replicas": [
1,
0
],
"log_dirs": [
"any",
"any"
]
},
{
"topic": "test_assign_topic",
"partition": 1,
"replicas": [
0,
1
],
"log_dirs": [
"any",
"any"
]
},
{
"topic": "test_assign_topic",
"partition": 2,
"replicas": [
1,
0
],
"log_dirs": [
"any",
"any"
]
},
{
"topic": "test_assign_topic",
"partition": 3,
"replicas": [
0,
1
],
"log_dirs": [
"any",
"any"
]
}
]
}
<4> 执行副本存储计划
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --reassignment-json-file increase-replication-factor.json --execute
<5> 验证副本存储计划
<1> 方式一
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --reassignment-json-file increase-replication-factor.json --verify
<2> 方式二
bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --topic test_topic --describe
<5> Leader Partition 负载平衡
正常情况下，Kafka本身会自动把Leader Partition均匀分散在各个机器上，来保证每台机器的读写吞吐量都是均匀的。但是如果某些broker宕机，会导致Leader Partition过于集中在其他少部分几台broker上，这会导致少数几台broker的读写请求压力过高，其他宕机的broker重启之后都是follower partition，读写请求很低，造成集群负载不均衡。
1. 自动平衡
<1> auto.leader.rebalance.enable
默认是true。自动Leader Partition平衡
<2> leader.imbalance.per.broker.percentage
默认是10%。每个broker允许的不平衡的leader的比率。如果每个broker超过了这个值，控制器会触发leader的平衡。
<3> leader.imbalance.check.interval.seconds
默认值300秒。检查leader负载是否平衡的间隔时间。
<6> 增加副本
1. 创建主题
bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092, hadoop105:9092 --topic test_add_replication_topic --create --partitions 4 --replication-factor 1
2. 查看分区和副本分布情况
bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --topic test_add_replication_topic --describe
3. 创建副本存储计划
在Kafka根目录下创建文件vim increase-replication-factor.json，将新提出的分区和副本计划写入文件。
{
"version": 1,
"partitions": [
{
"topic": "test_add_replication_topic",
"partition": 0,
"replicas": [
1,
0
],
"log_dirs": [
"any",
"any"
]
},
{
"topic": "test_add_replication_topic",
"partition": 1,
"replicas": [
0,
1
],
"log_dirs": [
"any",
"any"
]
},
{
"topic": "test_add_replication_topic",
"partition": 2,
"replicas": [
2,
3
],
"log_dirs": [
"any",
"any"
]
},
{
"topic": "test_add_replication_topic",
"partition": 3,
"replicas": [
3,
2
],
"log_dirs": [
"any",
"any"
]
}
]
}
4. 执行副本存储计划
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --reassignment-json-file increase-replication-factor.json --execute
5. 验证副本存储计划
<1> 方式一
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --reassignment-json-file increase-replication-factor.json --verify
<2> 方式二
bin/kafka-topics.sh --bootstrap-server hadoop102:9092,hadoop103:9092,hadoop104:9092,hadoop105:9092 --topic test_add_replication_topic --describe
6. 文件存储机制
<1> 概述
- Topic是逻辑上的概念，而partition是物理上的概念。
- 每个partition对应一个log文件(log文件也是虚拟概念)，该log文件中存储的就是Producer生产的数据。Producer生产的数据会被不断追加到该log文件末端。
- 为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，将每个partition分为多个segment。log.segment.bytes 指定segment的大小，默认值 1G。
- 每个segment包括:.index文件、.log文件和.timeindex等文件。位于同一目录下。
- 该文件夹的命名规则为：topic名称+分区序号，例如test_topic-0。
- Kafka 中的消息默认保存7天。
<2> 查看文件内容
通过工具查看 index 和 log 信息。
kafka-run-class.sh kafka.tools.DumpLogSegments --files ./00000000000000000000.index
kafka-run-class.sh kafka.tools.DumpLogSegments --files ./00000000000000000000.logs
<3> index 文件和 log 文件详解
- index为稀疏索引，大约每往log 文件中写入4kb数据，会往index文件中写入一条索引，参数log.index.interval.bytes 默认4kb
- index文件中保存的offset为相对offset，这样能保证offset的值所占空间不会过大，因此能将offset 的值控制在固定大小。
<4> 查找过程
- 根据目标offset定位segment文件。
- 找到小于或等于目标offset的最大offset对那个的索引项。
- 定位到log文件。
- 向下遍历找到目标record。
7. 文件清理策略
<1> 概述
Kafka 中默认的日志保存时间为 7 天，
可以通过调整如下参数修改保存时间。
- log.retention.hours，最低优先级，小时，默认 7 天。
- log.retention.minutes，分钟。 高于小时优先级
- log.retention.ms，最高优先级，毫秒。
- log.retention.check.interval.ms，负责设置检查周期，默认 5 分钟
<2> 日志清理策略
1. delete
<1> log.cleanup.policy = delete 所有数据启用删除策略
<2> 基于时间：默认打开。以 segment 中所有记录中的最大时间戳作为该文件时间戳。
<3> 基于大小(log.retention.bytes)：默认关闭。超过设置的所有日志总大小，删除最早的 segment。
<4> log.retention.bytes，默认等于-1，表示无穷大。
2. compact
<1> log.cleanup.policy = compact 所有数据启用压缩策略
<2> compact日志压缩：对于相同key的不同value值，只保留最后一个版本。
<3> 压缩后的offset可能是不连续的，比如上图中没有6，当从这些offset消费消息时，将会拿到比这个offset大 的offset对应的消息，实际上会拿到offset为7的消息，并从这个位置开始消费。
<4> 这种策略只适合特殊场景，比如消息的key是用户ID，value是用户的资料，通过这种压缩策略，整个消息 集里就保存了所有用户最新的资料。
8. 高效读写数据
<1> kafka 本省是分布式集群，可以采用分区奇数，并行度高。
<2> 读数据采用稀疏索引，可以快速定位到要消费的数据。
<3> 顺序写磁盘
Kafka 的 producer 生产数据，要写入到 log文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。
<4> 页缓存 + 零拷贝技术
零拷贝：Kafka的数据加工处理操作交由Kafka生产者和Kafka消费者处理。Kafka Broker应用层不关心存储的数据，所以就不用 走应用层，传输效率高。
PageCache页缓存：Kafka重度依赖底层操作系统提供的PageCache功能。当上层有写操作时，操作系统只是将数据写入 PageCache。当读操作发生时，先从PageCache中查找，如果找不到，再去磁盘中读取。实际上PageCache是把尽可能多的空闲内存都当做了磁盘缓存来使用。
