Kafka 入门实战：从核心概念到跑起第一个消息流

消息队列是后端系统解耦的常用工具。当服务 A 不需要立刻等服务 B 的结果时，让 A 把消息写进队列、B 慢慢消费，系统就不再互相拖累。Kafka 是其中最常用的一种，它把消息按主题组织、按分区并行处理，既能扛住高吞吐，也能把数据留下来供多个消费者反复读取。

先把几个核心概念讲清楚。Broker 是 Kafka 的服务节点，多个 Broker 组成集群。Topic 是消息的逻辑分类，好比一个文件夹。每个 Topic 又分成若干 Partition，分区是真正存储消息的单位，也是并行消费的基础。Producer 负责生产消息，Consumer 负责消费消息。多个 Consumer 组成一个 Consumer Group，组内每个分区同一时间只会被一个成员消费，这样既能分工，又不会重复处理。Offset 是消费进度，记录每个分区读到了哪里。

单机体验最省事的办法是用容器启动一个带 ZooKeeper 替代方案的 KRaft 模式节点。准备好容器环境后，用官方镜像以 KRaft 模式启动单个 Broker，映射好端口，等日志里出现启动完成的信息，就可以开始用了。生产环境不要用这种单机方式，至少要三个节点，并把副本数设为 3。

接下来创建第一个主题。用主题管理命令创建一个名为 order-events 的主题，分区数设为 3、副本因子设为 1，单机环境只能用 1 个副本。创建后查看主题列表，确认它已经出现。

然后生产几条消息。打开生产者控制台，输入几条订单相关的 JSON 文本，比如订单创建和订单支付各一条，每条带上订单号作为消息的键。键的作用很重要：相同键的消息会被分到同一个分区，从而保证同一订单的消息按顺序到达。

再打开消费者控制台，从头开始消费这个主题，应该能看到刚才发出的几条消息。接着换一个消费组名再消费一次，会发现消息又从头出现了一遍。这说明消费进度是按消费组保存的，不同组互不影响，这也是 Kafka 能同时服务实时处理和离线分析的原因。

几个关键参数值得记住。acks 决定生产者要等几个副本确认：设为 all 最稳，但最慢；设为 1 速度快，但主副本故障可能丢消息。开启幂等生产者可以避免网络重试导致重复写入。消费端处理完业务再提交 Offset，崩溃重启后会从上次提交处继续，不丢但可能重复消费，所以消费逻辑最好做成幂等的。

新手常踩的坑有三个。第一，消费组重平衡：组成员增减时分区会重新分配，消费端要处理好正在处理的消息。第二，顺序性只在同一个分区内保证，跨分区没有全局顺序，想保序就用键控制分区。第三，分区数一旦定下就只能增加不能减少，扩容前先想清楚并行度和键分布。

跑通上面这条链路后，下一步可以试试：把分区数改成 6 观察消费并行度变化；给消费者加上手动提交 Offset；再写一段小程序，用生产者发消息、用消费者读消息，把控制台操作换成代码。

全文约 1000 字，概念、命令思路、参数与避坑都齐了，适合作为入门第一篇。