kafka基础知识扫盲

Bertha 。 2021-11-04 14:50 438阅读 0赞

**1.kafka的主题会分为多个区，生产者发送到kafka的同一主题的消息会分散到多个区，这其中有几个策略**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h3MTIwMjE5_size_16_color_FFFFFF_t_70]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h3MTIwMjE5_size_16_color_FFFFFF_t_70 1]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h3MTIwMjE5_size_16_color_FFFFFF_t_70 2]  
实现的原理也很简单

List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
    		return Math.abs(key.hashCode()) % partitions.size();

简单来说是通过hashcode对分区数量取余。  
最常用的是按照key来区分消息的策略，可以保证消息的顺序性，kafka消息的特点是分区内有序，整体有序是保证不了的。

**2 zookeeper在kafka中的作用**

1、Broker注册  
Broker是分布式部署并且相互之间相互独立，但是需要有一个注册系统能够将整个集群中的Broker管理起来，此时就使用到了Zookeeper。在Zookeeper上会有一个专门用来进行Broker服务器列表记录的节点：  
/brokers/ids  
每个Broker在启动时，都会到Zookeeper上进行注册，即到/brokers/ids下创建属于自己的节点，如/brokers/ids/\[0…N\]。  
broker创建的是临时节点，一旦宕机，broker的节点就会删除  
2、Topic注册  
在Kafka中，同一个Topic的消息会被分成多个分区并将其分布在多个Broker上，这些分区信息及与Broker的对应关系也都是由Zookeeper在维护，由专门的节点来记录，如：  
/borkers/topics  
Kafka中每个Topic都会以/brokers/topics/\[topic\]的形式被记录，如/brokers/topics/login和/brokers/topics/search等。Broker服务器启动后，会到对应Topic节点（/brokers/topics）上注册自己的Broker ID并写入针对该Topic的分区总数，如/brokers/topics/login/3->2，这个节点表示Broker ID为3的一个Broker服务器，对于"login"这个Topic的消息，提供了2个分区进行消息存储，同样，这个分区节点也是临时节点。

3.分区 与 消费者 的关系  
消费组 (Consumer Group)：  
consumer group 下有多个 Consumer（消费者）。  
对于每个消费者组 (Consumer Group)，Kafka都会为其分配一个全局唯一的Group ID，Group 内部的所有消费者共享该 ID。订阅的topic下的每个分区只能分配给某个 group 下的一个consumer(当然该分区还可以被分配给其他group)。  
同时，Kafka为每个消费者分配一个Consumer ID，通常采用"Hostname:UUID"形式表示。  
在Kafka中，规定了每个消息分区 只能被同组的一个消费者进行消费，因此，需要在 Zookeeper 上记录 消息分区 与 Consumer 之间的关系，每个消费者一旦确定了对一个消息分区的消费权力，需要将其Consumer ID 写入到 Zookeeper 对应消息分区的临时节点上，例如：  
/consumers/\[group\_id\]/owners/\[topic\]/\[broker\_id-partition\_id\]  
其中，\[broker\_id-partition\_id\]就是一个 消息分区 的标识，节点内容就是该 消息分区 上 消费者的Consumer ID。  
4.消费者注册  
消费者服务器在初始化启动时加入消费者分组的步骤如下  
注册到消费者分组。每个消费者服务器启动时，都会到Zookeeper的指定节点下创建一个属于自己的消费者节点，例如/consumers/\[group\_id\]/ids/\[consumer\_id\]，完成节点创建后，消费者就会将自己订阅的Topic信息写入该临时节点。  
对 消费者分组 中的 消费者 的变化注册监听。每个 消费者 都需要关注所属 消费者分组 中其他消费者服务器的变化情况，即对/consumers/\[group\_id\]/ids节点注册子节点变化的Watcher监听，一旦发现消费者新增或减少，就触发消费者的负载均衡。  
对Broker服务器变化注册监听。消费者需要对/broker/ids/\[0-N\]中的节点进行监听，如果发现Broker服务器列表发生变化，那么就根据具体情况来决定是否需要进行消费者负载均衡。  
进行消费者负载均衡。为了让同一个Topic下不同分区的消息尽量均衡地被多个 消费者 消费而进行 消费者 与 消息 分区分配的过程，通常，对于一个消费者分组，如果组内的消费者服务器发生变更或Broker服务器发生变更，会发出消费者负载均衡。

**3.什么时候触发再均衡？**  
消费者宕机或者新增消费者，（扩展消费组内的消费者与分区关系是固定的，且一个分区只能绑定一个消费者）。  
**4.kafka 控制器选举流程**  
抢占式：kafka的控制器选举很简单，kafka的每一个broker都有一个ID唯一标识符，在集群启动的时候会把id注册到zookeeper的/broker/ids/节点下作为临时子节点，节点的增加和删除其他子节点都会得到通知，第一个启动的broker会在zookeeper里创建一个临时节点/controll让自己成为控制器，其他后续节点启动的也会创建，当发现已经存在这个临时节点了那么会抛出异常，会意识到此时节点已经存在，那么后续的broker会在这个控制器节点创建watch事件，用来监听控制器状态，如果控制器的broker挂掉了，其他节点有机会成为控制器  
**5.kafka 分区leader选举过程**  
Controller在Zookeeper注册Watch，一旦有Broker宕机（这是用宕机代表任何让系统认为其die的情景，包括但不限于机器断电，网络不可用，GC导致的Stop The World，进程crash等），其在Zookeeper对应的znode会自动被删除，Zookeeper会fire Controller注册的watch，Controller读取最新的幸存的Broker  
2.Controller决定set\_p，该集合包含了宕机的所有Broker上的所有Partition  
3.对set\_p中的每一个Partition  
3.1 从/brokers/topics/\[topic\]/partitions/\[partition\]/state读取该Partition当前的ISR  
3.2 决定该Partition的新Leader。如果当前ISR中有至少一个Replica还幸存，则选择其中一个作为新Leader，新的ISR则包含当前ISR中所有幸存的Replica（选举算法的实现类似于微软的PacificA）。否则选择该Partition中任意一个幸存的Replica作为新的Leader以及ISR（该场景下可能会有潜在的数据丢失）。如果该Partition的所有Replica都宕机了，则将新的Leader设置为-1。  
3.3 将新的Leader，ISR和新的leader\_epoch及controller\_epoch写入/brokers/topics/\[topic\]/partitions/\[partition\]/state。  
**6.Kafka副本同步机制**

Kafka中主题的每个Partition有一个预写式日志文件，每个Partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到Partition中，Partition中的每个消息都有一个连续的序列号叫做offset,  
确定它在分区日志中唯一的位置。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h3MTIwMjE5_size_16_color_FFFFFF_t_70 3]  
Kafka每个topic的partition有N个副本，其中N是topic的复制因子。Kafka通过多副本机制实现故障自动转移，当Kafka集群中一个Broker失效情况下仍然保证服务可用。在Kafka中发生复制时确保partition的预写式日志有序地写到其他节点上。N个replicas中。其中一个replica为leader，其他都为follower，leader处理partition的所有读写请求，与此同时\*\*，follower会被动定期地去复制leader上的数据。\*\*  
Kafka必须提供数据复制算法保证,如果leader发生故障或挂掉，一个新leader被选举并接收客户端的消息成功写入。Kafka确保从同步副本列表中选举一个副本为leader,或者换句话说,follower追赶leader数据。\*\*leader负责维护和跟踪ISR中所有follower滞后状态。\*\*当生产者发送一条消息到Broker,leader写入消息并复制到所有follower。消息提交之后才被成功复制到所有的同步副本。消息复制延迟受最慢的follower限制,重要的是快速检测慢副本,如果follower”落后”太多或者失效,leader将会把它从replicas从ISR移除。  
**7producer是否直接将数据发送到broker的leader(主节点)？**  
producer直接将数据发送到broker的leader(主节点)，不需要在多个节点进行分发，为了帮助producer做到这点，所有的Kafka节点都可以及时的告知:哪些节点是活动的，目标topic目标分区的leader在哪。这样producer就可以直接将消息发送到目的地了  
**8Kafa consumer是否可以消费指定分区消息？**  
可以，参考代码https://blog.csdn.net/zjx\_z/article/details/83000794  
**9.Kafka高效文件存储设计特点：**  
(1).Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。  
(2).通过索引信息可以快速定位message和确定response的最大大小。  
(3).通过index元数据全部映射到memory，可以避免segment file的IO磁盘操作。  
(4).通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。

**10.Kafka 与传统消息系统之间有三个关键区别**  
(1).Kafka 持久化日志，这些日志可以被重复读取和无限期保留  
(2).Kafka 是一个分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据提升容错能力和高可用性  
(3).Kafka 支持实时的流式处理  
**11.Kafka新建的分区会在哪个目录下创建**  
在启动 Kafka 集群之前，我们需要配置好 log.dirs 参数，其值是 Kafka 数据的存放目录，这个参数可以配置多个目录，目录之间使用逗号分隔，通常这些目录是分布在不同的磁盘上用于提高读写性能。  
当然我们也可以配置 log.dir 参数，含义一样。只需要设置其中一个即可。  
如果 log.dirs 参数只配置了一个目录，那么分配到各个 Broker 上的分区肯定只能在这个目录下创建文件夹用于存放数据。  
但是如果 log.dirs 参数配置了多个目录，那么 Kafka 会在哪个文件夹中创建分区目录呢？答案是：Kafka 会在含有分区目录最少的文件夹中创建新的分区目录，分区目录名为 Topic名+分区ID。注意，是分区文件夹总数最少的目录，而不是磁盘使用量最少的目录！也就是说，如果你给 log.dirs 参数新增了一个新的磁盘，新的分区目录肯定是先在这个新的磁盘上创建直到这个新的磁盘目录拥有的分区目录不是最少为止。  
**12.kafka生产者的ack机制**  
request.required.acks有三个值 0 1 -1  
0:生产者不会等待broker的ack，这个延迟最低但是存储的保证最弱当server挂掉的时候就会丢数据  
1：服务端会等待ack值 leader副本确认接收到消息后发送ack但是如果leader挂掉后他不确保是否复制完成新leader也会导致数据丢失  
\-1：同样在1的基础上 服务端会等所有的follower的副本受到数据后才会受到leader发出的ack，这样数据不会丢失

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h3MTIwMjE5_size_16_color_FFFFFF_t_70]: /images/20211104/3ef7894563b64240942e0dd7cb257330.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h3MTIwMjE5_size_16_color_FFFFFF_t_70 1]: /images/20211104/e1b1501c3c22486d959fd762454b8c77.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h3MTIwMjE5_size_16_color_FFFFFF_t_70 2]: /images/20211104/fa35a5717fbf476da6f3c8857bded523.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2h3MTIwMjE5_size_16_color_FFFFFF_t_70 3]: /images/20211104/4debff1cb16e4e9a9ba3fef622f8102c.png