Kafka消息中间件实战：生产者可靠性投递与消费者重平衡优化

Kafka是后端开发中应用最广的消息中间件，承担订单、日志、事件流等核心链路。用得好的团队能拿到吞吐和低延迟，用不好的团队会遇到消息丢失、重复消费、重平衡风暴。本文围绕Kafka消息中间件的生产实践，拆解生产者可靠性投递、消费者组管理与重平衡、消息堆积治理三个关键环节。

生产者端：acks与幂等生产者保证不丢消息

消息丢失多数发生在生产者端。acks=0不等确认，网络抖动就丢；acks=1只等leader确认，leader宕机会丢；acks=all配合min.insync.replicas才能扛住副本故障。同时开启enable.idempotence，让生产者具备幂等能力，避免重试产生重复消息：

# producer.properties
acks=all
enable.idempotence=true
max.in.flight.requests.per.connection=5
retries=2147483647
delivery.timeout.ms=120000

注意enable.idempotence开启后，max.in.flight可放宽到5，不影响顺序。发送结果要检查RecordMetadata，发送失败按业务重试，而不是静默丢弃。

消费端架构：消费者组与分区分配

消费能力由分区数决定，一个分区同一时刻只被组内一个消费者消费。扩容消费者数量超过分区数时，多出来的消费者空闲；要提升消费吞吐，先加分区数。消费逻辑建议用异步批量处理加手动提交offset：

props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "false");
// 拉取100条后批量入库，再提交offset
List<ConsumerRecord> batch = poll(500);
process(batch);
consumer.commitSync();  // 业务成功才提交

手动提交的原则：先处理业务再提交offset，业务失败不提交，让消息重新消费。但这也带来重复消费的可能，业务侧要做好幂等。

消费重试与死信队列

消费失败直接提交offset会丢消息，无限重试又会阻塞分区。标准做法是分级重试：瞬时错误（连接、锁）延迟重试3-5次；持久错误（数据非法）直接进死信主题（DLT），由人工或补偿任务处理。重试通过消费端schedule实现，死信主题用retry次数字段标记。用Spring Kafka可以配置：

spring.kafka.consumer.properties:
  max.poll.interval.ms: 300000
  max.poll.records: 500

@RetryableTopic(attempts = "4", backoff = @Backoff(delay = 1000, multiplier = 2))
@KafkaListener(topics = "order-events")
public void onOrderEvent(OrderEvent event) {
    orderService.handle(event);
}

重平衡风暴与消费者滞后治理

消费者组频繁重平衡是Kafka集群性能劣化的典型症状，根因通常是：消费者心跳超时、消费耗时过长超过max.poll.interval.ms、分区数远大于消费者数。治理手段：调大max.poll.records控制单批处理量；监控Lag（积压），用Kafka lag exporter或Burrow做告警；峰值期提前扩容分区和消费者。Lag持续增长比偶发消费失败更危险，代表消费能力跟不上生产速度。

压测与监控落地

上线前用kafka-producer-perf-test和kafka-consumer-perf-test做吞吐压测，明确单分区吞吐上限。监控指标必看：生产端request-latency、消费端records-lag-max、分区数、消费者组成员数。Broker层看磁盘IO和页缓存命中率，磁盘满和IO打满是Broker宕机的两大元凶。消息中间件的可靠性是设计出来的，不是靠运气。