分布式专题|最近一直死磕kafka设计原理,都肝吐了

kafka架构图

在这里插入图片描述

kafka核心控制器

定义

在kafka集群中,会选举出一个broker作为控制器(controller),负责管理集群中所有的分区和副本的状态;

职责

  1. 监听broker变化,通过监听Zookeeper中的/brokers/ids/ 节点方式来实现
  2. 监听topic变化,通过监听Zookeeper中的/brokers/topics节点方式来实现,实时监听topic变化
  3. 管理topic、partition、broker相关的信息
  4. 更新数据的元数据信息,同步到其他的broker节点

选举过程

broker控制器选举的原理是借助于zookeeper的临时节点实现:
kafka集群启动时,每个broker都会尝试争当控制器,都会往zookeeper的controller节点注册自己,但是由于zookeerper的特性,如果节点已经创建过,再创建就会失败,所以只会有一个broker创建成功,那么创建成功的broker就会成为控制器;此外其他broker都会监听这个controller节点

在这里插入图片描述

由于controller是临时节点,当控制器broker挂机之后,就会断开与zookeeper的会话连接,临时节点也会消失,其它节点监听到controller节点消失后,就会重新争取controller节点。
在这里插入图片描述

Partition副本选择机制

当controller感知到副本leader所在的broker宕机之后,会在当前副本所在的副本列表中选出第一个副本所在的broker作为副本leader,并且要保证这个broker一定要在副本的ISR(存活的副本broker)集合中,如果第一个不存在,则继续尝试第二个第三个,直到满足;不知道为啥kafka作者为什么不直接在ISR集合里面挑,非得多一步操作

消费者消费的offset如何记录?

每个消费者消费所在分区的offset都会记录在kafka的内部topic中(__consumer_offsets),kafka默认会为这个topic创建50个分区,用来抵抗高并发;
提交到这个topic的时候,key是当前消费者所处的消费组ID+topic+分区号,value就是当前offset的值,那么kafka会把这个消息发送到哪个分区呢,是由以下公式决定的:
hash(consumer group id) % __consumer_offsets主题的分区数(默认50),consumer每次消费前都会从这里获取offset值;

什么是消费者rebalance?

定义

当某个消费组中的消费者挂掉或退出之后,此时就会自动把分配给它的分区分配给其它消费者(没有被指定消费分区的消费者),不仅如此,当有新的消费者加入后也会触发rebalance操作。

Rebalance过程

  1. 选择组协调器(GroupCoordinato)
    因为每个消费组的消费offset提交到的分区是确定的,即通过公式hash(consumer group id) % __consumer_offsets主题的分区数计算而来,所以kafka就直接把这个提交的分区所在的副本leader当作组协调器。

  2. 加入消费组 JOIN GROUP
    在选好组协调器之后,接下来就是加入消费组阶段,在此阶段的消费者会向 GroupCoordinator 发送 JoinGroupRequest 请求,并处理响应,然后GroupCoordinator 从一个consumer group中选择第一个加入group的consumer作为leader(消费组协调器),把consumer group情况发送给这个leader,接着这个leader会负责制定分区方案。

  3. SYNC GROUP
    consumer leader通过给GroupCoordinator发送SyncGroupRequest,接着GroupCoordinator就把分区方案下发给各个consumer,他们会根据指定分区的leader broker进行网络连接以及消息消费。

Rebalance分区分配策略

通过在消费者客户端配置参数partition.assignment.strategy 来设置分配策略,默认为range

  • range
    假如现在有10个分区,4个消费者,那么第一步计算平均每个消费者分配的分区数:10/4 = 2,这样每个消费者分到两个分区,还剩余 2 个分区,那么把剩下的两个分区分别分给前面两个消费者,最终分配结果:
    第一个消费者:0,1,2
    第二个消费者:3,4,5
    第三个消费者:6,7
    第四个消费者:8,9

  • round-robin(轮询分配)
    很容易理解,同上有10个分区,4个消费者:
    第一个消费者:0,4,8
    第二个消费者:1,5,9
    第三个消费者:2,6
    第四个消费者:3,7

  • sticky

    • 分区尽可能均匀
    • 分区的分配尽可能与上次分配相同

    假如目前分区分配如下:

    第一个消费者:0,4,8
    第二个消费者:1,5,9
    第三个消费者:2,6
    第四个消费者:3,7

    现在如果第四个消费者挂机,则重新分配后如下:
    第一个消费者:0,4,8,7
    第二个消费者:1,5,9
    第三个消费者:2,6,3

    如果两个规则冲突,优先保证第一个原则

producer发布消息过程

  1. 写入方式
    生产者使用push模式将消息发布到broker中,每条消息都被追加到partition中,属于顺序写磁盘
  2. broker根据以下规则将消息发布到指定分区中
  • 如果指定分区,则直接发到指定分区
  • 如果没有指定分区,则根据key进行hash 取模分区数,得到分区
  • key和partition 都没有指定,则使用轮训方式
  1. 发送流程
    在这里插入图片描述

重要参数acks解释:

  • ack=0
    指producer把消息发送出去,不需要等待任何回应,就认为消息发送成功
  • ack=1
    指producer把消息发送到leader之后,leader把消息写入磁盘,并回复producer ACK,则producer就认为消息发送成功
  • ack=all/-1
    指producer把消息发送到leader之后,leader写入磁盘后,还要等待其他副本的ACK,只有都写成功了,leader才给producer回复ACK,这时producer才认为消息发送成功
  1. producer从zookeeper的state节点中中找到副本leader所在brokerid
  2. producer把消息发送到该leader
  3. leader将消息写入log
  4. follower从leader拉取消息,写入本地log后向leader回复ack
  5. leader收到所有ISR里面的副本恢复ACK之后,增加HW,并向producer发送ACK

HW与LEO到底是个啥?

HW俗称高水位,又称消费能消费到的最大offset,LEO是broker内部能看到的最大offset, 那么这个最大的offset是怎么产生的呢?
正常情况下,LEO的offset和HW的offset是相同的
当有新消息发送到leader之后,leader的LEO就会增加,这个时候LEO的offset就与HW的offset不一样了,接下来副本开始拉取leader消息,对应的副本LEO也会增加,等到最后一个副本同步完成消息之后,LEO和HW的offset就会一致,这样做的目的是什么呢?是为了数据的一致性,保证消息同步完成后才能对消费者可见。
在这里插入图片描述

微信搜一搜【乐哉开讲】关注帅气的我,回复【干货领取】,将会有大量面试资料和架构师必看书籍等你挑选,包括java基础、java并发、微服务、中间件等更多资料等你来取哦。

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 黑客帝国 设计师:上身试试 返回首页