1、首先要了解kafka是什么(Scala)
Kafka是一个分布式的消息订阅系统,消息被持久化到一个topic中,topic是按照“主题名-分区”存储的,一个topic可以分为多个partition,在parition(分区)内的每条消息都有一个有序的id号,这个id号被称为偏移(offset),记录消息的消息位置**。
高可用性和扩展性,而不是负载均衡。**
具体来说,Kafka 通过将主题(topic)分为多个分区(partition),并将每个分区复制到多个节点上来实现高可用性和扩展性。每个分区都有一个主节点(leader)和多个副本节点(replica)。主节点负责处理来自生产者的消息和消费者的读取请求,而副本节点则用于备份数据并提供冗余。如果主节点失效,Kafka 会自动选举一个副本节点作为新的主节点,以保持服务的连续性。**
虽然分区机制可以提高系统的整体吞吐量,但它并不是为了实现负载均衡而设计的。相反,Kafka 更关注的是数据的持久性、可用性和容错能力**。
实际上,Kafka 集群中只有分区的主节点(leader)负责处理来自生产者的消息和消费者的读取请求,而其他节点维护分区的副本(replica)。
具体来说,Kafka 集群中的每个分区都有一个主节点和多个副本节点。主节点负责处理生产者发送的消息并将其追加到分区的日志中,同时处理消费者的读取请求并提供消息的复制。副本节点仅用于备份数据,它们通过从主节点复制数据来保持与主节点的同步。当主节点失效时,Kafka 会自动从副本节点中选举出一个新的主节点,以确保服务的可用性。
因此,在正常情况下,只有分区的主节点(leader)才会直接处理请求,而其他节点(副本节点)则主要用于备份和保持数据的一致性。这种设计确保了高可用性和数据冗余,但并不是所有节点都直接参与消息的处理。
2、关于kafka版本更新之后有哪些变化要知道。
背景 Kafka2.8 之后,移除了Zookeeper,而使用了自己研发的Kafka Raft。
2.1 为什么移除Zookeeper
原来Zookeeper在Kafka中承担了Controller选举、Broker注册、TopicPartition注册和选举、Consumer/Producer元数据管理和负载均衡等。
即承担了各种元数据的保存和各种选举。
而Zookeeper并“不快”,集群规模大了之后,很容易成为集群的性能瓶颈。
Kafka作为一个消息中间件,还依赖额外的一个协调系统,而不能实现自我管理,说不过去~无法做到开箱即用,还得要求使用者掌握Zookeeper的调优知识。
到了2.8版本,Kafka移除了Zookeeper,使用自己的Kafka Raft(KRaft),这名字,一眼就能看出来是基于Raft算法实现的
元数据日志复制 与维护Consumer offset的方式类似,脱离ZK之后的Kafka集群将元数据视为日志,保存在一个内置的Topic中,且该Topic只有一个Partition。
对于元数据日志复制的方式,Kafka将元数据(例如Topic、Partition信息、Broker信息等)作为日志记录,保存在一个名为 "__consumer_offsets" 的内置Topic中。此内置Topic仅包含一个Partition,因为它的主要目的是用于管理Consumer offset和其他元数据信息,而不是存储实际的业务数据。
由于这种内置Topic只有一个Partition,因此它在Kafka集群中的复制行为与其他Topic不同。通常情况下,其他Topic可能有多个Partition,并且每个Partition在不同的Broker上都有多个副本以提供冗余和高可用性。但对于 "__consumer_offsets" 这个内置Topic,Kafka会确保其只有一个Partition,并且该Partition在集群中的所有Broker上都有一个副本,以确保该信息的高可用性。
为什么只有一个Partition?
Raft的日志队列,是需要有序的,先进先出。Kafka的日志,每个分区是一个逻辑上的文件,顺序写入,只有一个Partition的时候,所有消息都是顺序的。
2.2 kraft 协议数据一致性问题
使用自身的kraft 协议之后 如何保证leader和lader副本的一致性问题?
Kafka 从版本 2.8.0 开始引入了一种新的复制协议,称为 "kraft" 协议(也称为 KRaft)。该协议主要用于管理分区的 leader 选举和数据复制,以提供更强的一致性和可靠性。在使用 kraft 协议之后,Kafka 保证 leader 和 leader 副本的一致性的方式与之前的版本有一些不同,具体如下:
-
Raft 协议:Kraft 协议基于 Raft 一致性算法。Raft 是一种分布式共识算法,用于在集群中选择一个稳定的 leader,并确保所有节点上的数据副本保持一致。Raft 算法保证了 leader 和 leader 副本之间的数据一致性,以及在 leader 故障时自动选举新的 leader。
-
强一致性保证:Kraft 协议提供强一致性保证,这意味着只有 leader 完全提交了数据后,数据才会被视为可读。在写入到 leader 前,所有的 follower 都需要确认消息,确保数据在所有节点上都存在。这样一来,当消息被成功写入 leader 之后,它将被复制到 follower 中的绝大多数节点上。
-
无数据丢失:Kraft 协议能够保证在多数节点上成功提交的数据不会丢失,即使在出现 leader 故障的情况下。因为在 leader 失效时,新的 leader 会选举出来并基于之前提交的日志重建状态,从而保证数据不丢失。
-
持久化:Kraft 协议要求在进行任何提交之前将所有数据写入磁盘,这样即使服务器重启,也能从磁盘中加载数据并恢复状态。
总的来说,通过 kraft 协议,Kafka 实现了更强的一致性保证,确保 leader 和 leader 副本之间的数据始终保持一致。这对于 Kafka 高可用性和数据完整性非常重要,使得 Kafka 成为一个可靠的消息传递系统。