Kafka
分布式消息与流处理平台。以可持久化的分区日志为核心，支撑高吞吐的消息传递与事件流处理。
又称Apache Kafka
技术组件
核心模型
Kafka 的本质是分布式提交日志：
- Topic 是逻辑上的消息类别，Partition 是物理分片，每个分区是一个有序、不可变、可重放的日志。
- 分区内有序，分区间无序。要保证同一实体的顺序，就必须用同一个 key 把它们路由到同一分区。
- Consumer Group 内的消费者分摊分区，组间互不影响，因此同一份数据可以被多个系统各自消费。
- 消息不靠 broker 推送，而是消费者主动拉取，消费进度（offset）由消费者自己维护。
为什么说它「可重放」
Kafka 的消息按保留策略（默认 7 天，也可按大小或永久保留）落盘，不会因为被消费就删除。这意味着新上线的消费者可以从头读取历史数据——这是构建事件溯源、缓存重建、数据同步的基础。
投递语义
| 语义 | 实现代价 | 典型场景 |
|---|---|---|
| 至多一次 | 最低，容忍丢失 | 指标上报 |
| 至少一次 | 默认，需业务幂等 | 绝大多数场景 |
| 精确一次 | 事务 + 幂等生产者 | 金融记账 |
银行场景里，「至少一次 + 业务幂等」通常比追求精确一次更实用：把幂等做在业务侧（流水号去重），比依赖中间件的事务更简单也更可验证。
常见坑
- 分区数一旦增加，key 到分区的映射就变了，会打破原有的顺序保证。
- 消费者处理慢导致 rebalance，进而引发「消费停顿—积压—再 rebalance」的死亡螺旋。
- 把 Kafka 当消息队列用（比如依赖单条消息的确认与重试），会踩到它作为日志系统的设计边界。
提及本词的文章
- Kafka 存储与消费模型topic/partition 物理结构、offset 与消费位移、consumer group 与 rebalance、拉取模型。
- Kafka 可靠性与精确一次producer acks 与重试、幂等 producer 与事务、消费端重复与幂等处理，以及分区顺序性保证。
- 消息队列选型：Kafka vs Pulsar vs RabbitMQ从模型、吞吐、顺序性和运维复杂度对比三款主流消息中间件，给出银行场景下的选型思路。
- Kafka 在交易系统的削峰与解耦记录 Kafka 在交易系统中做削峰填谷与业务解耦的实践，以及顺序、幂等和积压处理上必须守住的细节。