欢迎光临
我们一直在努力
        找回密码
当前位置：171主机测评 > 服务器技术 > 正文

【Kafka 进阶之路】Kafka 消息队列详解

2026-03-16 分类：服务器技术 阅读(63) 评论(0)

✋ 简介：大家好 ~ 欢迎来到青蛙的池塘，这里是技术分享的池塘 ~ 📕 系列专栏：Java 源码系列、优化方案系列、生产问题系列等 💡 博主正在努力完成 2025 – 2026 年计划：基石计划 ✍️ 雄关漫道真如铁，而今迈步从头越！ 🔥 如果觉得有收获的话，别忘了点赞 👍 收藏 ⭐️ 哦 ~

文章目录

  • 消息队列
    • 三大核心功能
      • 削峰填谷
      • 异步处理
      • 解耦
  • Kafka 版本演进
    • 0.8 版本：Kafka 初成立
    • 0.11 版本：引入幂等性和事务功能
    • 2.0 版本：安全与性能
    • 2.8+3.0 版本：新架构去中心化
    • 4.0 版本：全新全能
    • 版本重大更新图示
  • Kafka的特点
  • Kafka的架构是怎么样的？

消息队列

说白了，消息队列就是个 “中转站 + 缓冲带”，专门帮不同系统传话。举个例子：你在网上买了个杯子，商家（生产者）得把发货信息告诉快递员（消费者），它会经历这三步：

  • 先把包裹（消息）存起来，不让它丢；
  • 按顺序排好队，按顺序进行存取；
  • 让发消息的一方（商家）不用等收消息的一方（快递员），两边可以各干各的，不用同步等待对方。

    • 三大核心功能

    还是以快递为例子来介绍消息队列的三大核心功能~ 请添加图片描述

    削峰填谷

    想象你家楼下的快递站（消息队列）平时每天收 100 件快递，3 个快递员（消费者 / 后端系统）刚好能送完，岁月静好～ 但双十一当天，电商商家（生产者）疯狂发货，一下子涌来 5000 件快递！要是没有快递站就会出现以下问题：

  • 快递员直接被堆成山的包裹压垮（系统过载崩溃）；
  • 晚来的包裹可能被挤丢（数据丢失）；
  • 商家还得等着快递员收件，没法继续处理订单（生产端阻塞）。

    • 有了快递站的削峰填谷，针对上述的问题：

  • 先把 5000 件快递全部存进仓库（队列缓存），按顺序排好队；
  • 3 个快递员按自己的节奏，每天送 100 件，慢慢消化库存（系统按处理能力消费）；
  • 哪怕后续还有新包裹来也得先排队，不会让快递员和商家崩溃。

    • 异步处理

    以前没有菜鸟之类的快递站时，商家发货得这么干：

  • 打包好包裹，打电话叫快递员上门；
  • 等快递员到店、扫码、确认收件，商家才能在系统上标记 “已发货”； 这会有个潜在的问题，要是快递员堵车或者忙别的，商家就得一直等，后面的订单全被卡住（同步阻塞）~

    • 有了快递站我们就可以这样操作：

  • 商家打包好包裹，直接送到快递站（发送消息到队列），快递站给个 “回执”；
  • 商家拿到回执，立刻在系统上标记 “已发货”，转身继续处理下一个订单（生产者立即返回，不等待）；

    • 快递员后续什么时候来取件、什么时候送货（消费者异步处理），商家完全不用管 —— 既提升了商家的发货效率，也不用让用户等半天才能看到 “已发货” 状态，这样就解决了上述的问题~

    解耦

    解耦这种思维在程序设计中很重要！！ 还是以前的老模式：

  • 商家得记着每个快递员的电话、配送范围，快递员换了人，商家就得重新对接（强依赖）；
  • 快递员得知道商家的营业时间、打包要求，商家改了地址，快递员就得重新记（耦合紧密）；
  • 要是快递员生病请假，商家的包裹就没人收，直接卡壳（一个环节故障，全链路瘫痪）

    • 有了快递站之后：

  • 商家只需要和 “快递站” 对接：把包裹送到快递站，约定好包裹格式（比如贴好快递单），至于后续是哪个快递员送、怎么送、什么时候送，商家一概不管；
  • 快递员也只需要和 “快递站” 对接：每天到快递站取件，按快递单送货，至于包裹是哪个商家的、怎么打包的，快递员也不用关心；

    • 就算快递员辞职、商家换地址，只要还和快递站对接，对方完全不受影响，这就是解耦，让每个环节都能独立运作

    Kafka 版本演进

    0.8 版本：Kafka 初成立

    • 核心突破：首次引入消息副本机制，提供数据持久化和高可用性保障 ~
    • 重要改进：
      • 实现了分布式架构的核心 ——Leader-Follower 模式，支持自动故障转移；
      • 引入新 Producer API，从直接连接 ZooKeeper 转向连接 Broker，简化架构；
      • 支持消息批量发送，大幅提升性能；

    0.11 版本：引入幂等性和事务功能

    • 生产者幂等性：通过 “PID + 序列号” 机制，确保消息即使因网络问题重传也不会重复消费，实现 “Exactly-Once” 精确一次语义~
    • 事务支持：允许跨分区的原子性操作，确保 “要么全成功，要么全失败”，特别适合金融等强一致性场景
    • 消息格式重构（V2 版本），为后续功能扩展奠定基础

    2.0 版本：安全与性能

    • 安全：
      • 支持 OAuth2 认证和前缀 ACL 权限控制，实现 “精细到消息级别的权限管理”；
      • 默认开启 SSL 连接主机名验证，防止中间人攻击；
      • 增强了数据加密和传输保护机制；
    • 性能：
      • 优化内存使用和垃圾回收，减少服务器宕机风险；
      • 支持 ZStandard 压缩，大幅减少磁盘空间占用和网络 I/O 消耗（压缩率比 Gzip 提升 30%+）；
      • 增强消费者组协议，减少 Rebalance 开销（对，就是你想的哪个极其影响性能的 Re）；

    2.8+3.0 版本：新架构去中心化

    • KRaft 模式：
      • 引入KRaft 元数据管理机制，彻底告别对 ZooKeeper 的依赖（使用过的同学都知道这玩意有多重）
      • 将元数据管理直接集成到 Kafka 内部，减少外部依赖，提升系统稳定性
      • 使集群管理和部署变得更加简单，故障恢复速度提升 50% 以上
    • 性能飞跃：
      • 支持百万级分区（之前仅支持几万），大幅扩展应用场景（不仅限于消息队列了！）
      • 控制器故障恢复从 “秒级” 降至 “毫秒级”，几乎让故障 “无感”
      • Producer 默认启用最强交付保证（acks=all + 幂等性），确保消息万无一失

    4.0 版本：全新全能

    • 队列功能：
      • 引入 “共享组 (Share Group)” 机制，让 Kafka 原生支持传统队列语义
      • 允许多消费者并行处理同一分区消息，实现 “点对点” 消息传递模式
      • 支持消息级 ACK/NACK 确认，提供更精细的消息控制（类似 RabbitMQ 的手动确认）
    • 彻底独立：
      • 完全移除对 ZooKeeper 的支持，默认仅运行 KRaft 模式，架构更加简洁
      • 全新的消费者组重平衡协议（KIP-848），几乎消除 “Stop-the-World” 现象，让服务更加稳定
      • 增强的客户端自恢复能力，在遇到网络问题时能主动重新连接

    版本重大更新图示

    在这里插入图片描述

    Kafka的特点

  • 高吞吐量：通过分区并行化和顺序I/O，支持每秒百万级消息处理。
  • 持久性与可靠性：消息持久化到磁盘，副本机制保证数据不丢失（持久性可配置）。
  • 可扩展性：水平扩展broker或分区，轻松应对数据量增长。
  • 容错性：自动故障转移；副本选举确保高可用性。
  • 低延迟：生产者到消费者的延迟通常在毫秒级，适合实时流处理。
  • 高并发：支持数千个客户端同时读写

    • Kafka的架构是怎么样的？

    Kafka 的整体架构比较简单，是显式分布式架构，主要由 Producer（生产者）、broker（Kafka集群）和 consumer（消费者） 组成。

  • 生产者（Producer）：生产者负责将消息发布到Kafka集群中的一个或多个主题(Topic)，每个Topic包含一个或多个分区（Partition）。 主题：Topic。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务。 分区：Partition。一个有序不变的消息序列。每个主题下可以有多个分区。
  • 消费者（Consumer）：消费者负责从Kafka集群中的一个或多个主题消费消息，并将消费的偏移量（Offset）提交回Kafka以保证消息的顺序性和一致性。 偏移量：Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值。
  • 主题（Topic）：消息的逻辑分类单位，类似于数据库中的表。每个主题被划分为多个分区（Partition），以实现并行处理和数据分布。
  • Kafka集群：Kafka集群是由多个Kafka节点（Broker）组成的分布式系统。每个节点都可以存储一个或多个主题（topic）的分区（partition）副本，以提供高可用性和容错能力。
  • 分区（Partition）：主题的物理分片，每个分区是一个有序、不可变的日志序列。消息在分区内按顺序追加，并分配一个唯一的偏移量（Offset），例如消息的索引可表示为offset。分区允许Kafka水平扩展。
  • 代理（Broker）：Kafka集群中的服务器节点，负责存储消息、处理生产者和消费者的请求。一个集群由多个broker组成，每个broker托管多个分区副本。
  • 副本（Replica）：每个分区有多个副本（通常为3个），包括一个领导者（Leader）副本和多个追随者（Follower）副本。领导者处理读写请求，追随者用于数据备份和高可用性。
  • ZooKeeper（或Kraft模式）：在早期版本中，ZooKeeper用于管理集群元数据（如broker状态、主题配置）。Kafka 2.8+版本引入了Kraft模式，使用内置共识协议替代ZooKeeper，简化了架构。
  • 消费者组（Consumer Group）：一组消费者共享订阅主题，每个分区只被组内的一个消费者消费，实现并行处理和故障转移。
  • 如果消费者实例在同一个消费组中，消息记录会依次负载均衡到消费组中的每一个消费者实例
  • 如果消费者实例在不同的消费组中，则会将每条消息记录广播到所有的消费组或消费者进程中

    • 在这里插入图片描述

    如上图中，包含了 Broker1、Broker2和 Broker3组成了一个集群。用来提升高可用性。 在集群中，每个分区（partition）都可以有多个副本。这些副本中包含了一个 Leader （也可以叫做Leader Partition 或者 Leader Replication） 和多个 Follower （也可以叫做Follower Partition 或者 Follower Replication），只有 Leader 才能处理生产者和消费者的请求，而 Follower 只是 Leader 的备份，用于提供数据的冗余备份和容错能力。如果 Leader 发生故障，Kafka 集群会自动将 Follower 提升为新的 Leader ，从而实现高可用性和容错能力。

    赞(0)
    未经允许不得转载：171主机测评 » 【Kafka 进阶之路】Kafka 消息队列详解
    分享到： 更多 (0)
    标签：

    相关推荐

    评论 抢沙发

    取消

    • 昵称 (必填)
    • 邮箱 (必填)
    • 网址

    热门标签

    #人工智能(58429)#python(19842)#开发语言(16680)#java(15321)#运维(15239)#linux(14852)#大数据(14434)#服务器(12972)#算法(11675)#前端(10771)#网络(9280)#数据库(8805)#ai(8753)#c++(8098)#课程设计(6775)#学习(6698)#机器学习(6642)#区块链(5869)#OpenClaw(5384)#后端(5092)#spring boot(4976)#深度学习(4878)#c语言(4347)#毕业设计(4286)#数据结构(4166)#安全(4001)#docker(3906)#架构(3816)#javascript(3781)#大模型(3613)

    热门文章

    最新文章

    归档

    分类