kafka raft协议

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 副本的一致性的方式与之前的版本有一些不同，具体如下：

1. Raft 协议：Kraft 协议基于 Raft 一致性算法。Raft 是一种分布式共识算法，用于在集群中选择一个稳定的 leader，并确保所有节点上的数据副本保持一致。Raft 算法保证了 leader 和 leader 副本之间的数据一致性，以及在 leader 故障时自动选举新的 leader。

2. 强一致性保证：Kraft 协议提供强一致性保证，这意味着只有 leader 完全提交了数据后，数据才会被视为可读。在写入到 leader 前，所有的 follower 都需要确认消息，确保数据在所有节点上都存在。这样一来，当消息被成功写入 leader 之后，它将被复制到 follower 中的绝大多数节点上。

3. 无数据丢失：Kraft 协议能够保证在多数节点上成功提交的数据不会丢失，即使在出现 leader 故障的情况下。因为在 leader 失效时，新的 leader 会选举出来并基于之前提交的日志重建状态，从而保证数据不丢失。

4. 持久化：Kraft 协议要求在进行任何提交之前将所有数据写入磁盘，这样即使服务器重启，也能从磁盘中加载数据并恢复状态。

总的来说，通过 kraft 协议，Kafka 实现了更强的一致性保证，确保 leader 和 leader 副本之间的数据始终保持一致。这对于 Kafka 高可用性和数据完整性非常重要，使得 Kafka 成为一个可靠的消息传递系统。