网站建设比较合理的流程是,免费网站建站百度云,小木桥路建设工程招投标网站,北京哪里可以做网站这里写自定义目录标题 Broker概述Broker总体工作流程Broker重要参数 Controller为什么需要Controller具体作用数据服务Leader选举选举流程脑裂问题羊群效应触发leader选举 Broker
概述
Kafka服务实例#xff0c;负责消息的持久化、中转等功能。一个独立的Kafka 服务器被就是… 这里写自定义目录标题 Broker概述Broker总体工作流程Broker重要参数 Controller为什么需要Controller具体作用数据服务Leader选举选举流程脑裂问题羊群效应触发leader选举 Broker
概述
Kafka服务实例负责消息的持久化、中转等功能。一个独立的Kafka 服务器被就是一个broker。
broker 是集群的组成部分。每个集群都有一个broker 同时充当了集群控制器Controller的角色。
kafka使用ZookeeperZK进行元数据管理保存broker注册信息包括主题Topic、分区Partition信息等选择分区leader在低版本kafka消费者的offset信息也会保存在ZK中。
在每一个Broker在启动时都会像向ZK注册信息ZK会选取一个最早注册的Broker作为Controller后面Controller会与ZK进行数据交互获取元数据即整个Kafka集群的信息例如有那些Broker,每个Broker中有那些Partition等信息并负责管理工作包括将分区分配给broker 和监控broker其他Broker是与Controller进行交互进而感知到整个集群的所有信息。
Broker总体工作流程 流程如下
broker 启动后向 ZK 集群进行注册各个 broker 的 controller 抢占 ZNode抢占到的 Controller 监听 brokers 节点的变化Controller 决定 Leader 的选举规则在 isr 中存活的 broker按照 AR 中排在前面的优先Controller 将节点信息上传到 ZK其他 controller 从 ZK 同步相关信息假设此时 broker1 中的 Leader 挂了Controller 监听到了节点变化从 ZK 中获取 ISR选举出新的 Leader向 ZK 更新 Leader 和 ISR
Broker重要参数
介绍完 Broker 的工作流程给大家总结一下Broker 在工作过程中涉及到的一些参数
参数描述replica.lag.time.max.msISR 中如果 Follower 长时间未向 Leader 发送通信请求或同步数据则该 Follower 将被踢出 ISR默认 30sauto.leader.rebalance.enable默认是 true。自动 Leader Partition 平衡leader.imbalance.per.broker.percentage默认是 10%。每个 broker 允许的不平衡的 leader 的比率。如果每个 broker 超过了这个值会触发 leader 的平衡leader.imbalance.check.interval.seconds默认值 300 秒。检查 leader 负载是否平衡的间隔时间log.segment.bytesKafka 中 log 日志是分成一块块存储的此配置是指 log 日志划分成块的大小默认值 1Glog.index.interval.bytes默认 4kb每当写入了 4kb 大小的日志 (.log)然后就往 index 文件里面记录一个索引log.retention.hoursKafka 中数据保存的时间默认 7 天log.retention.minutesKafka 中数据保存的时间分钟级别默认关闭log.retention.msKafka 中数据保存的时间毫秒级别默认关闭log.retention.check.interval.ms检查数据是否保存超时的间隔默认是 5 分钟log.retention.bytes默认等于 -1表示无穷大。超过设置的所有日志总大小删除最早的 segmentlog.cleanup.policy默认是 delete表示所有数据启用删除策略; 如果设置值为 compact表示所有数据启用压缩策略num.io.threads默认是 8。负责写磁盘的线程数。整个参数值要占总核数的 50%num.replica.fetchers副本拉取线程数这个参数占总核数的 50%的 1/3num.network.threads默认是 3。数据传输线程数这个参数占总核数的 50%的 2/3log.flush.interval.messages强制页缓存刷写到磁盘的条数默认是 long 的最大值。不建议修改log.flush.interval.ms每隔多久刷数据到磁盘默认是 null。不建议修改
Controller
为什么需要Controller
在Kafka早期版本对于分区和副本的状态的管理依赖于zookeeper的Watcher和队列每一个broker都会在zookeeper注册Watcher所以zookeeper就会出现大量的Watcher, 如果宕机的broker上的partition很多比较多会造成多个Watcher触发造成集群内大规模调整每一个replica都要去再次zookeeper上注册监视器当集群规模很大的时候zookeeper负担很重。这种设计很容易出现脑裂和羊群效应以及zookeeper集群过载。
新的版本中该变了这种设计使用KafkaController只有KafkaControllerLeader会向zookeeper上注册Watcher其他broker几乎不用监听zookeeper的状态变化。
Kafka集群中多个broker有一个会被选举为controller leader负责管理整个集群中分区和副本的状态比如partition的leader 副本故障由controller 负责为该partition重新选举新的leader 副本当检测到ISR列表发生变化有controller通知集群中所有broker更新其MetadataCache信息或者增加某个topic分区的时候也会由controller管理分区的重新分配工作。
具体作用
控制器在 Kafka 中是起协调作用的组件那么控制器的作用大致可以分为 5 种
1.Topic管理
这里说的To这里说的Topic管理是指控制器帮助我们完成对 Kafka 主题的创建、删除以及分区增加的操作, 大部分的后台工作都是控制器来完成的。
2.分区重分配
当一个新的 broker 刚加入集群时不会自动地分担己有 topic 的负载它只会对后续新增的 topic 生效。
如果要让新增 broker 为己有的 topic 服务用户必须手动地调整现有的 topic 的分区分布将一部分分区搬移到新增 broker 上。这就是所谓的分区重分配reassignment操作。
除了处理 broker 扩容导致的不均衡之外再均衡还能用于处理 broker 存储负载不均衡的情况在单个或多个 broker 之间的日志目录之间重新分配分区。用于解决多个代理之间的存储负载不平衡。
3.Leader选 触发分区 leader 选举的几种场景
Offline创建新分区或分区失去现有 leaderReassign用户执行重分配操作PreferredReplica将 leader 迁移回首选副本ControlledShutdown分区的现有 leader 即将下线
当上述几种情况发生时Controller 会遍历所有相关的主题分区并为其指定新的 Leader。然后向所有包含相关主题分区的 Broker 发送更新请求其中包含了最新的 Leader 与 Follower 副本分配信息。待更新完毕后新 Leader 会开始处理来自生产者和消费者的请求而 Follower 开始从新 Leader 那里复制消息。
4.集群成员管理
这是控制器提供的集群成员管理功能, 主要包括自动检测新增 Broker、Broker 主动关闭及被动宕机, 而这种自动检测主要是依赖于 Watch 通知功能和 ZooKeeper 临时节点组合实现的。
比如控制器组件会利用 Watch 机制 检查 ZooKeeper 的 /brokers/ids 节点下的子节点数量变更。目前当有新 Broker 启动后它会在 /brokers 下创建 临时的 znode 节点。一旦创建完毕ZooKeeper 会通过 Watch 机制将消息通知推送给控制器这样控制器就能自动地感知到这个变化。
5.提供数据服务
控制器会向其他 Broker 提供数据服务。控制器上保存了最全的集群元数据信息其他所有 Broker 会定期接收控制器发来的元数据更新请求从而更新其内存中的缓存数据。
数据服务
上面说了Controller会提供Broker节点及Topic等数据的信息下面具体能提供哪些 从上面表格可以看出,存储的大概有3大类:
所有topic信息包括具体的分区信息比如 Leader 副本是谁ISR 集合中有哪些副本等。所有 Broker 信息包括当前都有哪些运行中的 Broker哪些正在关闭中的 Broker 等。涉及运维任务的副本分区包括当前正在进行 Preferred Leader选举以及分区重分配的分区列表等。
数据实际存储在ZK之中。
其中/brokers/ids/[0...n]是使用临时节点存储在线的是各个服务节点的信息当下线后自动删除
/brokers/seqid辅助生成的brokerId当用户没有配置broker.id时ZK会自动生成一个全局唯一的id。
/brokers/topics/{topicName}持久化数据节点存储topic的分区副本分配信息
在/brokers/topics/{topicName}//partitions/0/state中记录了leader和isr队列的内容
Leader选举
选举流程
这里需要先明确一个概念leader选举因为kafka中涉及多处选举机制容易搞混kafka由三个方面会涉及到选举
broker控制器选leader分区多副本选leader消费者选leader
这里我们说的是 leader选举是controller的选举。
Broker 在启动时会尝试去 ZooKeeper 中创建 /controller 节点。Kafka 当前选举控制器的规则是第一个成功创建 /controller 节点的 Broker 会被指定为控制器。
但是当Controller节点挂了之后需要选举出新的controller。
Broker的leader选举过程与故障处理
集群中第一个启动的broker会在zookeeper中创建临时节点/controller来让自己成为控制器当其他的broker启动也会在zookeeper中创建临时节点/controller但是会发现节点已经存在此时会受到一个异常此时就会在zookeeper中创建一个watch对象方便这些broker接受leader的变更消息如果主leader因为网络问题与zookeeper断开连接或者发生异常退出了其他的broker就可以通watch接收到控制器的变更通知开始尝试去创建临时节点/controller如果有一个broker创建成功了就和上面说的一样其他的broker也会收到异常通知此时就说明集群中broker的leader已经确定其他的broker只能创建watch对象了集群中broker的leader发生异常退出在选举出新的leader之后会检测这个异常的broker上面是否有分区副本的leader如果有就是发起分区的leader选举选出新的分区leader然后更新ISR队列数据
示例 图片来源https://mp.weixin.qq.com/s/tTKXb6On5bfJGjcvn9IpbA
如上图所示: 最开始时候Broker 0 是控制器。当 Broker 0 被检测宕机后ZooKeeper 通过 Watch 机制感知到并删除了 /controller 临时节点。之后所有还存活的 Broker 开始竞选新的控制器。这时 Broker 3 最终赢得了选举成功地在 ZooKeeper 上重建了 /controller 临时节点。Broker 3 会从 ZooKeeper 中读取集群元数据信息并初始化到自己的缓存中。控制器的 Failover 完成这时候就可以正常工作了。
脑裂问题
所谓的脑裂问题也就是出现了多个大脑就是leader。比如因为网络或者其他的原因导致leader出现假死状态此时会触发leader选举这样就会出现两个leader。
broker的leader主要是用于管理主题的那些发生脑裂之后创建主题、增加分区的操作都会报错但是现有的主题的读写是不影响的这是因为读写是获取分区的元数据在任意一个broker中有可以拿到。
脑裂如何产生
broker是通过抢占的方式在zookeeper中注册临时节点/controller来时实现的先到先得。
由于zookeeper的临时节点的有效性是通过session来判断的若在session timeout时间内
controller所在broker网络故障controller 进行full gcSTW时间过长超过zookeeper session timeout 出现假死
则会出现脑裂问题。
kafka的解决方案
为了解决Controller脑裂问题zookeeper中有一个持久节点/controller_epoch存放的是一个整形值的epoch number纪元编号也称为隔离令牌集群中每选举一次控制器就会通过Zookeeper创建一个数值更大的epoch number如果有broker收到比这个epoch数值小的数据就会忽略消息。
羊群效应
在早期的kafka版本中如果宕机的那个Broker上的Partition比较多 会造成多个Watch被触发造成集群内大量的调整导致大量网络阻塞这种羊群效应会导致zookeeper过载的隐患。
之后kafka引入controller的概念也就是broker的leader来对分区副本的状态进行管理当某个分区的leader副本出现故障时由控制器负责为该分区选举新的leader副本。当检测到某个分区的ISR集合发生变化时由控制器负责通知所有broker更新其元数据信息。
在使用zookeeper的分布式中这种脑裂和羊群效应都是不可避免的。
触发leader选举
现阶段的kakfa集群中只需要broker的leader在zookeeper去注册相应的监听器其他的broker很少去监听zookeeper的数据变化但是每个broker还是需要对/controller进行监听当/controller节点发生数据变化的时候每个broker都会更新自身内存中保存的activeControllerId。
当/controller节点被删除时集群中的broker会进行选举如果broker在节点被删除前是控制器的话在选举前还需要有一个下线的操作关闭相应的资源比如关闭状态机、注销相应的监听器等。如果有特殊需要可以手动删除/controller节点来触发新一轮的选举。当然关闭控制器所对应的broker以及手动向/controller节点写入新的brokerid的所对应的数据同样可以触发新一轮的选举。
参考https://mp.weixin.qq.com/s/uI2zkf74KXsWaCOplX1Ing
https://mp.weixin.qq.com/s/oxb2Ezn4K2jMPzubqFULuw
https://mp.weixin.qq.com/s/tTKXb6On5bfJGjcvn9IpbA
https://mp.weixin.qq.com/s/CCAP8n0mTCrUT-NzOAacCg
