泰州住房和城乡建设厅网站首页,wordpress数据库修改域名,攻击wordpress,网站制作推广需要多少钱本文内容来自尚硅谷B站公开教学视频#xff0c;仅做个人总结、学习、复习使用#xff0c;任何对此文章的引用#xff0c;应当说明源出处为尚硅谷#xff0c;不得用于商业用途。 如有侵权、联系速删 视频教程链接#xff1a;【尚硅谷】Kafka3.x教程#xff08;从入门到调优… 本文内容来自尚硅谷B站公开教学视频仅做个人总结、学习、复习使用任何对此文章的引用应当说明源出处为尚硅谷不得用于商业用途。 如有侵权、联系速删 视频教程链接【尚硅谷】Kafka3.x教程从入门到调优深入全面 文章目录 1 副本基本信息2 Leader 选举流程3Leader 和 Follower 故障处理细节3.1 Follower故障处理细节3.2 Leader故障处理细节 4 分区副本分配5 手动调整分区副本存储6 Leader Partition 负载平衡7 增加副本因子 1 副本基本信息
1Kafka 副本作用提高数据可靠性。 2Kafka 默认副本 1 个生产环境一般配置为 2 个保证数据可靠性太多副本会增加磁盘存储空间增加网络上数据传输降低效率。 3Kafka 中副本分为Leader 和 Follower。Kafka 生产者只会把数据发往 Leader然后 Follower 找 Leader 进行同步数据。 4Kafka 分区中的所有副本统称为 ARAssigned Repllicas。 AR ISR OSR ISR 表示和 Leader 保持同步的 Follower 集合。如果 Follower 长时间未向 Leader 发送通信请求或同步数据则该 Follower 将被踢出 ISR。该时间阈值由 replica.lag.time.max.ms参数设定默认 30s。Leader 发生故障之后就会从 ISR 中选举新的 Leader。 OSR 表示 Follower 与 Leader 副本同步时延迟过多的副本。
2 Leader 选举流程
Kafka 集群中有一个 broker 的 Controller 会被选举为 Controller Leader负责管理集群broker 的上下线所有 topic 的分区副本分配和 Leader 选举等工作。 Controller 的信息同步工作是依赖于 Zookeeper 的。 模拟一下一个集群从启动到leader挂掉是怎么重新选leader的
首先我们启动集群所有的节点启动并在zookeeper中注册自己的信息此时谁先注册谁就工作积极那这个节点就负责选举这个节点被称为controller剩下的按积极性依次排列controller负责监听各个节点的信息并维护进zookeeper中现在确定出controller节点这个controller节点将数据上传到zk并开始维护别的节点读取zk的数据这时假设有个节点挂了controller发现有个节点没了那这个节点上的所有主题的leader等于没了要重新选举首先获取了ISR看看要重新选举leader的主题它还有哪些节点活着从活着的节点中选一个在AR队列里排名最靠前的节点它就是新的leader将新的节点信息上传到zk其他节点同步数据 3Leader 和 Follower 故障处理细节
我们上面知道了如何重新选leader的但选举时的数据如何处理呢往下接着分析我们将挂掉的情况分为leader挂掉和follower挂掉两种情况
3.1 Follower故障处理细节
首先引出两个概念LEO和WH LEO 每个副本的最后一个offset也就是最后一条消息的ID或者说同步到哪条消息了 HW 所有副本中最小的LEO也就是所有副本中同步最慢的那个同步到哪条消息了
现在如下图节点2挂掉了上面的副本离线不影响其余副本当它重新上线时将挂掉时的HW和它自己的LEO之间的数据清理掉重新从掉时的HW处开始同步直到追上现在的HW时重新加入ISR 为啥要清理掉这批数据 数据都是一批一批的同步过来的挂掉时并不知道你这一批数据同步到哪一个了也就是HW到你的LEO这中间的数据都可能不完整所以干脆全部舍弃重新同步 3.2 Leader故障处理细节
和follower差不多区别是新的leader并不知道故障时别的节点同步的具体认为故障时高于HW的数据都不可靠所以全部清掉重新同步 这就导致了一个问题leader挂掉时通过清掉HW后面的数据让新的leader和follower之间的数据保持了一致性但是挂掉的leader可能已经处理了一部分数据了那这一部分数据如果没同步到别的节点上等于这部分数据就丢失了
4 分区副本分配
会依次往每个节点上放 如果 kafka 服务器只有 4 个节点那么设置 kafka 的分区数大于服务器台数在 kafka底层如何分配存储副本呢
创建 16 分区3 个副本 ①创建一个新的 topic名称为 second。
bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --create --partitions 16 --replication-factor 3 --topic second②查看分区和副本情况。
bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic second
Topic: second4 Partition: 0 Leader: 0 Replicas: 0,1,2 Isr: 0,1,2
Topic: second4 Partition: 1 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
Topic: second4 Partition: 2 Leader: 2 Replicas: 2,3,0 Isr: 2,3,0
Topic: second4 Partition: 3 Leader: 3 Replicas: 3,0,1 Isr: 3,0,1
Topic: second4 Partition: 4 Leader: 0 Replicas: 0,2,3 Isr: 0,2,3
Topic: second4 Partition: 5 Leader: 1 Replicas: 1,3,0 Isr: 1,3,0
Topic: second4 Partition: 6 Leader: 2 Replicas: 2,0,1 Isr: 2,0,1
Topic: second4 Partition: 7 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2
Topic: second4 Partition: 8 Leader: 0 Replicas: 0,3,1 Isr: 0,3,1
Topic: second4 Partition: 9 Leader: 1 Replicas: 1,0,2 Isr: 1,0,2
Topic: second4 Partition: 10 Leader: 2 Replicas: 2,1,3 Isr: 2,1,3
Topic: second4 Partition: 11 Leader: 3 Replicas: 3,2,0 Isr: 3,2,0
Topic: second4 Partition: 12 Leader: 0 Replicas: 0,1,2 Isr: 0,1,2
Topic: second4 Partition: 13 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
Topic: second4 Partition: 14 Leader: 2 Replicas: 2,3,0 Isr: 2,3,0
Topic: second4 Partition: 15 Leader: 3 Replicas: 3,0,1 Isr: 3,0,15 手动调整分区副本存储
在生产环境中每台服务器的配置和性能不一致但是Kafka只会根据自己的代码规则创建对应的分区副本就会导致个别服务器存储压力较大。所有需要手动调整分区副本的存储。
需求创建一个新的topic4个分区两个副本名称为three。将 该topic的所有副本都存储到broker0和broker1两台服务器上。 手动调整分区副本存储的步骤如下 1创建一个新的 topic名称为 three。
bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --create --partitions 4 --replication-factor 2 --topic three2查看分区副本存储情况。
bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic three3创建副本存储计划所有副本都指定存储在 broker0、broker1 中。
vim increase-replication-factor.json输入如下内容
{
version:1,
partitions:[{topic:three,partition:0,replicas:[0,1]},
{topic:three,partition:1,replicas:[0,1]},
{topic:three,partition:2,replicas:[1,0]},
{topic:three,partition:3,replicas:[1,0]}]
}4执行副本存储计划。
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --reassignment-json-file increase-replication-factor.json --execute6查看分区副本存储情况。
bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --describe --topic three6 Leader Partition 负载平衡
正常情况下Kafka本身会自动把Leader Partition均匀分散在各个机器上来保证每台机器的读写吞吐量都是均匀的。但是如果某些broker宕机会导致Leader Partition过于集中在其他少部分几台broker上这会导致少数几台broker的读写请求压力过高其宕机的broker重启之后都是follower partition读写请求很低造成集群负载不均衡。 auto.leader.rebalance.enable默认是true。自动Leader Partition 平衡。生产环境中leader 重选举的代价比较大可能会带来性能影响建议设置为 false 关闭。 leader.imbalance.per.broker.percentage默认是10%。每个broker允许的不平衡的leader的比率。如果每个broker超过了这个值控制器会触发leader的平衡。 leader.imbalance.check.interval.seconds默认值300秒。检查leader负载是否平衡的间隔时间。 下面拿一个主题举例说明假设集群只有一个主题如下图所示
针对broker0节点分区2的AR优先副本是0节点但是0节点却不是Leader节点 所以不平衡数加1AR副本总数是4 所以broker0节点不平衡率为1/410%需要再平衡。
broker2和broker3节点和broker0不平衡率一样需要再平衡。 Broker1的不平衡数为0不需要再平衡
7 增加副本因子
在生产环境当中由于某个主题的重要等级需要提升我们考虑增加副本。副本数的增加需要先制定计划然后根据计划执行。 1创建 topic bin/kafka-topics.sh --bootstrap-server hadoop102:9092 --create --partitions 3 --replication-factor 1 --topic four2手动增加副本存储 创建副本存储计划所有副本都指定存储在 broker0、broker1、broker2 中
vim increase-replication-factor.json输入如下内容
{version:1,partitions:[{topic:four,partition:0,replicas:[0,1,2]},{topic:four,partition:1,replicas:[0,1,2]},{topic:four,partition:2,replicas:[0,1,2]}]}执行副本存储计划。
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop102:9092 --reassignment-json-file increase-replication-factor.json --execute
