分布式流处理组件-生产实战：Broker副本与优化

最新推荐文章于 2024-11-12 15:32:21 发布

谢先生F

最新推荐文章于 2024-11-12 15:32:21 发布

阅读量114

点赞数

分类专栏：消息中间件文章标签：分布式 kafka java

本文链接：https://blog.csdn.net/weixin_51192504/article/details/132088005

版权

消息中间件专栏收录该内容

3 篇文章 0 订阅

订阅专栏

💯 作者：谢先生。 2014年入行的程序猿。多年开发和架构经验。专注于Java、云原生、大数据等技术。从CRUD入行，负责过亿级流量架构的设计和落地，解决了千万级数据治理问题。

📖 微信公众号、B站：搜索「谢先生说技术」不定时更新～

📂 清单： goku-framework、【定期开源】享阅读II

真的是好久都没有更新了，失业难过中😫

前言

在最开始我们就说过，Kafka中存储消息数据看似在向Topic写入，但其实Topic只是逻辑上的概念，实际上数据最终都以Partition为落点。随后Broker会对Partition中的存储数据做进一步操作。与此同时Producer和Consumer都是跟Partition的Leader角色进行数据发送与消费。

顾名思义，这都是我们之前了解过的

本章我们针对Broker中的副本信息作细致介绍。本节内容包括：

副本基本信息
副本间Leader选举与故障处理
Leader Partition自平衡处理
- 人为干预Partition分布策略

把我们零碎的知识汇总起来～

副本

副本信息

我们在创建Topic的时候，会设置对应的分区数与副本因子，为了保证整个集群的健康，默认情况下Kafka集群会将分区与副本均匀的每一个Broker节点上。

而一般情况下，Broker会将同一分区的Leader和Follower节点进行分离，这样主要为了保证：

为了防止当某个Broker节点出现宕机等问题，其余Follower能够快速升级。保证整个集群的高可用
为了提高数据的可靠性，避免由于单点故障而导致数据丢失等情况

这里需要注意的是：副本并不是说越多越好，如果副本数设置过多，会增加磁盘的存储空间，而且主从节点间的数据同步还会增加网络数据传输
这里建议：

建议副本数配置2，不要过多设置

故障处理

前面其实我们也提到过：分区Leader角色承担与Producer和Consumer的读写交互，而Follower会从Leader分区中进行数据同步。
但是我们必须能够想到：

如果由于出现网络或者Broker节点本身出现故障，导致分区无法正常交互，进而影响到整个集群健康

为了能够尽快对外提供服务，Kafka也提供了故障处理机制。我们先从Leader故障处理来看：

Leader故障处理

当Leader发生故障之后，首先Controller控制器会从ZK中查询该分区下的所有副本的LEO，某个最大LEO所在的Broker将会被选举为Leader角色

选举原则一：副本数据保存最全

如果存在多个副本的LEO相同，则Controller将会从ISR列表中选择一个副本所在Broker为Leader。

ISR：同步副本队列，当前集合表示其它副本及时于Leader进行数据同步，同步数据基本赶上了Leader的数据

如果ISR中不存在集合数据，那么将选择所有副本中第一个在线的Broker作为Leader。

为了保证副本数据间的一致性，此时其它Follower需要与新的Leader进行数据同步：

其它Follower会先将各自的log文件中高于HW的部分截取，然后开始从新的Leader同步

Follower故障处理

接下来我们看看当Follower出现故障之后会出现的问题：

首先，Follower无法正常与Leader进行心跳且无法正常拉取数据，那么当等待replica.lag.time.max.ms时间之后将会被提出ISR列表

等待该Follower正常恢复之后，由于Leader还在正常处理消息中，必然会出现消息同步不及时的问题。

此时当前Follower节点会读取本地磁盘记录的HW，并将log记录中高于HW的部分进行截取，然后从HW的位置开始从Leader进行同步
等待当前Follower的LEO与该Partition的HW持平，那么表示当前Follower可以重新加入到ISR集合中

Leader分区自平衡机制

自平衡是Kafka在处理分区均匀分散的一种非常重要的机制。Kafka本身会通过该机制将Partition均匀分散在每个Broker节点上。这样能够保证每个Broker节点的读写吞吐量都是平均的。

但是如果某些Broker节点故障出现宕机等问题，Controller会快速对Leader和Follwer进行故障恢复处理，此时Partition容易集中在部分Broker节点上。

这样就会导致部分Broker节点的读写请求压力过高
而当Broker节点重启恢复之后，大概率都是Follower分区，这些节点上读写请求非常低。
这样就很大程度上会造成集群负载不均衡。
现在我们来看看Kafka是如何解决这种问题的～

核心参数

为了防止出现上述问题，kafka提供三个配置项：

auto.leader.rebalance.enable
当前参数默认为true，也就是说默认自动开启LeaderPartition平衡检测机制。

其实在生产环境我们一般推荐将参数设置为false
如果出现频繁自平衡调整，将会导致整个集群性能严重下降

leader.imbalance.per.broker.percentage
每个Broker允许的不平衡的比率。如果broker超过了设置的值，那么Controller就会触发自动平衡进行调整

默认10%，如果非要开启auto.leader.rebalance.enable，建议将该值设置的略大一些

leader.imbalance.check.interval.seconds

一般情况下比率与间隔时间都是相辅出现的: 如果迟迟没有达到leader.imbalance.per.broker.percentage设置的值，那么Broker将在等待leader.imbalance.check.interval.seconds之后检查集群是否平衡

检查每个Broker节点下Leader Partition是否平衡的间隔时间。默认为300秒

人为干预副本分配

手动调衡副本的方式其实非常简单，我们在上一节《Broker节点负载》中也介绍过执行命令，回忆回忆：

kafka-reassign-partitions.sh

操作流程如下

编写副本存储计划

{
    "version": 1,
    "partitions": [
        {
            "topic": "",           // topic名称
            "partition": 0/1/2/3,  // 分区号
            "replicas": [0,1]      // 想要放的broker节点
        }
    ]
}

执行当前计划

kafka-reassign-partitions.sh --bootstrap-server master:9092 --reassignment-json-file jsonfile.json --execute

对当前执行计划进行校验

kafka-reassign-partitions.sh --bootstrap-server master:9092 --reassignment-json-file b.json --verify

如此这般，就能实现手动管理副本的功能。

最后

到此本节内容结束，基于概念性内容居多，希望大家多看多理解。
后面为大家介绍关于Broker中消息数据的存储与过期等内容。期待～