kafka详解

Hommi
249 阅读5分钟

kafka

核心概念

  • Broker（服务端）：消息中间件处理节点，一个Kafka节点就是一个broker，一个或者多个Broker可以组成一个Kafka集群
  • Topic：Kafka根据topic对消息进行归类，发布到Kafka集群的每条消息都需要指定一个topic
  • Producer：消息生产者，向Broker发送消息的客户端
  • Consumer：消息消费者，从Broker读取消息的客户端
  • ConsumerGroup：每个Consumer属于一个特定的Consumer Group，一条消息可以被多个不同的Consumer Group消费 但是一个Consumer Group中只能有一个Consumer能够消费该消息
  • Partition：物理上的概念，一个topic可以分为多个partition，每个partition内部消息是有序的，Partition是一个有序的message序列，这些message按顺序添加到一个叫做commit log的文件中，每个partition，都对应一个commit log文件。每个consumer是基于自己在commit log中的消费进度(offset)来进行工作的。在kafka中，消费offset由consumer自己来维护

如图所示：

kafka结构.png

消费模式

  • 单播消费：一条消息只能被某一个消费者消费的模式，类似queue模式，只需让所有消费者在同一个消费组里即可。分别在两个客户端执行如下消费命令，然后往主题里发送消息，结果只有一个客户端能收到消息
  • 多播消费：一条消息能被多个消费者消费的模式，类似publish-subscribe模式费，针对Kafka同一条消息只能被同一个消费组下的某一个消费者消费的特性，要实现多播只要保证这些消费者属于不同的消费组即可。

重要参数：

  • current-offset：当前消费组的已消费偏移量
  • log-end-offset：主题对应分区消息的结束偏移量(HW)
  • lag：当前消费组未消费的消息数

消息存储机制

文件结构：xx.index xx.log xx.timeindex

Kafka 一个分区的消息数据对应存储在一个文件夹下，以topic名称+分区号命名，消息在分区内是分段(segment)存储，每个段的消息都存储在不一样的log文件里。每从log文件写入4kb（看配置）的消息，将对应一个索引写入index文件,并将时间点写入timeindex文件。

设计原理

消费者Rebalance机制

概念：如果消费组里的消费者数量有变化或消费的分区数有变化，kafka会重新分配消费者消费分区的关系。比如consumer group中某个消费者挂了，此时会自动把分配给他的分区交给其他的消费者，如果他又重启了，那么又会把一些分区重新交还给他。

什么情况引起rebalacne？

  • 消费组里的consumer增加或减少了
  • 动态给topic增加了分区
  • 消费组订阅了更多的topic

rebalance分配策略：

  • range（默认）：按分区序号排序，假设一个主题有10个分区(0-9)，现在有三个consumer消费。假设 n＝分区数／消费者数量 = 3， m＝分区数%消费者数量 = 1，那么前 m 个消费者每个分配 n+1 个分区，后面的（消费者数量－m ）个消费者每个分配 n 个分区。
  • round-robin：轮询分配，比如分区0、3、6、9给一个consumer，分区1、4、7给一个consumer，分区2、5、8给一个consumer
  • sticky：与round-robin类似。

Rebalance过程

第一阶段：选择组协调器(选消费者组长)

1、选个kafka集群的组长GroupCoordinator：consumer消费的offset要提交到__consumer_offsets的哪个分区，这个分区leader对应的broker就是这个consumer group的coordinator
2、kafka组长去选消费组的组长：谁先连kafka集群组长的速度最快为消费者组组长

第二阶段：加入消费组JOIN GROUP：

消费者组长制定分区方案，并返回给kafka组长

第三阶段（ SYNC GROUP)

kafka组长将分区方案同步给其他消费者：kafka组长通过心跳机制，谁还连着，就给谁发分区方案

注意：rebalance过程中，消费者无法从kafka消费消息

Kafka核心总控制器Controller（Leader）

在Kafka集群中会有一个或者多个broker，其中有一个broker会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态

功能：

  • 当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本。

  • 当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有broker更新其元数据信息。

  • 当使用kafka-topics.sh脚本为某个topic增加分区数量时，同样还是由控制器负责让新分区被其他节点感知到。

如何选举?

  • 启动时 集群中每个broker都会尝试在zookeeper上创建一个controller临时节点 zookeeper会保证有且仅有一个broker能创建成功，这个broker就会成为集群的总控器controller
  • controller宕机时 此时zookeeper临时节点会消失，集群里其他broker会一直监听这个临时节点，发现临时节点消失了，就竞争再次创建临时节点，就是我们上面说的选举机制zookeeper又会保证有一个broker成为新的controller

Partition副本选举Leader机制

controller感知到分区leader所在的broker挂了(controller监听了很多zk节点可以感知到broker存活)，controller会从ISR列表(参数unclean.leader.election.enable=false的前提下)里挑第一个broker作为leader(第一个broker最先放进ISR列表，可能是同步数据最多的副本)

副本进入ISR列表有两个条件;

  • 副本节点不能产生分区，必须能与zookeeper保持会话以及跟leader副本网络连通
  • 副本能复制leader上的所有写操作，并且不能落后太多。(与leader副本同步滞后的副本，是由 replica.lag.time.max.ms 配置决定的，超过这个时间都没有跟leader同步过的一次的副本会被移出ISR列表)

消费者消费消息的offset记录机制

每个consumer会定期将自己消费分区的offset提交给kafka内部topic： __consumer_offsets，提交过去的时候，key是consumerGroupId+topic+分区号，value就是当前offset的值

通过如下公式可以选出consumer消费的offset要提交到__consumer_offsets的哪个分区

hash(consumerGroupId)  %  __consumer_offsets主题的分区数
avatar
文章
阅读
粉丝