rabbitmq消息确认机制通过生产者确认和消费者确认确保消息可靠传输。1. 生产者确认（publisher confirms）：开启confirm模式后，可通过异步监听或同步等待确认消息是否到达服务器，支持批量确认和单条确认；2. 消费者确认（consumer acknowledgements）：需设置为手动确认模式，在消息成功处理后调用basicack确认，若处理失败则调用basicnack或basicreject拒绝消息并决定是否重新入队；3. 死信队列（dlx）配置：当消息被拒绝且requeue=false、过期或队列满时，消息会被发送到指定的dlx，并绑定dlq进行后续处理；4. 消息丢失排查：生产者端启用确认机制，rabbitmq端开启持久化，消费者端使用手动确认和异常捕获；5. 顺序性保证：通过单一队列单一消费者、消息分片或sequence number排序实现；6. 不同场景选择机制：高可靠性需启用全部确认并配置dlx，性能优先使用批量确认，简单场景可用自动确认。
RabbitMQ消息确认机制，简单来说，就是确保消息从生产者可靠地发送到消费者，并且被成功处理。核心在于，如果消息在传输过程中丢失，或者消费者处理失败，系统能够检测到并采取措施，比如重新发送消息。
解决方案
RabbitMQ提供了两种主要的消息确认机制：
- 生产者确认（Publisher Confirms）： 确保消息成功到达RabbitMQ服务器。
- 消费者确认（Consumer Acknowledgements）： 确保消息被消费者成功处理。
生产者确认（Publisher Confirms）
-
开启确认模式： 在Channel上调用
channel.confirmSelect()方法，将Channel设置为confirm模式。
Channel channel = connection.createChannel(); channel.confirmSelect();
-
异步监听确认结果： RabbitMQ会异步地向生产者发送确认消息。可以通过
channel.addConfirmListener()方法添加监听器，处理确认和拒绝的消息。
channel.addConfirmListener(new ConfirmListener() {
@Override
public void handleAck(long deliveryTag, boolean multiple) throws IOException {
// 处理确认的消息
System.out.println("Message confirmed with delivery tag: " + deliveryTag + ", multiple: " + multiple);
}
@Override
public void handleNack(long deliveryTag, boolean multiple) throws IOException {
// 处理拒绝的消息
System.err.println("Message rejected with delivery tag: " + deliveryTag + ", multiple: " + multiple);
// 可以选择重新发送消息
}
});-
批量确认：
multiple参数表示是否批量确认。如果为true，表示确认所有小于等于deliveryTag的消息；如果为false，表示只确认deliveryTag对应的消息。
同步等待确认： 可以使用
channel.waitForConfirms()或channel.waitForConfirmsOrDie()方法同步等待确认结果。这种方式效率较低，不建议在高吞吐量场景中使用。
try {
channel.waitForConfirmsOrDie(5000); // 等待5秒
System.out.println("Message confirmed");
} catch (InterruptedException | TimeoutException e) {
System.err.println("Message confirmation failed: " + e.getMessage());
// 处理超时或中断的情况，例如重新发送消息
}消费者确认（Consumer Acknowledgements）
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
-
手动确认模式： 默认情况下，消费者会自动确认消息。为了确保消息被成功处理，通常需要将确认模式设置为手动。在
basicConsume()方法中，将autoAck参数设置为false。
channel.basicConsume(QUEUE_NAME, false, consumer); // autoAck = false
-
确认消息： 在消费者处理完消息后，调用
channel.basicAck()方法确认消息。
DeliverCallback deliverCallback = (consumerTag, delivery) -> {
String message = new String(delivery.getBody(), "UTF-8");
System.out.println(" [x] Received '" + message + "'");
try {
doWork(message); // 模拟消息处理
} finally {
System.out.println(" [x] Done");
channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false); // 确认消息
}
};-
拒绝消息： 如果消费者处理消息失败，可以调用
channel.basicNack()或channel.basicReject()方法拒绝消息。basicNack()可以批量拒绝消息，而basicReject()只能拒绝单条消息。
channel.basicNack(delivery.getEnvelope().getDeliveryTag(), false, true); // 拒绝消息，并重新放入队列 // 或者 channel.basicReject(delivery.getEnvelope().getDeliveryTag(), true); // 拒绝消息，并重新放入队列
-
重新入队：
basicNack()和basicReject()方法的第三个参数requeue表示是否将消息重新放入队列。如果设置为true，消息会被重新放入队列，等待下次消费；如果设置为false，消息会被丢弃或进入死信队列（Dead Letter Exchange，DLX）。
如何配置死信队列（DLX）和死信路由（DLK）？
死信队列（DLX）和死信路由（DLK）是处理无法被正常消费的消息的重要机制。当消息被拒绝（basicNack 或 basicReject 且 requeue=false），或者消息过期，或者队列达到最大长度时，消息会被发送到DLX。
- 创建DLX和DLK： 首先，需要创建一个交换机作为DLX，以及一个队列作为DLQ。
String DLX_EXCHANGE_NAME = "dlx_exchange"; String DLQ_NAME = "dlq"; channel.exchangeDeclare(DLX_EXCHANGE_NAME, "direct"); channel.queueDeclare(DLQ_NAME, false, false, false, null); channel.queueBind(DLQ_NAME, DLX_EXCHANGE_NAME, "dlx_routing_key");
-
配置队列的DLX： 在创建或声明队列时，通过
arguments参数指定DLX。
Map<String, Object> arguments = new HashMap<>();
arguments.put("x-dead-letter-exchange", DLX_EXCHANGE_NAME);
arguments.put("x-dead-letter-routing-key", "dlx_routing_key"); // 可选，默认为原routing key
channel.queueDeclare(QUEUE_NAME, false, false, false, arguments);- 处理DLQ中的消息： 创建一个消费者来监听DLQ，处理其中的消息。可以记录日志、发送告警，或者尝试重新处理消息。
消息丢失的常见原因和排查方法
消息丢失可能发生在生产者、RabbitMQ服务器和消费者三个环节。
-
生产者丢失消息：
- 原因： 生产者发送消息后，没有收到RabbitMQ的确认，就认为消息发送成功。如果网络出现问题，消息可能没有到达RabbitMQ服务器。
- 排查方法： 启用生产者确认机制，确保消息成功到达RabbitMQ服务器。检查网络连接是否稳定。
-
RabbitMQ服务器丢失消息：
- 原因： RabbitMQ服务器收到消息后，没有持久化就宕机。
-
排查方法： 启用消息持久化。将交换机和队列设置为持久化（
durable=true），并将消息的deliveryMode设置为2（持久化）。
channel.exchangeDeclare(EXCHANGE_NAME, "direct", true); // durable = true
channel.queueDeclare(QUEUE_NAME, true, false, false, null); // durable = true
AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder()
.deliveryMode(2) // 持久化消息
.build();
channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, properties, message.getBytes("UTF-8"));-
消费者丢失消息：
- 原因： 消费者收到消息后，自动确认了消息，但在处理消息的过程中发生异常导致消息丢失。
- 排查方法： 将确认模式设置为手动，确保消息被成功处理后再确认。使用try-catch块捕获异常，并在catch块中拒绝消息，将其重新放入队列或发送到DLQ。
如何保证消息的顺序性？
在某些场景下，消息的顺序性非常重要。RabbitMQ本身并不能保证所有情况下的消息顺序性，但可以通过一些策略来尽量保证。
- 单一队列，单一消费者： 这是最简单的方法。将所有需要保证顺序的消息发送到同一个队列，并使用一个消费者来消费。由于只有一个消费者，消息的处理顺序与发送顺序一致。
- 消息分片： 将消息按照一定的规则分片，保证同一分片的消息发送到同一个队列，并使用一个消费者来消费。例如，可以按照订单ID进行分片，保证同一个订单的消息发送到同一个队列。
- 使用Sequence Number： 在消息中添加一个Sequence Number，消费者在处理消息时，按照Sequence Number进行排序。如果发现消息乱序，可以先缓存消息，等待前面的消息到达后再处理。
不同场景下，应该选择哪种确认机制？
- 高可靠性场景： 同时启用生产者确认和消费者确认，并配置DLX和DLQ。
- 性能优先场景： 可以考虑使用批量确认，但需要注意消息丢失的风险。
- 简单场景： 如果对消息可靠性要求不高，可以使用自动确认模式。
选择合适的确认机制需要根据具体的业务场景和需求进行权衡。在实际应用中，可以根据消息的重要程度和系统性能要求，选择合适的确认机制。
