Kafka on 追风笔记

Kafka 存储与消费模型

Tue, 25 Aug 2026 00:00:00 +0000

Kafka 的高性能依赖于「分区日志 + 顺序写 + 批量拉取」的设计。理解存储与消费模型，才能合理配置并行度与避免重复消费。

Topic 与 Partition

topic 是逻辑主题，partition 是物理并行单位，消息只追加写入分区末尾。
每个分区是一个有序、不可变的日志，由多个 segment 文件组成，并维护 offset（分区内唯一递增）。
分区数决定了消费的并行上限：一个分区同一时刻只被 group 内一个消费者消费。

Offset 与消费位移

消费者处理完消息后提交的位移称为 offset，Kafka 将其保存在内部 topic __consumer_offsets 中：

Producer -> [partition-0: 0,1,2,3 ...]
 ^
 | committed offset (group A)
Consumer group A 从 offset=4 继续拉取

位移提交方式影响可靠性：

自动提交：间隔提交，可能丢失（提交后未处理崩溃）或重复（处理中崩溃未提交）。
手动提交：处理成功后再提交，配合幂等可实现至少一次/精确一次。

Consumer Group 与 Rebalance

同一 group 内的消费者共同消费 topic 的全部分区，分区在成员间均衡分配。当成员加入/退出时触发 rebalance，重新分配分区。频繁 rebalance 会暂停消费，应控制 session.timeout 与 heartbeat.interval 并避免消费耗时过长。

Kafka 可靠性与精确一次

Tue, 25 Aug 2026 00:00:00 +0000

Kafka 的可靠性需要在 producer、broker、consumer 三端协同配置。下面从「不丢、不重、有序」三个目标展开。

Producer 端的可靠性

通过 acks 控制写入持久化级别：

acks=0：发完即认为成功，可能丢消息，吞吐最高。
acks=1：leader 写入即成功，leader 宕机可能丢。
acks=all：ISR 全部同步才成功，最安全，配合 min.insync.replicas 防单点。

开启重试（retries）可应对瞬时失败，但会带来重复：网络抖动导致 producer 未收到 ack 而重试，同一条消息被写两次。

幂等 Producer 与事务

Kafka 提供 幂等 producer（enable.idempotence=true），broker 用 producerId + 序列号 去重，保证单分区内不重不漏。需要跨分区、跨系统的原子写入时，使用事务（transactional.id）将多次 produce 与 offset 提交纳入一个事务：

producer.initTransactions();
producer.beginTransaction();
producer.send(record1);
producer.send(record2);
producer.commitTransaction(); // 要么都成功，要么都不可见

消费端去重与幂等

即使 producer 幂等，consumer 在 rebalance 或位移提交时机不当时仍可能重复消费。消费端应保证业务幂等：

用唯一键（订单号等）做去重表/唯一索引。
将「处理 + 提交位移」放在同一事务（如消费写 DB 同时记录 offset）。

分区顺序性

Kafka 只保证单分区内有序。需要全局顺序只能单分区（牺牲并行）；需要业务顺序则按 key（如用户 id）分区，使同一 key 落到同一分区，从而在该 key 维度保持顺序。精确一次（EOS）正是幂等 + 事务 + 消费幂等三者叠加的结果。

消息队列选型：Kafka vs Pulsar vs RabbitMQ

Sat, 28 Feb 2026 00:00:00 +0000

消息队列是分布式系统的神经系统，但 Kafka、Pulsar、RabbitMQ 三者的设计哲学差异极大。选错不是「换个客户端」的事，而是架构重做。下面从几个工程最关心的维度拆开看。

模型差异是根本

RabbitMQ：经典消息代理，面向「消息」和「队列」，支持丰富路由（直连、主题、头部、扇出）。适合任务分发、低延迟小消息。
Kafka：日志型、分区有序、拉取消费，面向「流」和「事件溯源」。适合高吞吐、可重放。
Pulsar：计算存储分离，分层架构，原生多租户和跨地域复制。适合既要 Kafka 的流、又要 RabbitMQ 的队列语义的统一平台。

# Kafka 顺序消费依赖分区
bin/kafka-console-consumer.sh \
 --topic orders --bootstrap-server b1:9092 \
 --partition 0 --offset earliest

关键维度对比

维度	Kafka	Pulsar	RabbitMQ
吞吐	极高	极高	中等
消息模型	流/日志	流+队列	队列
顺序性	分区内有序	分区/Key 有序	队列有序
运维复杂度	中	高（含 BookKeeper）	低
消费模型	拉取、可重放	拉取、可重放	推送

选型思路

事件流、日志、可重放 → Kafka 稳。审计、CDC、行为埋点这类场景它的重放能力几乎是刚需。
统一消息平台、多租户、跨地域 → Pulsar 更合适，但团队要扛得住运维。
任务队列、复杂路由、低延迟 → RabbitMQ 更直接。

// 用消息头做复杂路由（RabbitMQ 风格）
channel.basicPublish("orders.topic",
 "order.created.vip", // routingKey
 props, body);

别用 RabbitMQ 扛日均百亿事件流，也别用 Kafka 做需要复杂路由的任务分发——用对的工具，比用最强的工具重要。

Kafka 在交易系统的削峰与解耦

Sat, 28 Mar 2026 00:00:00 +0000

交易系统引入 Kafka 通常出于两个动机：扛住流量尖峰，以及把非核心逻辑从主链路上摘下来。这两件事它都能做，但做法和注意点完全不同。

削峰：把洪峰变成队列

代发工资、批量还款、营销活动这些场景的流量特征是极不均匀——平时每秒几百笔，活动开始瞬间冲到几万笔。数据库扛不住的不是总量，是瞬时并发。

削峰的本质是用延迟换稳定：请求先落 Kafka，下游按自己的处理能力匀速消费。关键是消费端要限速，不能拿到消息就火力全开打数据库。

spring:
 kafka:
 consumer:
 group-id: txn-processor
 enable-auto-commit: false # 必须手动提交
 max-poll-records: 100
 properties:
 max.poll.interval.ms: 300000 # 留足单批处理时间，避免误判掉线
 listener:
 ack-mode: manual
 concurrency: 8 # 与分区数匹配，不要超过

concurrency 超过分区数没有任何收益，多出来的线程只会空转。要提升并行度得先加分区，而分区数一旦加了就减不回去，前期要按峰值容量规划好。

削峰只对"可以延后处理"的业务成立。用户在 App 里点转账等结果的场景不能这么做——那是同步链路，塞消息队列只是把等待转移到了别处。

解耦：从同步调用到事件

主链路上挂着一堆下游是很常见的技术债：转账成功后要发短信、更新积分、推送风控特征、写数仓。每加一个下游，主链路的失败面就大一分。

改成发一条 transfer.posted 事件，各下游自己订阅。主链路只负责记账和发事件，下游挂了不影响交易成功。

需要划清界限的是：哪些下游能异步。判断标准是这个下游失败后，业务上能不能接受"稍后补上"。更新积分可以，扣减额度不行——额度是交易准入条件，必须同步。

几个必须守住的细节

顺序只在分区内保证。同一账户的消息必须用账户号做 key，否则先扣款后入账的顺序可能颠倒。跨账户不需要全局顺序，别为了顺序把分区数设成 1。
消费端必须幂等。Kafka 是至少一次投递，重复是常态。用业务唯一键加唯一索引兜住，不要指望不重复。
先处理成功再提交 offset。自动提交会在处理失败时丢消息。手动提交虽然会带来重复，但重复有幂等兜着，丢了就找不回来了。
积压要能定位到分区。整体 lag 正常但单分区堆积，通常是某个 key 数据倾斜或者某条消息反复失败阻塞了分区。

# 按分区查看消费延迟，定位倾斜与阻塞
kafka-consumer-groups.sh --bootstrap-server "$BROKERS" \
 --group txn-processor --describe

# 排查反复失败的毒消息：从指定 offset 读一条看内容
kafka-console-consumer.sh --bootstrap-server "$BROKERS" \
 --topic txn-events --partition 3 --offset 88213 --max-messages 1

毒消息一定要有出路。处理失败超过阈值就转到死信 topic，让分区继续往下走，否则一条脏数据能把整个分区卡死几个小时。