Kafka消息队列实战：生产者可靠性投递与消费者幂等处理

消息队列在分布式系统里承担削峰填谷与解耦的职责，但消息丢失、重复消费、堆积是三个绕不开的生产问题。Kafka作为高吞吐消息中间件，可靠性投递不取决于单一环节，而是生产者、Broker、消费者三段配置共同作用的结果。这篇文章按数据流顺序，说明每一段怎么配才能做到不丢消息、不重复处理。

Kafka可靠性模型：ack机制与ISR副本同步

Kafka的生产者默认配置可能丢消息。生产端可靠性由acks参数决定：acks=0不等待确认，吞吐最高但可能丢；acks=1等Leader确认，宕机窗口可能丢；acks=all等ISR全部同步，最可靠。ISR（In-Sync Replicas）是维持同步的副本集合，Leader写入后向ISR内副本复制，只有ISR中的副本才有资格接任Leader。

配合min.insync.replicas设置，当ISR数量低于阈值时拒绝写入，宁可写入失败也不接受只有单副本的假成功。生产者端同时开启retries与enable.idempotence，幂等生产者用PID加序列号去重，避免重试导致的消息重复。

生产者可靠性投递实战：同步确认与幂等配置

Properties props = new Properties();
props.put("bootstrap.servers", "kafka-1:9092,kafka-2:9092");
props.put("acks", "all");
props.put("retries", Integer.MAX_VALUE);
props.put("max.in.flight.requests.per.connection", 5);
props.put("enable.idempotence", true);
props.put("delivery.timeout.ms", 120000);

KafkaProducer<String, String> producer = new KafkaProducer<>(props);
producer.send(new ProducerRecord<>("orders", key, value), (meta, ex) -> {
    if (ex != null) {
        // 写入本地重试队列，交给补偿任务重发
        retryQueue.offer(new RetryMessage(topic, key, value));
    }
});

发送带回调，异常进入本地重试队列，由补偿任务按退避策略重发，避免进程内重试无上限拖垮业务线程。enable.idempotence与acks=all配合后，Broker端自动去重，这一层保证了at-least-once语义。

Broker持久化配置：刷盘与副本因子

Broker端防丢失的配置集中在两个点：副本因子与刷盘。副本因子（replication.factor）生产环境不低于3，且min.insync.replicas设为2。分区副本分布要跨机架，避免单机故障带走全部副本。

日志刷盘由log.flush.interval.messages与log.flush.interval.ms控制，默认值偏宽松，写缓存中的数据在崩溃时可能丢失。对可靠性要求高的场景调小刷盘间隔，代价是写放大。更常见的做法是依赖OS页缓存加副本机制，单机掉电场景用副本兜底。

消费者端幂等处理：唯一键与手动提交

at-least-once语义下，消费者可能重复收到消息，处理逻辑必须幂等。最通用的方案是业务唯一键：处理前查库判断是否已处理，处理时用唯一索引兜底。示例：订单消息用order_id做唯一键，插入订单表时依赖数据库唯一约束，重复消息插入失败直接忽略。

INSERT INTO order_events(order_id, status, created_at)
VALUES (?, ?, NOW())
ON DUPLICATE KEY UPDATE status = VALUES(status);

消费端同时要处理两类场景：enable.auto.commit设为false，业务处理成功后再手动提交offset；处理与提交之间进程崩溃，重启后会重复消费一批，靠幂等兜底。需要事务一致性时，用Kafka事务API实现跨分区原子写入，或与数据库本地事务组合成事务性消息模式。

消息堆积排查与消费能力评估

消息堆积通常由三个原因：消费者数量少于分区数、单个消费者处理耗时过长、下游依赖变慢。排查顺序：先看消费者组分区分配是否均衡，再看单条处理耗时与GC停顿，最后确认下游接口是否超时。消费者并发上限是分区数，增加消费者进程不解决分区不足的问题，此时要扩大分区并做数据重分布。

Kafka可靠投递的完整链路是：生产者幂等加all确认、Broker副本与刷盘、消费者手动提交加业务幂等。每个环节单独看都是标准配置，串起来才能保证数据不丢不重。