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有多个ReplicaLeader Follower4.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。生产者发送数据和消费者消费数据的对象都是LeaderFollower只负责从Leader同步数据起到数据备份的作用。Leader/FollowerLeader是每个分区副本的主所有读写都走Leader。Follower实时从Leader同步数据当Leader发生故障时某个Follower会被选举成新的Leader保证服务不中断。ISRIn-Sync Replicas与Leader保持同步的Follower集合。如果某个Follower长时间未向Leader发送同步请求默认超过30s就会被踢出ISR。Leader故障后新Leader只会从ISR中产生。5. 集群部署关键配置Kafka集群部署时server.properties中几个关键配置需要理解其含义# 每个Broker在集群中的唯一编号不能重复 broker.id0 # Kafka数据存储路径 log.dirs/opt/module/kafka/datas # 单个Topic在当前Broker上默认的分区数 num.partitions1 # 每个Topic创建时的默认副本数 offsets.topic.replication.factor1 # 数据保留时间默认7天 log.retention.hours168 # 连接Zookeeper集群的地址在/kafka根目录下创建节点方便管理 zookeeper.connecthadoop102: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# 创建Topic3个分区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架构的主干。后续生产者、消费者的细节都是在这个框架上展开的。