Kafka是如何保证消息队列中的消息不丢失、不重复？

如何保证消息队列中的消息不丢失、不重复？

作为一名拥有八年 Java 后端开发经验的工程师，在分布式系统开发过程中，消息队列的应用越来越广泛，它不仅能实现系统解耦、异步处理，还能削峰填谷。但随之而来的消息丢失和重复问题，却像两颗 "定时炸弹"，时刻威胁着系统数据的完整性和业务逻辑的准确性。在经历了无数次 "踩坑" 与 "填坑" 后，我总结出一套保障消息队列可靠性的实战经验，今天就来和大家分享如何保证消息队列中的消息不丢失、不重复。

一、消息不丢失的保障策略

（一）消息生产阶段

在 Java 中，使用消息队列客户端发送消息时，以 Kafka 为例，默认情况下，生产者发送消息是异步且不保证消息是否成功写入到 Broker。为了确保消息发送成功，我们可以开启同步发送 ，通过调用send()方法的返回值，获取Future对象，使用get()方法等待发送结果，捕获可能出现的异常。不过同步发送会降低发送性能，所以更常用的是异步回调确认机制，利用Callback接口，在消息发送成功或失败时执行相应的回调逻辑。

typescript 复制代码

ProducerRecord<String, String> record = new ProducerRecord<>("my_topic", "key", "value");
producer.send(record, new Callback() {
    @Override
    public void onCompletion(RecordMetadata metadata, Exception exception) {
        if (exception != null) {
            // 消息发送失败，进行重试或记录日志
            log.error("Failed to send message: {}", exception.getMessage());
        } else {
            // 消息发送成功
            log.info("Message sent successfully, offset: {}", metadata.offset());
        }
    }
});

同时，为了避免因网络瞬时故障导致消息发送失败，可以设置合理的重试机制。但要注意重试次数和重试间隔，防止无限重试耗尽系统资源。

（二）消息存储阶段

消息队列本身的高可用性是防止消息丢失的关键。以 RabbitMQ 为例，我们可以通过镜像队列 机制，将队列镜像分布到多个节点上，即使某个节点宕机，消息依然可以从其他节点获取。在 Kafka 中，则可以通过副本机制，为每个分区设置多个副本，其中一个为 Leader 副本，其他为 Follower 副本，Follower 副本会定期从 Leader 副本同步消息。通过设置min.insync.replicas参数（最小同步副本数）和acks参数（生产者要求的确认级别），可以确保消息至少被写入到指定数量的副本中，只有当 Leader 和足够数量的 Follower 都确认收到消息后，才认为消息写入成功。

ini 复制代码

# 在Kafka的server.properties中配置
min.insync.replicas=2

java 复制代码

// 在Kafka生产者配置中设置acks
Properties props = new Properties();
props.put("acks", "all");

（三）消息消费阶段

在消费端，我们要避免在消息处理完成前就提交消费确认。以 Kafka 为例，默认是自动提交偏移量，这可能导致消息还未处理完就提交了偏移量，重启后消息丢失。所以建议使用手动提交偏移量，在消息处理完成后，再调用commitSync()或commitAsync()方法提交。对于 RabbitMQ，消费者可以通过设置autoAck=false，在业务逻辑处理成功后，手动调用basicAck方法确认消息已被成功消费，若处理失败，则调用basicNack或basicReject方法进行拒绝或否定确认，让消息重新回到队列等待消费。

less 复制代码

// Kafka手动提交偏移量示例
ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
for (ConsumerRecord<String, String> record : records) {
    try {
        // 处理消息
        processMessage(record.value());
        // 手动提交偏移量
        consumer.commitSync(Collections.singletonMap(
                new TopicPartition(record.topic(), record.partition()),
                new OffsetAndMetadata(record.offset() + 1)
        ));
    } catch (Exception e) {
        // 处理失败，可选择重试或记录日志
        log.error("Failed to process message: {}", e.getMessage());
    }
}

二、消息不重复的保障策略

（一）生产者去重

在消息生产端，可以为每条消息生成一个唯一的消息 ID，常见的做法是使用 UUID 或者基于时间戳和随机数生成唯一标识。在发送消息前，将消息 ID 存储到缓存（如 Redis）中，每次发送新消息时，先检查缓存中是否存在该 ID，如果存在则说明消息已经发送过，不再重复发送。

ini 复制代码

String messageId = UUID.randomUUID().toString();
Boolean isExist = redisTemplate.opsForValue().setIfAbsent("message:" + messageId, "1", 10, TimeUnit.MINUTES);
if (isExist) {
    // 消息不存在，进行发送
    sendMessage(message);
} else {
    // 消息已存在，不重复发送
    log.info("Message {} has been sent, skip sending.", messageId);
}

（二）消费端去重

在消费端，同样利用消息 ID 进行去重。当消费者接收到消息后，先从消息中提取消息 ID，检查本地缓存（如 Guava Cache）或 Redis 中是否已存在该 ID。如果存在，说明消息已经消费过，直接跳过；如果不存在，则处理消息，并将消息 ID 存入缓存，设置合理的过期时间，避免缓存占用过多资源。

typescript 复制代码

// 使用Guava Cache进行消费端去重示例
LoadingCache<String, Boolean> cache = CacheBuilder.newBuilder()
       .expireAfterWrite(5, TimeUnit.MINUTES)
       .build(new CacheLoader<String, Boolean>() {
            @Override
            public Boolean load(String key) {
                return false;
            }
        });
String messageId = message.get("messageId");
try {
    if (cache.get(messageId)) {
        // 消息已消费，跳过
        log.info("Message {} has been consumed, skip processing.", messageId);
        return;
    }
    // 处理消息
    processMessage(message);
    // 标记消息已消费
    cache.put(messageId, true);
} catch (ExecutionException e) {
    log.error("Failed to check cache: {}", e.getMessage());
}

（三）幂等性设计

除了基于消息 ID 去重，更彻底的解决方案是将业务接口设计成幂等性 的。也就是说，对同一操作的多次请求应该产生相同的效果，不会因为重复调用而导致数据不一致或其他副作用。例如，在订单支付场景中，当支付接口接收到重复的支付请求时，通过查询订单状态判断是否已经支付，如果已支付则直接返回支付成功结果，而不再重复执行支付逻辑。在数据库操作层面，可以利用唯一索引来保证相同数据不会被重复插入，如订单表中以订单号作为唯一索引，当重复的订单创建请求到来时，数据库会因为唯一索引冲突而拒绝插入，从而保证数据的一致性。

三、总结与实践建议

保证消息队列中的消息不丢失、不重复，需要从消息的生产、存储、消费全流程进行把控。在实际项目中，要根据业务场景和消息队列的特点，灵活组合使用上述策略。例如，对于金融类对数据准确性要求极高的业务，要严格落实消息生产确认、多副本存储以及消费端的强幂等性设计；而对于一些对实时性要求较高，但对数据准确性容忍度稍高的业务，可以适当放宽部分策略，在性能和可靠性之间找到平衡。

同时，监控和日志记录也至关重要。通过对消息队列的发送、存储、消费状态进行实时监控，及时发现异常情况；详细记录消息处理的各个环节日志，以便在出现问题时能够快速定位和排查。希望这些经验分享能帮助大家在 Java 后端开发中更好地驾驭消息队列，打造出更可靠、更健壮的分布式系统。

上述内容涵盖了消息队列可靠性的关键策略。若你对其中某部分实现细节、特定消息队列的应用还有疑问，欢迎随时和我说说。