kafka

Kafka 核心概念、CLI 与生产消费要点

补充说明

kafka 是分布式事件流平台，数据按 Topic 追加到 Partition 日志，Partition 通过 Replica 复制到多个 Broker。每个 Partition 有一个 Leader 和若干 Follower，ISR 是与 Leader 保持同步的副本集合；Consumer Group 把 Partition 分配给成员，同一 Partition 在同一时刻只由一个成员消费。

它解决高吞吐削峰、系统解耦、事件回溯和流处理的数据底座问题。与 RabbitMQ 的队列/确认模型不同，Kafka 保留日志并按 offset 消费，消费者可以重放；与 Pulsar 相比，Kafka 的分区模型更简单，生态和 Connect 连接器更成熟。Broker 启动、磁盘、副本重分配等运维细节见 kafka-broker 页面。

KRaft 模式用 Controller quorum 取代 ZooKeeper，元数据也走 Raft；生产要规划 node.id、controller.quorum.voters、process.roles 和 advertised.listeners。客户端只依赖 bootstrap servers，但拿到的是 broker 返回的 advertised 地址，内网/外网监听要分别配置。

常用示例

kafka-topics.sh --bootstrap-server broker:9092 --create --topic orders --partitions 12 --replication-factor 3 --config min.insync.replicas=2 --config retention.ms=604800000
kafka-topics.sh --bootstrap-server broker:9092 --list
kafka-topics.sh --bootstrap-server broker:9092 --describe --topic orders
kafka-configs.sh --bootstrap-server broker:9092 --alter --entity-type topics --entity-name orders --add-config retention.ms=86400000
kafka-console-producer.sh --bootstrap-server broker:9092 --topic orders --property parse.key=true --property key.separator=:
kafka-console-consumer.sh --bootstrap-server broker:9092 --topic orders --group debug --from-beginning --property print.key=true
kafka-consumer-groups.sh --bootstrap-server broker:9092 --list
kafka-consumer-groups.sh --bootstrap-server broker:9092 --describe --group order-service
kafka-consumer-groups.sh --bootstrap-server broker:9092 --group order-service --topic orders --reset-offsets --to-earliest --dry-run
kafka-consumer-groups.sh --bootstrap-server broker:9092 --group order-service --topic orders --reset-offsets --to-earliest --execute
kafka-get-offsets.sh --bootstrap-server broker:9092 --topic orders
kafka-metadata-quorum.sh --bootstrap-server broker:9092 describe --status
kafka-storage.sh random-uuid
kafka-storage.sh format -t <uuid> -c config/kraft/server.properties
kafka-server-start.sh config/kraft/server.properties

生产者与消费者关键参数：

# producer
acks=all
enable.idempotence=true
retries=2147483647
max.in.flight.requests.per.connection=5
delivery.timeout.ms=120000
linger.ms=5
batch.size=16384
compression.type=lz4

# consumer
group.id=order-service
enable.auto.commit=false
auto.offset.reset=earliest
max.poll.records=500
max.poll.interval.ms=300000
isolation.level=read_committed

常见配置

Broker/Topic 侧常用项：

num.partitions=12
default.replication.factor=3
min.insync.replicas=2
auto.create.topics.enable=false
log.retention.hours=168
log.segment.bytes=1073741824
offsets.topic.replication.factor=3
transaction.state.log.replication.factor=3
unclean.leader.election.enable=false

num.partitions 服务端默认 1，retention.ms 默认 604800000（7 天），segment.bytes 默认 1GiB，min.insync.replicas 默认 1；生产不要依赖这些默认值。acks=all + min.insync.replicas=2 + 3 副本，才能在单副本故障时仍可写。

易错点与排错

• advertised.listeners 配错时 bootstrap 能连上，但客户端拿到不可达的 broker 地址；内外网要分别配置 listener。
• 副本因子大于 broker 数会创建失败；ISR 小于 min.insync.replicas 时 acks=all 写入报 NotEnoughReplicas。
• 自动建 Topic 会使用服务端默认分区和副本，容易不符合生产要求；关闭 auto.create.topics.enable，显式建 Topic。
• Key 为 null 时按批次粘性分区，Key 相同才保证同分区；热点 Key 会造成单分区倾斜，需要拆 Key 或加随机后缀。
• 消费滞后看 LAG，处理时间超过 max.poll.interval.ms 会触发再平衡；减小 max.poll.records 或异步处理。
• 自动提交发生在处理前会丢消息；关闭 enable.auto.commit，处理成功后手动提交，并接受重复消费。
• 再平衡风暴常由会话超时过短、滚动发布和长处理引起；用静态成员 group.instance.id 和 cooperative-sticky 降低影响。
• Offset 超出保留范围会报 OffsetOutOfRange；消费者停机时间不能超过 retention.ms/bytes，必要时重置位点。
• 顺序只在分区内保证；重试、无幂等时的 max.in.flight>5 和多分区都会破坏顺序。
• 事务消息要设 transactional.id，消费端用 isolation.level=read_committed，否则会读到已中止的记录。
• KRaft 集群 ID、node.id 或 voters 不一致会导致格式化/启动失败；用 kafka-metadata-quorum.sh describe --status 检查 quorum。
• 消息超过 max.message.bytes 会被拒；同时调整 broker 和 producer 的 max.request.size，优先压缩或拆分。

相关命令

• kafka-broker — Broker 启动、副本与磁盘运维
• kafka-connect — 连接器与数据集成
• kafka-cheatsheet — Kafka 常用命令速查
• kafka-vs-pulsar — 消息平台选型对比
• kafka-consumer-lag — 消费滞后与再平衡排查

读完自测

1. Partition、Replica、ISR 和 Consumer Group 之间是什么关系？
2. acks=all、min.insync.replicas=2、3 副本同时满足时能容忍什么故障？
3. 为什么关闭自动提交后仍可能重复消费？