Kraft模式

Kafka Kraft模式（KRaft）是Apache Kafka自2.8版本引入的核心功能，旨在通过移除对ZooKeeper的依赖，简化集群架构并提升性能。以下是其核心内容的总结：

1. 什么是Kraft模式？

Kraft模式（Kafka Raft元数据模式）是Kafka内置的分布式共识协议，基于Raft算法实现集群元数据（如主题、分区、副本状态等）的自主管理。它替代了传统ZooKeeper模式，使Kafka集群无需外部协调服务即可运行。

2. 为什么引入Kraft模式？

• 简化架构：消除对ZooKeeper集群的依赖，减少运维复杂度。
• 提升扩展性：通过Raft协议实现元数据的高效同步，支持百万级分区（远超ZooKeeper的数万限制）。
• 增强可靠性：控制器故障恢复时间缩短至毫秒级，且元数据变更通过Raft协议保证强一致性。
• 统一管理：将元数据管理与Kafka自身深度整合，统一安全模型和配置管理。

3. 核心优势

• 部署与管理更简单：仅需维护Kafka节点，无需额外部署ZooKeeper。
• 性能优化：元数据存储本地化，减少跨系统通信延迟。
• 高可用性：通过Raft协议的多数派选举机制，确保集群在部分节点故障时仍正常运行。
• 快速恢复：控制器故障后，新控制器可直接从内存加载元数据，无需从外部存储恢复。

4. 架构与工作原理

• 控制器节点：
  • 集群中指定部分节点（如3个）作为控制器候选，通过Raft协议选举产生主控制器（Active Controller），其余为备用（Standby）。
  • 控制器节点通过controller.quorum.voters配置定义，格式为id@host:port。
• 元数据存储：
  • 元数据通过名为__cluster_metadata的主题存储，支持日志压缩和快照，确保数据持久化。
• Broker通信：
  • Broker通过心跳机制与控制器保持会话，主动拉取元数据更新，而非被动接收广播。

5. 部署与配置要点

• 关键配置：
  • process.roles：定义节点角色（controller、broker或混合模式）。
  • node.id：唯一标识节点，需与controller.quorum.voters中的ID一致。
  • listeners：配置控制器通信端口（如CONTROLLER://host:9093）。
• 初始化集群：
  使用kafka-storage initialize命令生成元数据，需指定配置文件和引导服务器。
• 生产建议：
  • 控制器节点数建议为3或5（奇数），确保多数派存活。
  • 避免混合模式（同时作为控制器和Broker），推荐隔离部署以提升稳定性。

6. 适用场景与最佳实践

• 适用场景：
  • 大规模集群（百万级分区）。
  • 对延迟敏感的实时数据处理。
  • 需要简化运维的边缘计算或小型部署。
• 最佳实践：
  • 迁移前充分测试，优先新建KRaft集群。
  • 监控控制器状态和Raft日志同步情况。
  • 定期备份元数据存储目录。

总结

Kraft模式是Kafka架构的重大演进，通过自管理的Raft协议显著提升了集群的可扩展性、可靠性和运维效率。随着Kafka版本的迭代（如3.3+），KRaft已成为生产环境的首选模式，尤其适合需要高性能、低延迟的分布式消息系统场景。

KIP-833: Mark KRaft as Production Ready

KIP-833: Mark KRaft as Production Ready

除了Kraft模式，Kafka还有以下常用模式：

• ZooKeeper模式：这是Kafka在KRaft出现之前长期使用的模式。Kafka依赖ZooKeeper来管理元数据，比如集群成员信息、主题（Topic）配置、分区（Partition）分配等。ZooKeeper为Kafka提供了分布式协调服务，帮助Kafka处理诸如选举领导者（Leader）副本、监控Broker状态等任务。但随着Kafka集群规模扩大，ZooKeeper可能成为性能瓶颈，并且其复杂的配置和维护也增加了管理难度。
• 消息消费模式：
  • 发布订阅模式（Publish/Subscribe）：一对多的关系，消费者消费完消息后，消息不会立即被删除，而是会存储一段时间，该模式下的消息会被所有订阅该主题的消费者消费。比如在实时数据分析场景中，多个数据分析应用可以同时订阅同一个主题的业务数据，进行各自维度的分析 。此模式下又分为推模式（queue直接将消息推给消费者，可能出现消费者处理不过来的情况）和拉模式（消费者主动去拉取queue中的消息，可按自身消费能力拉取，但需持续维护拉取任务）。
  • 点对点模式（Point-to-Point，P2P）：一对一的关系，消费者主动拉取数据，消息确认被消费后，消息队列会删除该消息，一条消息只会被一个消费者消费。在Kafka中，同一消费者组里面的消费者，消费消息类似点对点模式，不过消费完消息后消息不会被删除。
• 数据可靠性模式（基于生产者角度，通过acks参数设置） ：
  • acks = 0：生产者无需等待来自Broker的确认就继续发送下一批消息，传输效率最高，但可靠性最低，可能丢数据，不会重复发送，因为这种模式下重试机制会失效。
  • acks = 1（默认）：生产者在ISR（In-Sync Replicas，副本同步队列 ）中的Leader已成功收到数据并得到确认后，才发送下一条消息。如果Leader宕机，可能会丢失数据。
  • acks = -1或all：生产者需要等待ISR中的所有Follower都确认接收到数据后，才算一次发送完成，可靠性最高，但不能完全保证数据不丢失（如ISR中只剩Leader时，就类似acks = 1的情况），且开启失败重试可能导致消息重复发送。
• 消费者消费语义模式：
  • at most once（最多一次）：保证每一条消息commit成功之后，再进行消费处理。设置自动提交为false，接收到消息之后，首先commit，然后再进行消费。特点是不会重复发送，但可能丢失消息。
  • at least once（至少一次）：保证每一条消息处理成功之后，再进行commit。设置自动提交为false，消息处理成功之后，手动进行commit。特点是会重复发送，但消息不会丢失。
  • exactly once（恰好一次）：发送端数据发送成功，并且成功的消息只发送一次（重复的数据被服务器拒绝），消费端结合幂等性实现。例如，Kafka 0.11.0.0 及以后版本通过生产者幂等性和事务机制来实现Exactly - once语义，确保消息在生产和消费过程中都只被处理一次。

启用 Kafka KRaft 模式

启用 Kafka KRaft 模式需按以下标准流程操作：

1. 配置 server.properties 文件

• 核心配置项：
  • process.roles：定义节点角色，取值：
    • controller,broker：节点同时作为控制器和代理（测试场景）。
    • controller：仅作为控制器（生产环境推荐多节点）。
    • broker：仅作为代理。
  • node.id：为节点设置唯一 ID，集群内所有节点（控制器、代理）的 node.id 不可重复。
  • controller.quorum.voters：以 {id}@{host}:{port} 格式定义控制器仲裁列表，例如 1@host1:9093,2@host2:9093,3@host3:9093，其中 id 需与节点的 node.id 一致。
  • 其他基础配置：如 listeners（监听地址）、inter.broker.listener.name（代理间通信协议）、log.dirs（日志存储路径）等。

2. 初始化集群元数据

使用 kafka-storage 工具初始化 KRaft 集群元数据：

# 命令格式
bin/kafka-storage initialize \-bootstrap-server localhost:9093 \-cluster-id <自动生成，首次可不填> \-configuration config/kraft/server.properties

• 执行后会生成集群元数据，存储在 log.dirs 配置的目录中。

3. 启动 Kafka 服务

bin/kafka-server-start.sh config/kraft/server.properties

生产环境注意事项

• 控制器节点数量：至少 3 个控制器节点，确保仲裁机制正常（遵循多数原则）。
• 网络与端口：控制器间通过 controller.quorum.voters 配置的端口通信，需开放对应端口。
• 迁移场景：若从 ZooKeeper 模式迁移，需参考官方迁移文档逐步操作，避免数据丢失。

完整流程参考 Apache Kafka 官方文档：KRaft Documentation。