Kafka
一个能存住海量消息的高吞吐分布式消息队列
Kafka 最早是 LinkedIn 用来收日志的，后来变成事实上的“数据总线”。它把消息按 Topic 分片、按顺序追加到磁盘，生产者和消费者互不等待，所以能做到百万级吞吐，还能让消息保留好几天供多个下游重复消费。
它解决什么问题
系统 A 每秒产生几万条日志和事件，系统 B、C、D 都要用。如果 A 直接调用它们，A 会被拖死，新增一个下游还要改 A 的代码。
真实场景：典型场景：订单服务把“订单已支付”事件写进 Kafka，风控、积分、推荐、数仓四套系统各自按自己的节奏消费，互不影响。
核心概念
每个概念一句话 + 一个类比。点击卡片看更详细的解释。
Topic
消息的分类目录，同一类消息写进同一个 Topic
类比：一个电视频道，所有人都在这个频道里发节目
看概念详情Partition
Topic 被切成的多份，是并行和顺序的基本单位
类比：一条高速公路的多条车道，车各走各的道
看概念详情Offset
每条消息在分区里的唯一序号，消费者靠它记住读到哪
类比：书签，夹在第 1024 页，下次从这继续读
看概念详情Broker
真正存消息的一台服务器，多个 Broker 组成集群
类比：仓库，一个集群就是一片仓库区
看概念详情Producer
往 Topic 里写消息的程序
类比：寄快递的人
看概念详情Consumer
从 Topic 里读消息的程序
类比：收快递的人
看概念详情Consumer Group
一组消费者分摊分区，一条消息组内只被处理一次
类比：同一个部门的同事轮流处理工单
看概念详情Replica
分区的备份，Leader 挂了 Follower 顶上
类比：重要文件的备份硬盘
看概念详情数据流转动画
跟着步骤看一条数据从进入系统到被处理完的完整路径，可以暂停、重播和调速。
一条消息从 Producer 到 Consumer 的完整路径
← 左右滑动查看完整流程图 →
Producer 把消息序列化、按 key 哈希选出 Partition 0，攒成一批再发。
提示：注意 offset 的推进：消息只会追加，消费者只是移动自己的书签。 悬停图中的节点可以看概念解释。
优劣势
短句说清适合什么、不适合什么，选型时先看这一栏。
- 吞吐极高，百万级消息/秒
- 消息可保留数天，支持多个下游重复消费
- 分区水平扩展，加机器就能扩容
- 生态成熟，流处理（Flink/Spark）默认搭档
- 不支持事务消息（只有事务写，不是业务事务）
- 没有原生延迟消息、消息优先级
- Topic 多时运维和元数据压力大
- 部署依赖 ZooKeeper 或 KRaft，门槛偏高
常见使用场景
每个场景都配一句「为什么用它」。
日志与埋点采集
前端/后端埋点统一写进 Kafka，数仓、监控、告警分别消费。
为什么用它：写入吞吐高，允许短暂堆积，丢一条日志也不影响业务。
事件驱动的微服务
订单、库存、积分服务之间用事件通信，而不是互相调用。
为什么用它：下游可以随时新增，上游不需要改代码。
流式计算的数据源
Flink 从 Kafka 读实时数据，做实时大屏和风控。
为什么用它：分区内有序 + 可回溯，天然适合流处理。
同类对比
和同赛道的组件并排看，差异一目了然。
一句话：吞吐选 Kafka，业务语义选 RocketMQ，路由灵活和轻量选 RabbitMQ。三者不是替代关系，很多公司同时用两个。
常见问题
上手第一个月最容易卡住的地方。
Q1Kafka 怎么保证消息顺序？
只能保证同一个 Partition 内有序，跨分区不保证。要全局有序只能把 Topic 设成 1 个分区，代价是没有并行度；通常做法是把需要有序的消息用同一个 key（比如订单号）打到同一个分区。
Q2为什么 Kafka 吞吐这么高？
四件事：顺序写磁盘、批量发送（batch）、零拷贝（sendfile）、分区并行。再加上消费者自己维护 offset，服务端不做逐条确认。
Q3Kafka 和 RocketMQ 怎么选？
日志、埋点、流处理选 Kafka；电商交易、需要事务消息/延迟消息/顺序消息选 RocketMQ。前者吞吐更高生态更好，后者业务语义更全、运维更轻。
Q4消息会不会丢？
三个环节都要配：生产者 acks=all + 重试；Broker 设置 replication.factor≥3、min.insync.replicas≥2；消费者关闭自动提交，处理完再手动提交 offset。
Q5消费者组里消费者比分区多会怎样？
多出来的消费者分不到分区，会空转。所以并行度上限就是分区数，扩容消费者前先看分区够不够。