2. Kafka基础概念
在金融行情场景中，Kafka 之所以能承载每秒数十万甚至上百万条的行情推送，并不是因为某个单点组件特别快，而是因为一整套概念模型把“写入、存储、读取、消费进度”拆成了可并行、可扩展、可恢复的单元。理解这套模型，是后续做高吞吐管道调优的前提。本节围绕七个核心概念展开，并说明它们在行情链路中的真实含义。
一、核心原理：从一条行情到一次可追溯的读取
Kafka 的最小存储与并行单位不是“消息”，而是 Partition（分区）。一个 Topic（主题） 只是逻辑名称，例如 market.quote.realtime；它被切分为多个 Partition，每个 Partition 是一个有序、不可变、追加写的日志文件。消息一旦写入，就获得该分区内唯一的、单调递增的编号，这就是 Offset（偏移量）。
Broker 是运行 Kafka 服务的节点，负责接收写入、持久化日志、响应读取。多个 Broker 组成集群，Partition 会按副本因子分布到不同 Broker 上，其中 Leader 处理读写，Follower 负责同步备份。Producer（生产者） 决定消息进入哪个 Partition；Consumer（消费者） 按 Offset 顺序拉取消息；Consumer Group（消费者组） 则把多个消费者组织起来，让同一 Topic 的不同 Partition 被组内成员分摊消费，从而实现水平扩展。
二、方法流程：一条行情消息的完整生命周期
- Producer 序列化并选择分区。行情网关把股票代码、价格、成交量封装为消息；若指定了 key（如股票代码），Kafka 按 key 的哈希值选择 Partition，保证同一股票进入同一分区。
- Broker 追加写入 Leader 副本。消息以追加方式写入分区日志，返回 Offset。此时消息对消费者可见。
- Follower 同步副本。副本因子为 3 时，消息需被 ISR（同步副本集合）确认，才能满足
acks=all的可靠性要求。 - Consumer 按 Offset 拉取。消费者记录自己消费到的位置，提交 Offset 表示“这条及之前已处理”。
- Consumer Group 再平衡。当消费者增减或分区变化时，组内重新分配 Partition，保证每个 Partition 在同一时刻只被组内一个消费者读取。
# 查看行情 Topic 的分区与副本分布
kafka-topics.sh --bootstrap-server broker-a:9092 \
--describe --topic market.quote.realtime
# 输出示例
Topic: market.quote.realtime PartitionCount: 3 ReplicationFactor: 3
Partition: 0 Leader: 1 Replicas: 1,2,3 Isr: 1,2,3
Partition: 1 Leader: 2 Replicas: 2,3,1 Isr: 2,3,1
Partition: 2 Leader: 3 Replicas: 3,1,2 Isr: 3,1,2三、案例场景：行情管道中的分区与消费组设计
假设某券商行情平台需要同时支撑三类下游：实时风控、行情落库、策略回放。上游行情网关每秒推送 20 万条逐笔委托。若只建 1 个 Partition，则写入和消费都无法并行，单消费者必然积压。合理做法是：Topic 设置 12 个 Partition，Producer 以股票代码为 key，使同一股票有序；风控组用 12 个消费者并行消费，落库组用 6 个消费者批量写入，回放组则从最早 Offset 开始独立消费。三个 Consumer Group 各自维护 Offset，互不干扰。
| 概念 | 金融行情中的角色 | 关键参数/行为 |
|---|---|---|
| Topic | 行情主题，如逐笔、快照、指数 | 逻辑分类，不直接决定并行度 |
| Partition | 并行与有序的基本单位 | 数量决定最大消费并行度 |
| Broker | 行情集群节点 | Leader 读写，Follower 同步 |
| Producer | 行情网关/采集端 | key 决定分区，acks 决定可靠性 |
| Consumer | 风控、落库、回放等下游 | 按 Offset 拉取，可重复消费 |
| Offset | 消费进度与回溯依据 | 提交策略影响重复与丢失 |
| Consumer Group | 同类下游的横向扩展单元 | 组内分区独占，组间互不影响 |
四、误区与复盘：行情高吞吐中最容易踩的坑
误区一：Partition 越多越好。分区过多会增加 Broker 元数据、文件句柄和再平衡成本。行情场景建议按“峰值吞吐 ÷ 单分区可承载吞吐”估算，并预留 1.5 倍余量，而不是盲目设成几百个。
误区二：用 null key 追求均匀。null key 会轮询分区，导致同一股票的消息散落到不同 Partition，下游无法保证逐笔有序。行情场景应优先用股票代码作为 key。
误区三：Consumer 数超过 Partition 数。同一 Consumer Group 内，多余的消费者会空闲。若风控组有 12 个 Partition，部署 20 个消费者，其中 8 个不会分到分区。
误区四：自动提交 Offset 导致重复或丢失。行情落库若先提交后处理，进程崩溃会丢数据；若先处理后提交，则可能重复。应根据业务选择手动提交，并配合幂等写入。
复盘口诀：Topic 定业务，Partition 定并行，key 定顺序，Offset 定进度，Consumer Group 定扩展。把这五句话对应到行情链路的每个环节，就能快速判断瓶颈出在写入、存储还是消费侧。
掌握这些概念后，后续讨论吞吐调优、副本可靠性、消费积压排查时，才能准确判断问题发生在 Producer 分区策略、Broker 副本同步，还是 Consumer Group 的 Offset 提交与再平衡环节。