kafka broker

kafka学习笔记（课程：尚硅谷kafka3.x）

在zookeeper中要记住的kafka相关信息

/kafka/broker/ids

记录有哪些服务器

/kafka/broker/topics/first/partitions/0/state

{“leader”:1,“isr”:[1,0,2]}记录leader是谁，有哪些服务器可以用

/kafka/controller

{“brokerid”:0}
辅助选举leader

其他

consumer：消费者信息，用于保存offset。0.9之前用于保存offset，0.9版本之后offset存储在kafka主题中

broker总体工作流程

（1） broker启动后在zk中注册，在/ids中增加节点
（2） controller谁先注册，谁说了算（并没有成为leader）
（3）由选举出来的controller坚挺brokers节点变换
（4）conteoller决定Leader选举
AR：kafka分区中所有副本的统称
选举规则：
在isr中存活，AR中排在前面的优先，按照isr中的顺序轮询
（5） controller将节点信息上传到zk
（6） 其他controller从zk同步相关信息
（7）如果leader挂了，则： controller监听到节点变化，从zk获取isr
（10） 选举新的leader

follower故障处理细节

一些概念

LEO(Log End Offset)：每个副本的最后一个offset，就是最新的offset+1
HW(High Watermark)：所有副本中最小的LEO

故障处理

（1） 如果是follower出现故障
故障的follower被踢出ISR，其他的继续接收数据。重新连上之后，原故障的follower中记录有断开之前的HW，把高于HW的部分截掉，从HW开始向leader进行同步。当其LEO大于等于该partition的HW，重新加入ISR
（2） leader挂了
踢出ISR，选出一个新的leader，其余follower截掉高于HW的部分，然后从新的leader同步数据（智能保证副本之间的一直性，并不能保证数据不丢失/不重复）

节点服役和退役

服役新节点

退役旧节点

把数据导入到其他节点上

kafka副本

kafka副本作用

提高数据可靠性
默认副本是一个，生产环境一般配置为2个
太多会增加存储空间，增加网络传输压力
副本分为leader和follower
所有副本称为AR
AR=ISR+OSR
kafka操作只针对leader，follower找leader进行同步数据
OSR：延迟过多的副本

分区副本分配

leader和follower不在同一个broker
尽量保证不同的partition的副本分配情况不一样，用过123，下一次可以用013
副本分配尽量均匀。

手动调整分区副本存储

执行副本存储计划：

bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --reassignment-json-file increase-replication-factor.json --execute

其中，json文件的内容形如：

{
“version”:1,
“partitions”:[{“topic”:“three”,“partitions”:0,“replicas”:[0,1]},
{“topic”:“three”,“partitions”:1,“replicas”:[0,1]},
{“topic”:“three”,“partitions”:2,“replicas”:[1,0]},
{“topic”:“three”,“partitions”:3,“replicas”:[1,0]}]
}
验证副本存储计划

bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --reassignment-json-file increase-replication-factor.json --verify

查看分区副本存储情况

bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic three

以上代码来自尚硅谷kafka3.x教程，本人因为电脑内存不足不方便搞虚拟机（yin wei lan）没有试验过

leader partition自动平衡

broker宕机会导致leaderpartition过于集中在其他少部分几台broker上，导致少数几台broker的读写请求压力过高，其他重启的都是follower，读写请求很低，造成集群负载不均衡。

kafka使用自动再平衡机制进行负载均衡。
配置项：auto.leader.rebalance.enable，默认值是true
leader.imbalance.per.broker.percentage，默认是10%，每个broker允许的不平衡的leader的比例如果每个broker超过这个值，控制器会触发leader的再平衡。计算方式：当AR优先副本和leader节点不同时，不平衡数加1。不平衡比例=不平衡数/AR。
leader.imbalance.check.interval.seconds，默认值300s。检查leader负载是否平衡的间隔时间。

一般不建议开启再平衡，因为再平衡消耗大量的资源。
kafka的生产者、broker、消费者都有再平衡机制，这个地方的再平衡好像不是特别重要，用到再看吧。感觉可能讲的不太对。

生产经验——增加副本因子

某个主题需要提高可靠性，要增加副本。
不能通过命令行修稿弗恩，要手动操作

vim increase-replication-factor.json

输入的内容：

{
“version”:1,
“partitions”:[{“topic”:“four”,“partitions”:0,“replicas”:[0,1,2]},
{“topic”:“four”,“partitions”:1,“replicas”:[0,1,2]},
{“topic”:“four”,“partitions”:2,“replicas”:[1,0,2]}]
}
执行副本存储计划：

bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --reassignment-json-file increase-replication-factor.json --execute

kafka文件存储

topic是逻辑上的概念，partition是物理上的概念。每个partition对应一个log文件。（log文件也是虚拟的概念。）生产者生产的数据不断追加到log文件末端。partition以segment形式存储，单位大小为1g。每个segment包括：“.index"文件、”.log"文件、".timeindex"文件和其他文件。
".log"文件：实实在在存储数据的地方。
".index"文件：偏移量索引文件
".timeindex"文件：消费者不删除数据。kafka默认保存时间是7天。这个文件用来存储时间。
index和log文件以当前segment的第一条消息的offset命名。

使用kafka工具查看log和index信息，不然是乱码（因为是序列化后的文件）。

kafka-run-class.sh kafka.tools.DumpLogSegments--files ./00000000000000000000.index

0没数，个数可能不对。

index存储

index是稀疏存储，每往log写入4kB数据，会往index文件写入一条索引（log.index.interval.bytes）。
index文件中保存的offset为相对offset，相对于文件名中的offset。