Kafka 简介、核心原理与典型使用场景
一、简介
Apache Kafka 是一个分布式的发布 - 订阅消息系统。它最初由 LinkedIn 开发，2010 年贡献给 Apache 基金会并成为顶级开源项目。
简单来说，Kafka 是一种快速、可扩展的分布式提交日志服务。它天生就是为分布式设计的，支持分区和复制，能够处理海量数据流。
二、基本架构
Kafka 的核心组件主要包括以下四个部分：
- Topic（话题）：特定类型的消息流。消息是字节负载，而 Topic 则是这些消息的分类名或 Feed 名。
- Producer（生产者）：负责将消息发布到指定 Topic 的对象。
- Broker（代理）：已发布的消息保存在一组服务器中，它们被称为 Broker，多个 Broker 共同构成了 Kafka 集群。
- Consumer（消费者）：可以订阅一个或多个 Topic，并从 Broker 拉取数据来消费消息。
在典型的架构中，生产者将数据发送到 Broker，Broker 内部包含多个 Topic，而消费者则从 Broker 获取所需的数据进行处理。
三、基本原理
我们将消息的发布称为 Producer，订阅称为 Consumer，中间的存储阵列称为 Broker。乍一看这似乎很简单，但关键在于它是如何分布式的。
Kafka 官方架构图展示了多个 Broker 协同工作的场景。Producer 和 Consumer 部署在各个业务逻辑中被频繁调用，三者通过 Zookeeper 进行协调请求和转发。这样一个高性能的分布式消息发布订阅系统就完成了。
这里有两个关键细节需要注意：
- Push vs Pull：Producer 到 Broker 的过程是 Push，即有数据就推送；而 Consumer 到 Broker 的过程是 Pull，即消费者主动去拉取数据，而不是 Broker 主动发送。
- 分布式协调：多节点协同合作，确保系统的高可用性和一致性。
四、Zookeeper 的作用
上述提到了 Zookeeper，它在 Kafka 生态中扮演着至关重要的角色：
- 元数据管理：无论是 Kafka 集群还是 Producer/Consumer，都依赖 Zookeeper 保存一些 Meta 信息，保证系统可用性。
- 分布式协调框架：Kafka 利用 Zookeeper 将消息生产、存储、消费的过程有机结合。
- 负载均衡与订阅关系：借助 Zookeeper，Kafka 能够在无状态的情况下，建立生产者与消费者的订阅关系，并实现负载均衡。
五、执行流程
假设我们有一个简化的部署环境，其中 Broker 只有一台，整个系统的运行顺序大致如下：
- 启动 Zookeeper Server：Server-2 作为 Zookeeper 服务端，维护一张表记录各节点的 IP、端口等信息。
- 启动 Kafka Server：Server-1 作为 Kafka 服务端，主要负责数据存储。
- 客户端配置：Server-3、4、5 等客户端配置了 zkClient，运行前必须指定 Zookeeper 地址，以便连接分发。
- 高可用部署：Server-1 和 Server-2 可以放在同一台机器，也可以分开，Zookeeper 本身也支持集群模式，目的是防止单点故障。
具体交互流程：
- 启动 Zookeeper 后，再启动 Kafka Server。
- Producer 生产数据时，先通过 Zookeeper 找到对应的 Broker，然后将数据存放到 Broker。
- Consumer 消费数据时，同样先通过 Zookeeper 定位 Broker，然后拉取并消费。
六、核心特性
Kafka 之所以流行，主要得益于以下特性：
- 高吞吐、低延迟：每秒可处理几十万条消息，延迟低至几毫秒。每个 Topic 可分多个 Partition，Consumer Group 对 Partition 进行消费操作。
