标签: Kafka

Kafka 的可靠性需要在 producer、broker、consumer 三端协同配置。下面从「不丢、不重、有序」三个目标展开。 Producer 端的可靠性 通过 acks 控制写入持久化级别： acks=0：发完即认为成功，可能丢消息，吞吐最高。 acks=1：leader 写入即成功，leader 宕机可能丢。 acks=all：ISR 全部同步才成功，最安全，配合 min.insync.replicas 防单点。 开启重试（retries）可应对瞬时失败，但会带来重复：网络抖动导致 …

Kafka 的高性能依赖于「分区日志 + 顺序写 + 批量拉取」的设计。理解存储与消费模型，才能合理配置并行度与避免重复消费。 Topic 与 Partition topic 是逻辑主题，partition 是物理并行单位，消息只追加写入分区末尾。 每个分区是一个有序、不可变的日志，由多个 segment 文件组成，并维护 offset（分区内唯一递增）。 分区数决定了消费的并行上限：一个分区同一时刻只被 group 内一个消费者消费。 Offset 与消费位移 消费者处理完消息后提交的位移称为 …

交易系统引入 Kafka 通常出于两个动机：扛住流量尖峰，以及把非核心逻辑从主链路上摘下来。这两件事它都能做，但做法和注意点完全不同。 削峰：把洪峰变成队列 代发工资、批量还款、营销活动这些场景的流量特征是极不均匀——平时每秒几百笔，活动开始瞬间冲到几万笔。数据库扛不住的不是总量，是瞬时并发。 削峰的本质是用延迟换稳定：请求先落 Kafka，下游按自己的处理能力匀速消费。关键是消费端要限速，不能拿到消息就火力全开打数据库。 spring: kafka: consumer: group-id: …

消息队列是分布式系统的神经系统，但 Kafka、Pulsar、RabbitMQ 三者的设计哲学差异极大。选错不是「换个客户端」的事，而是架构重做。下面从几个工程最关心的维度拆开看。 模型差异是根本 RabbitMQ：经典消息代理，面向「消息」和「队列」，支持丰富路由（直连、主题、头部、扇出）。适合任务分发、低延迟小消息。 Kafka：日志型、分区有序、拉取消费，面向「流」和「事件溯源」。适合高吞吐、可重放。 Pulsar：计算存储分离，分层架构，原生多租户和跨地域复制。适合既要 Kafka 的流 …