Kafka概述与快速入门

Kafka概述与快速入门

1. Kafka是什么

Kafka最初被定义为一个分布式的基于发布/订阅模式的消息队列，主要应用于大数据实时处理领域。但随着版本迭代，Kafka的官方定义已经更新为开源的分布式事件流平台（Event Streaming Platform），被数千家公司用于高性能数据管道、流分析、数据集成和关键任务应用。

两个定义的区别在于定位的变化：消息队列强调的是"传递消息"，而事件流平台强调的是"处理连续的事件流"。Kafka现在不只是一个中间件，更是一个完整的流处理基础设施。

2. 消息队列的应用场景

在理解Kafka之前，先搞清楚消息队列解决了什么问题。

2.1 缓存/消峰

系统在高并发时，如果所有请求直接打到后端服务，很容易把服务压垮。消息队列可以把请求先缓存起来，让后端按自己的处理能力逐步消费，从而平滑流量峰值。

典型场景：双十一秒杀，用户请求量远超系统处理能力，消息队列充当缓冲层，避免系统被瞬间流量击垮。

2.2 解耦

系统A需要把数据传给系统B、C、D，如果直接调用，A就和B、C、D产生了强依赖，任何一个下游变化都需要修改A。引入消息队列后，A只需要把消息发到队列，下游系统自己去订阅，A和下游完全解耦。

2.3 异步通信

用户注册时，除了写数据库，还需要发短信、发邮件。如果同步执行，用户需要等待所有操作完成才能得到响应，体验很差。把发短信、发邮件的请求写入消息队列后，主流程立即返回，后续操作异步执行，响应速度大幅提升。

3. 消息队列的两种模式

3.1 点对点模式

消费者主动从队列拉取消息，消息被消费后立即从队列删除。一条消息只能被一个消费者消费，消费完就没了。

3.2 发布/订阅模式

消息发布到某个Topic（主题），所有订阅了该Topic的消费者都能收到这条消息。消息消费后不会被删除，不同消费者之间互不影响，都能独立消费到完整的数据。

Kafka采用的是发布/订阅模式，这也是Kafka能支撑多下游系统同时消费同一份数据的根本原因。

4. Kafka基础架构

理解Kafka的核心在于搞清楚以下几个概念之间的关系：

Producer → Kafka集群（多个Broker） → Consumer Group（多个Consumer） ↓ Topic（逻辑概念） ↓ Partition（物理存储，分布在各Broker上） ↓ 每个Partition有多个Replica（Leader + Follower）

4.1 各概念说明

Producer（生产者）：向Kafka发送消息的客户端，消息发往Broker中的某个Topic。

Consumer（消费者）：从Kafka拉取消息的客户端，面向的也是Topic。

Consumer Group（消费者组）：由多个Consumer组成，组内每个Consumer负责消费不同分区的数据，一个分区只能由同一个组内的一个Consumer消费。消费者组之间互不影响，这意味着同一份数据可以被多个消费者组独立消费。

Broker：一台Kafka服务器就是一个Broker，多个Broker组成Kafka集群，一个Broker可以容纳多个Topic。

Topic（主题）：逻辑上的消息分类，生产者和消费者面向的都是Topic，类似于数据库中的表。

Partition（分区）：为了实现扩展性，一个Topic可以分为多个Partition分布在不同的Broker上。每个Partition是一个有序的队列，Partition内部消息有序，但多个Partition之间无序。分区的好处有两个：一是把海量数据分散存储，实现负载均衡；二是生产者和消费者都可以以分区为单位并行处理，提高吞吐量。

Replica（副本）：每个Partition有若干个副本，分为一个Leader和若干个Follower。生产者发送数据和消费者消费数据的对象都是Leader，Follower只负责从Leader同步数据，起到数据备份的作用。

Leader/Follower：Leader是每个分区副本的"主"，所有读写都走Leader。Follower实时从Leader同步数据，当Leader发生故障时，某个Follower会被选举成新的Leader，保证服务不中断。

ISR（In-Sync Replicas）：与Leader保持同步的Follower集合。如果某个Follower长时间未向Leader发送同步请求（默认超过30s），就会被踢出ISR。Leader故障后，新Leader只会从ISR中产生。

5. 集群部署关键配置

Kafka集群部署时，server.properties中几个关键配置需要理解其含义：

# 每个Broker在集群中的唯一编号，不能重复 broker.id=0 # Kafka数据存储路径 log.dirs=/opt/module/kafka/datas # 单个Topic在当前Broker上默认的分区数 num.partitions=1 # 每个Topic创建时的默认副本数 offsets.topic.replication.factor=1 # 数据保留时间，默认7天 log.retention.hours=168 # 连接Zookeeper集群的地址（在/kafka根目录下创建节点，方便管理） zookeeper.connect=hadoop102:2181,hadoop103:2181,hadoop104:2181/kafka

集群中每台节点的broker.id必须唯一，这是Kafka识别不同节点的依据。

启动顺序需要注意：先启动Zookeeper，再启动Kafka。停止时反过来，先停Kafka，再停Zookeeper，否则Kafka无法正常获取停止信息。

6. 命令行操作

Kafka提供了三类命令行工具，分别用于操作Topic、生产者和消费者。

6.1 Topic操作

# 查看所有Topicbin/kafka-topics.sh --bootstrap-server hadoop102:9092--list# 创建Topic（3个分区，2个副本）bin/kafka-topics.sh --bootstrap-server hadoop102:9092\--create--topicfirst--partitions3--replication-factor2# 查看Topic详情（分区、副本、Leader分布）bin/kafka-topics.sh --bootstrap-server hadoop102:9092\--describe--topicfirst# 修改分区数（注意：只能增加，不能减少）bin/kafka-topics.sh --bootstrap-server hadoop102:9092\--alter--topicfirst--partitions5# 删除Topicbin/kafka-topics.sh --bootstrap-server hadoop102:9092\--delete--topicfirst

分区数只能增加不能减少，这是Kafka的设计限制，减少分区会导致数据丢失问题，Kafka直接禁止了这个操作。

6.2 生产者命令行

# 启动命令行生产者，向first主题发送消息bin/kafka-console-producer.sh\--bootstrap-server hadoop102:9092--topicfirst

启动后进入交互模式，每输入一行回车即发送一条消息。

6.3 消费者命令行

# 消费first主题的消息（只消费新产生的消息）bin/kafka-console-consumer.sh\--bootstrap-server hadoop102:9092--topicfirst# 从头开始消费（包括历史消息）bin/kafka-console-consumer.sh\--bootstrap-server hadoop102:9092--topicfirst --from-beginning

默认情况下消费者只消费启动后新产生的消息，加上--from-beginning才会从最早的offset开始消费。

小结

Kafka的核心设计思路可以用一句话概括：通过Topic分类、Partition分片、Replica备份，在保证数据可靠性的同时实现高吞吐、高可扩展的消息传递。

理解了Producer → Topic → Partition → Replica → Consumer Group这条数据流转链路，就抓住了Kafka架构的主干。后续生产者、消费者的细节都是在这个框架上展开的。