kafka-broker-副本

SeaDhdhdhdhdh

已于 2022-11-14 21:33:47 修改

阅读量504

点赞数

分类专栏： kafka 文章标签： kafka 大数据

于 2022-11-14 21:32:20 首次发布

本文链接：https://blog.csdn.net/weixin_43119856/article/details/127849910

版权

kafka 专栏收录该内容

11 篇文章 1 订阅

订阅专栏

6 Leader Partition自动平衡(重要)

7 生产经验---增加副本因子

1 基本副本信息

Kafka 副本作用:提高数据可靠性。
Kafka 默认副本1个，生产环境一般配置为2个，保证数据可靠性;太多副本会增加磁盘存储空间，增加网络上数据传输，降低效率。
Kafka 中副本分为: Leader 和 Follower。Kafka 生产者只会把数据发往 Leader,然后 Follower找 Leader 进行同步数据。(生产者和消费者都是针对leader进行操作)
Kafka 分区中的所有副本统称为AR (Assigned 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的。

选举过程详情看这篇文章：kafka-Broker-zk存储_SeaDhdhdhdhdh的博客-CSDN博客

实际操作示例图:

创建在kafka集群中创建 topic 为 atguigu2 的主题。并查看该主题信息，注意观察信息中的Isr部分。
现在将hadoop105关掉。
现在回到hadoop102查看topic为auguigu2的信息。

由上图可见，在关掉hadoop105以后，Isr集合中编号为3的broker节点被踢出了，同时原来leader节点为3的分区的leader节点变为2了。符合轮询的选举规则。
现在将hadoop104干掉。观察该topic详细信息。

同理，在关掉hadoop104以后，Isr结合中为2的broker节点被踢出。同时原来leader节点为2的分区的leader节点变为对应AR集合中的第一个broker节点了。符合轮询的选举规则。
现在恢复hadoop105。
注意观察该topic信息。

isr中多了hadoop105的broker节点信息，但是leader并没有变化，说明添加节点并没有进行重新选举。
恢复hadoop104以后的topic信息。

同第6步。
思考：现在如果将hadoop103干掉会出现什么结果？

leader节点为1的全部变为了3。符合选举规则。

3 Leader和Follower故障处理细节

LEO(Log End Offset)：每个副本的最后一个offset，LEO其实就是最新的offset+1。

HW(High Watermark)：所有副本中最小LEO。

3.1 Follower故障

Follower发生故障后会被临时踢出ISR
这个期间Leader和Follower继续接收数据
待该Follower恢复后，Follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向Leader进行同步。
等该Follower的LEO大于等于该Partition的HW，即Follower追上Leader之后，就可以重新加入ISR了。

3.2 Leader故障

Leader发生故障之后，会从ISR中选出一个新的Leader。
为保证多个副本之间的数据一致性，其余的Follower会先将各自的log文件高于HW的部分截掉，然后从新的Leader同步数据。

注意:这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。

4 分区副本分配

如果 kafka 服务器只有4个节点，那么设置kafka 的分区数大于服务器台数，在 kafka底层如何分配存储副本呢?

创建16个分区，3个副本:

启动hadoop102,103,104,105四台服务器，并在hadoop102上面创建新的topic：second。
查看该主题的信息

创建副本的的时候4个台服务器进行了四轮分配。每次分配法则都不一样，这样分配副本的好处是既可以保证负载均衡，有可以防止一台follower所在机器宕机引起某个分区的消息丢失。

5 生产经验---手动调整分区副本存储

在生产环境中，每台服务器的配置和性能不一致，但是Kafka只会根据自己的代码规则创建对应的分区副本，就会导致个别服务器存储压力较大。所有需要手动调整分区副本的存储。

需求:创建一个新的topic，4个分区，两个副本，名称为three。由于broker0和broker1两台服务器性能较好，所以决定将该topic的所有副本都存储到broker0 和 broker1 两台服务器上。

创建一个新的topic，名称为three。
创建完成以后查看分区和副本情况。

发现副本在每个broker上均匀存在。

创建副本存储计划（所有副本存储在broker0和broker1中）
创建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]}]

}

执行副本存储计划。
验证副本存储计划。
查看该topic分区和副本情况。

6 Leader Partition自动平衡(重要)

正常情况下，Kafka本身会自动把Leader Partition均匀分散在各个机器上，来保证每台机器的读写吞吐量都是均匀的。但是如果某些broker宕机，会导致Leader Partition过于集中在其他少部分几台broker上，这会导致少数几台broker的读写请求压力过高，其他宕机的broker重启之后都是follower partition，读写请求很低，造成集群负载不均衡。

auto.leader.rebalance.enable，默认是true。自动Leader Partition平衡
leader.imbalance.per.broker.percentage,默认是10%。每个broker允许的不平衡的leader的比率。如果每个broker超过了这个值，控制器会触发leader的平衡。
不平衡的leader的比率计算方法：
leader.imbalance.check.interval.seconds，默认值300秒。检查leader负载是否平衡的间隔时间。

7 生产经验---增加副本因子

在生产环境当中，由于某个主题的重要等级需要提升，我们考虑增加副本。副本数的增加需要先制定计划，然后根据计划执行。

创建topic：four，创建1个副本。

手动添加副本存储。

创建副本存储计划（所有副本都指定存储在broker0，broker1，broker2中）。
创建json文件。

写入存储计划。

{ 
    "version":1, 
    "partitions" :[ {"topic":"four","partition":0, "replicas":[1], "log_dirs":["any"]},                                                    
                    {"topic":"four","partition":1, "replicas":[0], "log_dirs":["any"]},     
                    {"topic":"four","partition":2, "replicas":[2], "log_dirs":["any"]}]
}