kafka 介绍
什么是 Kafka
Kafka 是由 LinkedIn 公司开发并开源的一款分布式流处理平台（Distributed Streaming Platform）。它最初被设计为一个高吞吐量的分布式消息队列，但现在已经发展成为一个功能强大的、支持多分区、多副本的、基于发布/订阅模式的流处理平台。
Kafka 的基本术语
- 消息 (Message) ：Kafka 中的数据单元被称为消息，也被称为记录（Record），可以把它看作数据库表中某一行的记录。
- 批次 (Batch) ：为了提高效率，消息会分批次写入 Kafka，批次就代指的是一组消息。
- 主题 (Topic) ：消息的种类称为 主题（Topic）,可以说一个主题代表了一类消息。相当于是对消息进行分类。主题就像是数据库中的表。
- 分区 (Partition) ：主题可以被分为若干个分区（partition），同一个主题中的分区可以不在一个机器上，有可能会部署在多个机器上，由此来实现 kafka 的 伸缩性。在单个分区内，消息是有序的，但无法保证整个主题中所有分区的全局有序性。
- 生产者 (Producer) ：向主题发布消息的客户端应用程序称为生产者（Producer），生产者用于持续不断地向某个主题发送消息。
- 消费者 (Consumer) ：订阅主题消息的客户端程序称为 消费者（Consumer），消费者用于处理生产者产生的消息。
- 消费者组 (Consumer Group) ：多个消费者可以组成一个消费者组（Consumer Group），共同消费一个或多个主题。消费者组是实现消费负载均衡和高可用的关键。一个主题的每个分区在同一时刻只能被组内的一个消费者消费，但可以被多个不同组的消费者同时消费。这使得消费者组可以通过增减消费者数量来横向扩展处理能力。
- 偏移量 (Offset) ：偏移量（Offset）是分区内每条消息的唯一 ID，是一个单调递增的整数。它标志着消费者在分区中消费到的位置。消费者会定期提交（commit）自己消费到的偏移量，当消费者重启或发生重平衡后，可以从上次提交的偏移量位置继续消费，从而保证消息的至少一次（at-least-once）或精确一次（exactly-once）处理。
- 节点(Broker): 一个独立的 Kafka 服务器就被称为 broker，broker 接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。broker 集群：broker 是 集群的组成部分，broker 集群由一个或多个 broker 组成，每个集群都有一个 broker 同时充当了 集群控制器的角色（自动从集群的活跃成员中选举出来）。
- 副本 (Replica) ：Kafka 中消息的备份又叫做副本（Replica），副本的数量是可以配置的。Kafka 为每个分区定义了两类副本：领导者副本（Leader Replica） 和追随者副本（Follower Replica）。一个分区的所有读写请求都由 Leader 副本处理，而 Follower 副本则被动地从 Leader 副本同步数据，作为备份。当 Leader 副本失效时，其中一个 Follower 副本会被选举为新的 Leader。
- 重平衡（Rebalance）：当消费者组内的消费者数量发生变化（如有新的消费者加入、或有旧的消费者宕机、主动离开），或者订阅的主题分区数量发生变化时，会触发 重平衡（Rebalance），这是一个将分区重新分配给组内消费者的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。
Kafka 的特性
- 高吞吐、低延迟：Kafka 最大的特点就是收发消息非常快，它每秒可以处理几十万甚至上百万条消息，延迟最低可达几毫秒。
- 高伸缩性：每个主题(topic) 包含多个分区(partition)，主题中的分区可以分布在不同的主机(broker)中。可以通过增加 Broker 节点扩展集群，也可以通过增加主题的分区来提高并行度，从而实现轻松扩展。
- 持久性、可靠性：Kafka 将消息持久化到 Broker 节点的本地磁盘上，并支持配置多副本进行数据备份，防止数据丢失。KRaft 主要负责存储集群的元数据，例如：Broker 信息、Topic 配置、访问控制列表（ACL）等，而不是消息数据本身。
- 容错性：允许集群中的节点失败。得益于副本机制，某个节点宕机，Kafka 集群能够选举出新的 Leader 继续对外提供服务，保证系统正常工作。
- 高并发：支持数千个客户端同时读写。
Kafka 的使用场景
- 活动跟踪：Kafka 可以用来跟踪用户行为，比如：我们经常去淘宝购物，您打开淘宝的那一刻，您的登陆信息，登陆次数都会作为消息传输到 Kafka ，当浏览购物的时候，浏览信息、搜索指数、购物爱好都会作为一个个消息传递给 Kafka ，这样就可以生成实时报表，进行智能推荐，分析用户购买喜好等。
- 传递消息：Kafka 另一个基本用途是作为应用解耦的中间件，用于在不同的微服务或应用组件之间传递消息。生产者应用无需关心消费者的实现细节、格式和位置，只需将消息发送到 Kafka 即可。
- 度量指标：Kafka 也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
- 日志记录：Kafka 的设计灵感来源于提交日志 (Commit Log) 架构。它可以作为统一的日志聚合平台，收集来自不同服务器和应用程序的日志，然后以统一接口服务的方式开放给各种下游系统消费，例如：Hadoop、HBase、Elasticsearch 等。
- 流式处理：结合 Kafka Streams、Flink、Spark Streaming 等流处理框架，Kafka 可以作为强大的数据源，对实时数据流进行复杂的处理和分析，例如：实时 ETL、事件驱动的应用等。
- 限流削峰：在互联网应用中，面对突发流量（如秒杀活动），可以把用户的请求先写入 Kafka，后端服务再按照自己的处理能力平稳地从 Kafka 中拉取请求进行处理，避免了瞬时高并发直接冲击后端系统导致服务崩溃。
系统架构
一个典型的 Kafka 集群中包含若干 Producer，若干 broker（Kafka 支持水平扩展，一般 broker 数量越多，集群吞吐率越高），若干 Consumer 或 Consumer Group。Kafka 通过 KRaft 管理集群配置，选举 leader，以及在 Consumer Group 发生变化时进行 rebalance。Producer 使用 push 模式将消息发布到 broker，Consumer 使用 pull 模式从 broker 订阅并消费消息。
Kafka API
Apache Kafka 提供了五个核心 Java API 来实现集群和客户端管理。
- 生产者 API：生产者将事件流发布（写入）到一个或多个 Kafka 主题（topics）。Producer API 允许开发者创建自己的生产者，将数据写入 Kafka 主题。该 API 提供了多个选项来配置生产者的行为，例如：设置在将消息视为已发送之前所需的确认次数，或者设置压缩选项以减小消息大小。
- 消费者 API：消费者订阅（读取）一个或多个主题（topics），并处理生成的事件流。Consumer API 允许开发者创建自己的消费者，从 Kafka 主题读取数据。它提供了多种选项来配置消费者的行为，例如：设置开始消费的位置，或设置一次获取的记录数。
- 管理客户端 API：Admin Client API 是一个 Kafka API，它使开发人员能够以编程方式管理 Kafka 集群。它提供了一组操作，可用于创建、删除、描述和修改 Kafka 资源，例如：主题、代理和 ACL（访问控制列表）。Admin Client API 可用于自动执行常见的管理任务，例如：创建和删除主题，以及将 Kafka 管理集成到更大的系统和工作流程中。
- 连接 API：Kafka Connect API 允许您构建和运行可重复使用的数据导入、导出连接器，这些连接器可以从与 Kafka 集成的外部系统和应用程序消费（读取）事件流，也可以生成（写入）事件流。例如：连接到关系数据库（例如 PostgreSQL）的连接器可以捕获一组表的每次更改。通常您不需要实现自己的连接器，因为 Kafka 社区提供了数百个开箱即用的连接器。
- Kafka Streams API：使用 Kafka Streams API 实现对 Kafka 中的数据执行流处理操作的应用程序和微服务。从一个或多个主题读取输入，并生成到一个或多个主题的输出，从而将输入流转换为输出流。Kafka Streams API 通过 Kafka Streams 领域特定语言 (DSL) 提供高级功能，并通过处理器 API 提供低级处理。Kafka Streams DSL 为高级 API 提供最常见的数据转换操作，例如：map、filter、join 和聚合，开箱即用。如果您是 Kafka Streams 开发新手，建议您使用此 DSL，它应该能够满足大多数用例和流处理需求。如果您使用的是 Scala，则可以使用 Kafka Streams DSL for Scala 库，与 Java DSL 相比，它省去了大部分 Java/Scala 互操作性样板代码。
Kafka 为何快
Kafka 实现了零拷贝原理来快速移动数据，避免了内核之间的切换。Kafka 可以将数据记录分批发送，从生产者到文件系统（Kafka 主题日志）到消费者，可以端到端的查看这些批次的数据。
批处理能够进行更有效的数据压缩并减少 I/O 延迟，Kafka 采取顺序写入磁盘的方式，避免了随机磁盘寻址的浪费，更多关于磁盘寻址的了解，请参阅程序员需要了解的硬核知识之磁盘。
总结一下其实就是四个要点：
- 顺序读写
- 零拷贝
- 消息压缩
- 分批发送
KRaft 模式介绍
架构介绍
Kafka 的 KRaft 模式是一种新的元数据管理方式，旨在去除对 ZooKeeper 的依赖，使 Kafka 成为一个完全自包含的系统。在 Kafka 的传统模式下，元数据管理依赖于 ZooKeeper，这增加了部署和运维的复杂性。为了解决这个问题，Kafka 社区引入了 KRaft 模式。在 KRaft 模式下，所有的元数据，包括主题、分区信息、副本位置等，都被存储在 Kafka 集群内部的特殊日志中。这个日志使用 Raft 协议来保证一致性。
在传统架构中，Kafka 集群包含多个 Broker 节点和一个 ZooKeeper 集群。Kafka 集群的 Controller 在被选中后，会从 ZooKeeper 中加载它的状态。并且通知其他 Broker 发生变更，如 LeaderAndISR 和 Updatemetdata 请求。
在新的架构中，三个 Controller 节点替代三个 ZooKeeper 节点。Controller 节点和 Broker 节点运行在不同的进程中。Controller 节点中会选举出一个 Leader 角色。并且 Leader 不会主动向 Broker 推送更新，而是由 Broker 拉取元数据信息。
注意：Controller 进程与 Broker 进程在逻辑上是分离的，同时允许部分或所有 Controller 进程和 Broker 进程是同一个进程，即一个 Broker 节点即是 Broker 也是 Controller。
优点
简化部署：不再需要单独部署和维护 ZooKeeper 集群，降低了运维复杂性和成本。
一致性和可靠性：KRaft 协议提供了强一致性保证，确保元数据在多个节点之间的一致复制，提高了系统的可靠性。
高可用性：通过控制节点的多数共识机制，在少数节点故障的情况下仍能保证集群的正常运行。
性能优化：减少了 Kafka 与 ZooKeeper 之间的通信开销，可能带来性能上的提升。
