一、为什么需要消息队列在现代分布式系统中消息队列Message Queue已成为架构设计的核心组件之一。无论是电商秒杀的流量削峰、微服务间的异步解耦还是大数据实时处理的缓冲消息队列都扮演着不可替代的角色。使用消息队列的核心价值可以概括为以下8 大优势优势说明解耦生产者和消费者独立扩展只需遵守统一接口冗余持久化消息持久化到队列处理完毕才删除防止数据丢失扩展性增加消费者即可线性提升处理能力削峰填谷突发流量暂存队列系统按恒定速率处理避免崩溃可恢复性单个消费者挂掉不影响整体重启后继续消费顺序保证队列天然有序Kafka 保证 Partition 内消息顺序缓冲平衡生产与消费的速度差异异步通信消息放入队列即可返回无需等待处理完成二、消息队列的两种经典模式2.1 点对点模式Point-to-Point特点一对一一条消息只能被一个消费者消费主动拉取消费者主动从队列拉取Pull消息消费即删除消息被消费后从队列中清除典型代表传统 JMS 队列2.2 发布/订阅模式Publish/Subscribe┌──────────────┐ │ Topic │ └──────┬───────┘ │ ┌───────────────┼───────────────┐ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │Consumer1│ │Consumer2│ │Consumer3│ └─────────┘ └─────────┘ └─────────┘特点一对多一条消息可被多个订阅者接收推送/拉取结合基于推送Push模型也可主动拉取订阅者类型临时订阅者仅在线时接收消息持久订阅者离线期间消息保留上线后补发典型代表Kafka、RabbitMQTopic 模式三、什么是 Kafka3.1 Kafka 的诞生背景Apache Kafka最初由LinkedIn公司于 2011 年开源2012 年成为 Apache 顶级项目。它使用Scala语言编写是一个分布式、高吞吐、低延迟的流式消息平台。Kafka 的设计目标为处理实时数据提供一个统一、高通量、低等待的平台。3.2 Kafka 的核心定位┌─────────────────────────────────────────────────────────┐ │ 实时数据流场景 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 日志收集 │ │ 消息系统 │ │ 流处理 │ │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ └──────────────┼──────────────┘ │ │ ▼ │ │ ┌─────────────┐ │ │ │ Kafka │ ← 统一的数据管道 │ │ └─────────────┘ │ └─────────────────────────────────────────────────────────┘在大数据生态中Kafka 通常作为数据缓冲层承接上游海量数据统一数据管道连接 Flume、Spark、Flink、Storm 等计算框架3.3 Kafka 的三类核心角色角色英文名职责生产者Producer向 Kafka 发送消息消费者Consumer从 Kafka 订阅并消费消息服务节点BrokerKafka 服务器实例负责存储和转发消息四、Kafka 核心架构详解4.1 整体架构图4.2 核心概念逐层拆解① Topic主题Topic: order-topic ├─ Partition 0 → Broker 102 ├─ Partition 1 → Broker 103 └─ Partition 2 → Broker 104Topic 是逻辑上的消息分类可以理解为一个消息队列一个 Topic 可分为多个Partition分区实现水平扩展② Partition分区Partition 0有序队列: ┌─────┬─────┬─────┬─────┬─────┐ │ Msg0│ Msg1│ Msg2│ Msg3│ Msg4│ ... └─────┴─────┴─────┴─────┴─────┘ Offset: 0 1 2 3 4每个 Partition 是一个有序的、不可变的消息序列每条消息被分配一个唯一的Offset偏移量Kafka 只保证单个 Partition 内的消息有序不保证 Topic 全局有序③ Replication副本Topic: order-topic (3分区, 2副本) Partition 0: Leader → Broker 102 Follower → Broker 103 Partition 1: Leader → Broker 103 Follower → Broker 104 Partition 2: Leader → Broker 104 Follower → Broker 102每个 Partition 可有多个副本分散在不同 Broker 上Leader 副本负责读写请求Follower 副本从 Leader 同步数据实现容错④ Consumer Group消费者组Topic: order-topic ├─ Partition 0 ├─ Partition 1 └─ Partition 2 Consumer Group A: Consumer Group B: ┌──────────────┐ ┌──────────────┐ │ Consumer A1 │──P0──┐ │ Consumer B1 │──P0──┐ │ Consumer A2 │──P1──┼──▶│ Consumer B2 │──P1──┼──▶ 广播 │ Consumer A3 │──P2──┘ │ Consumer B3 │──P2──┘ └──────────────┘ └──────────────┘ ↑ ↑ 单播负载均衡 单播负载均衡组内单播一个 Partition 同一时间只能被组内一个消费者消费组间广播不同消费者组可独立消费同一 Topic 的全部消息水平扩展增加消费者可提升消费能力不超过分区数⑤ Offset偏移量Consumer Group: group-1 ┌─────────────────────────────────────┐ │ Partition 0 → Offset: 1050 │ ← 记录消费进度 │ Partition 1 → Offset: 2048 │ │ Partition 2 → Offset: 998 │ └─────────────────────────────────────┘ 存储位置: __consumer_offsets (Topic)Offset 是消息在 Partition 中的唯一标识从 0 开始递增消费者通过 Offset 记录消费位置支持断点续传旧版存储在Zookeeper新版0.9存储在 Kafka 内部 Topic__consumer_offsets五、Kafka 与 Zookeeper 的关系5.1 旧版架构Kafka 3.0┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Zookeeper │◄───▶│ Kafka │◄───▶│ Producer/ │ │ 集群 │ │ Broker │ │ Consumer │ └─────────────┘ └─────────────┘ └─────────────┘Zookeeper 负责Broker 注册记录所有存活节点Topic 元数据分区分配、副本信息、Leader 选举消费者 Offset记录消费进度0.9 版本后改为内部 Topic5.2 新版架构Kafka ≥ 3.0KRaft 模式┌─────────────┐ ┌─────────────┐ │ Kafka │◄───▶│ Producer/ │ │ (自管理) │ │ Consumer │ └─────────────┘ └─────────────┘Kafka 3.0 引入KRaftKafka Raft模式去除 Zookeeper 依赖使用内置的Quorum Controller管理元数据降低运维复杂度六、Kafka 的核心特点总结特性说明高吞吐单机每秒可处理数十万条消息顺序写磁盘性能优异低延迟毫秒级延迟满足实时场景需求可扩展通过 Partition 和 Broker 水平扩展持久性消息持久化到磁盘支持多副本冗余容错性自动故障转移副本机制保证数据不丢失高并发支持数千个客户端同时读写七、Kafka 适用场景日志收集聚合分布式系统的日志数据消息系统替代传统 MQ处理高吞吐消息流处理Kafka Streams 实时计算事件溯源记录系统状态变更事件指标监控收集系统和应用的监控指标如果本文对你有帮助欢迎点赞 收藏 ⭐ 关注 你的支持是我持续创作的动力
Kafka 入门指南 —— 从消息队列到核心概念
一、为什么需要消息队列在现代分布式系统中消息队列Message Queue已成为架构设计的核心组件之一。无论是电商秒杀的流量削峰、微服务间的异步解耦还是大数据实时处理的缓冲消息队列都扮演着不可替代的角色。使用消息队列的核心价值可以概括为以下8 大优势优势说明解耦生产者和消费者独立扩展只需遵守统一接口冗余持久化消息持久化到队列处理完毕才删除防止数据丢失扩展性增加消费者即可线性提升处理能力削峰填谷突发流量暂存队列系统按恒定速率处理避免崩溃可恢复性单个消费者挂掉不影响整体重启后继续消费顺序保证队列天然有序Kafka 保证 Partition 内消息顺序缓冲平衡生产与消费的速度差异异步通信消息放入队列即可返回无需等待处理完成二、消息队列的两种经典模式2.1 点对点模式Point-to-Point特点一对一一条消息只能被一个消费者消费主动拉取消费者主动从队列拉取Pull消息消费即删除消息被消费后从队列中清除典型代表传统 JMS 队列2.2 发布/订阅模式Publish/Subscribe┌──────────────┐ │ Topic │ └──────┬───────┘ │ ┌───────────────┼───────────────┐ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ │Consumer1│ │Consumer2│ │Consumer3│ └─────────┘ └─────────┘ └─────────┘特点一对多一条消息可被多个订阅者接收推送/拉取结合基于推送Push模型也可主动拉取订阅者类型临时订阅者仅在线时接收消息持久订阅者离线期间消息保留上线后补发典型代表Kafka、RabbitMQTopic 模式三、什么是 Kafka3.1 Kafka 的诞生背景Apache Kafka最初由LinkedIn公司于 2011 年开源2012 年成为 Apache 顶级项目。它使用Scala语言编写是一个分布式、高吞吐、低延迟的流式消息平台。Kafka 的设计目标为处理实时数据提供一个统一、高通量、低等待的平台。3.2 Kafka 的核心定位┌─────────────────────────────────────────────────────────┐ │ 实时数据流场景 │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 日志收集 │ │ 消息系统 │ │ 流处理 │ │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ └──────────────┼──────────────┘ │ │ ▼ │ │ ┌─────────────┐ │ │ │ Kafka │ ← 统一的数据管道 │ │ └─────────────┘ │ └─────────────────────────────────────────────────────────┘在大数据生态中Kafka 通常作为数据缓冲层承接上游海量数据统一数据管道连接 Flume、Spark、Flink、Storm 等计算框架3.3 Kafka 的三类核心角色角色英文名职责生产者Producer向 Kafka 发送消息消费者Consumer从 Kafka 订阅并消费消息服务节点BrokerKafka 服务器实例负责存储和转发消息四、Kafka 核心架构详解4.1 整体架构图4.2 核心概念逐层拆解① Topic主题Topic: order-topic ├─ Partition 0 → Broker 102 ├─ Partition 1 → Broker 103 └─ Partition 2 → Broker 104Topic 是逻辑上的消息分类可以理解为一个消息队列一个 Topic 可分为多个Partition分区实现水平扩展② Partition分区Partition 0有序队列: ┌─────┬─────┬─────┬─────┬─────┐ │ Msg0│ Msg1│ Msg2│ Msg3│ Msg4│ ... └─────┴─────┴─────┴─────┴─────┘ Offset: 0 1 2 3 4每个 Partition 是一个有序的、不可变的消息序列每条消息被分配一个唯一的Offset偏移量Kafka 只保证单个 Partition 内的消息有序不保证 Topic 全局有序③ Replication副本Topic: order-topic (3分区, 2副本) Partition 0: Leader → Broker 102 Follower → Broker 103 Partition 1: Leader → Broker 103 Follower → Broker 104 Partition 2: Leader → Broker 104 Follower → Broker 102每个 Partition 可有多个副本分散在不同 Broker 上Leader 副本负责读写请求Follower 副本从 Leader 同步数据实现容错④ Consumer Group消费者组Topic: order-topic ├─ Partition 0 ├─ Partition 1 └─ Partition 2 Consumer Group A: Consumer Group B: ┌──────────────┐ ┌──────────────┐ │ Consumer A1 │──P0──┐ │ Consumer B1 │──P0──┐ │ Consumer A2 │──P1──┼──▶│ Consumer B2 │──P1──┼──▶ 广播 │ Consumer A3 │──P2──┘ │ Consumer B3 │──P2──┘ └──────────────┘ └──────────────┘ ↑ ↑ 单播负载均衡 单播负载均衡组内单播一个 Partition 同一时间只能被组内一个消费者消费组间广播不同消费者组可独立消费同一 Topic 的全部消息水平扩展增加消费者可提升消费能力不超过分区数⑤ Offset偏移量Consumer Group: group-1 ┌─────────────────────────────────────┐ │ Partition 0 → Offset: 1050 │ ← 记录消费进度 │ Partition 1 → Offset: 2048 │ │ Partition 2 → Offset: 998 │ └─────────────────────────────────────┘ 存储位置: __consumer_offsets (Topic)Offset 是消息在 Partition 中的唯一标识从 0 开始递增消费者通过 Offset 记录消费位置支持断点续传旧版存储在Zookeeper新版0.9存储在 Kafka 内部 Topic__consumer_offsets五、Kafka 与 Zookeeper 的关系5.1 旧版架构Kafka 3.0┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Zookeeper │◄───▶│ Kafka │◄───▶│ Producer/ │ │ 集群 │ │ Broker │ │ Consumer │ └─────────────┘ └─────────────┘ └─────────────┘Zookeeper 负责Broker 注册记录所有存活节点Topic 元数据分区分配、副本信息、Leader 选举消费者 Offset记录消费进度0.9 版本后改为内部 Topic5.2 新版架构Kafka ≥ 3.0KRaft 模式┌─────────────┐ ┌─────────────┐ │ Kafka │◄───▶│ Producer/ │ │ (自管理) │ │ Consumer │ └─────────────┘ └─────────────┘Kafka 3.0 引入KRaftKafka Raft模式去除 Zookeeper 依赖使用内置的Quorum Controller管理元数据降低运维复杂度六、Kafka 的核心特点总结特性说明高吞吐单机每秒可处理数十万条消息顺序写磁盘性能优异低延迟毫秒级延迟满足实时场景需求可扩展通过 Partition 和 Broker 水平扩展持久性消息持久化到磁盘支持多副本冗余容错性自动故障转移副本机制保证数据不丢失高并发支持数千个客户端同时读写七、Kafka 适用场景日志收集聚合分布式系统的日志数据消息系统替代传统 MQ处理高吞吐消息流处理Kafka Streams 实时计算事件溯源记录系统状态变更事件指标监控收集系统和应用的监控指标如果本文对你有帮助欢迎点赞 收藏 ⭐ 关注 你的支持是我持续创作的动力
