面试系列-kafka基础组件及其关系

基础组件

broker

服务器节点，每个服务器上可以有一个或多个kafka的实例，共同组成kafka集群；一个broker可以容纳多个topic，broker之间的地位是对等的，无主从之分；

topic

物理上不同topic的消息分开存储，逻辑上一个topic的消息保存在一个或者多个broker上；

partition

一个大的topic会被分解为多个partition分配到多个broker上，partition上的每条消息都会有一个自增id（offset）, 单个partition上的消息具有顺序性，多个同级的partition上不具有顺序性，在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1；如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition，在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡；每个partition中的数据使用多个segment文件存储；

消费者应该小于等于该主题下的分区数：

• Partition = 消费任务的并发度=刚刚好，每个任务读取一个partition数据；
• Partition >消费任务的并发度=有部分消费任务读取多个分区的数据；
• Partition < 消费任务的并发度=有部分消费任务空闲；

任何时候，分区中的一条数据只能被一个消费组中的一个消费任务读取；分区数越多，同一时间可以有越多的消费者来进行消费，消费数据的速度就会越快，提高消费的性能；

offset

消息在partition中的位置，offset自增；

replica

控制消息保存在几个broker（服务器）上，topic的partition含有N个副本replica，N为副本因子，其中一个副本为leader（主副本），其他的为follower（从副本），leader处理partition上的所有读写请求，follower定期同步leader上的数据；一般情况下等于broker的个数，副本因子应该小于等于可用的broker数；

数据副本数一般情况下小于等于broker的个数，每个分区都有各自的主副本（在哪里复制的）和从副本（复制出来的），follower通过拉的方式从leader同步数据， 消费者和生产者都是从leader读写数据，不与follower交互，副本只用来提高集群的可靠性，一个挂掉（主副本），不会在其他的broker中，另启动一个副本，丢失的副本不会恢复；

zookeeper集群

存放kafka集群元数据，zk集群会保存topic、broker、消费者的状态信息，生产者负载均衡，消费者负责均衡；zookeeper保证了Kafka系统可用性，一旦controller所在broker宕机了，此时临时节点消失，集群里其他broker会一直监听这个临时节点，发现临时节点消失了，就争抢再次创建临时节点，保证有一台新的broker会成为controller角色；broker依然依赖于zk，zookeeper在kafka中还用来选举controller和检测broker是否存活等；

Kafka Controller

在kafka集群中有一个broker会被选举为控制器（kafka controller），它负责管理整个集群中所有分区和副本的状态；

当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本。当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有broker更新其元数据信息。当使用kafka-topics.sh脚本为某个topic增加分区数量时，同样还是由控制器负责分区的重新分配；

kafka中的控制器选举工作依赖于zookeeper，成功竞选为控制器的broker会在zookeeper中创建/controller这个临时节点；

在任意时刻，集群中有且仅有一个控制器。每个broker启动的时候会去尝试去读取/controller节点的brokerid的值，如果读取到brokerid的值不为-1，则表示已经有其它broker节点成功竞选为控制器，所以当前broker就会放弃竞选；如果zookeeper中不存在/controller这个节点，或者这个节点中的数据异常，那么就会尝试去创建/controller这个节点，当前broker去创建节点的时候，也有可能其他broker同时去尝试创建这个节点，只有创建成功的那个broker才会成为控制器，而创建失败的broker则表示竞选失败；