消息队列中的可靠性主要是分为三部分：
- 消息不丢失：确保消息从生产者发送到消费者消息不丢失
- 消息不重复：确保消息不被重复消费
- 消息顺序性：确保消费的顺序性
解决方案主要有以下几部分：
- 一、消息不丢失
-
- 生产者确认机制
- 持久化机制
- 消费者确认机制
- 高可用
- 二、消息不重复：
-
- 消费者确认机制
- 消息重试机制
- 幂等性设计
- 三、消息顺序性
-
- 单消费者模式
- 消息编号
生产者确认机制
作用
确保生产者发送的消息成功到达mq，避免消息在传输过程中丢失
实现原理
- 生产者会发送消息之后，mq会向生产者返回确认（ack）或未确认（nack）信号
- 如果生产者收到ack，说明消息已经成功发送
配置方式
-
开启生产者确认模式
Channel channel = connection.createChannel();
channel.confirmSelect(); // 开启确认模式 -
处理确认和未确认
channel.addConfirmListener((sequenceNumber, multiple) -> {
// 消息确认
System.out.println("Message confirmed: " + sequenceNumber);
}, (sequenceNumber, multiple) -> {
// 消息未确认
System.out.println("Message not confirmed: " + sequenceNumber);
});
适用场景
对消息可靠性要求高的场景，如金融交易、订单处理等
持久化机制
作用
将消息和队列持久化到磁盘，防止mq重启或者崩溃时消息丢失
实现原理
- 队列持久化：将队列中的数据保存在磁盘
- 消息持久化：将消息内容保存到磁盘
配置方式
-
队列持久化
boolean durable = true;
channel.queueDeclare("my_queue", durable, false, false, null); -
消息持久化
AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder()
.deliveryMode(2) // 2 表示持久化消息
.build();
channel.basicPublish("", "my_queue", properties, message.getBytes());
适用场景
需要保证消息不丢失的场景，如日志存储、重要数据同步
消费者确认机制
作用
确保消费者成功处理消息之后，mq才会将消息从消息队列中删除，避免消息丢失
实现原理
- 消费者处理完成消息后，手动发送ack信号
- 如果消费者未发送ack，mq会将消息重新投递给其他消费者
配置方式
-
开启消费者确认
boolean autoAck = false; // 关闭自动确认
channel.basicConsume("my_queue", autoAck, new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
// 处理消息
System.out.println("Received: " + new String(body));// 手动发送 ack channel.basicAck(envelope.getDeliveryTag(), false); }});
适用场景
需要确保消息成功处理的场景，如订单处理、消息通知等
死信队列
作用
处理无法正常消费的消息（被拒绝或者过期），避免消息丢失
实现原理
- 当消息无法被正常消费时，mq将其转发到死信队列中
- 死信队列可以配置独立的交换机和路由规则
配置方式
-
配置死信队列
Map<String, Object> args = new HashMap<>();
args.put("x-dead-letter-exchange", "my_dlx_exchange"); // 设置死信交换机
args.put("x-dead-letter-routing-key", "my_dlx_routing_key"); // 设置死信路由键
channel.queueDeclare("my_queue", true, false, false, args);
适用场景
需要处理异常消息的场景，如消息重试，失败信息分析等
消息重试机制
作用
当消息处理失败的时候，通过重试机制重新投递消息，确保消息最终被成功处理
实现原理
- 消费者捕获异常，并拒绝消息，同时设置requeue=true
- 使用死信队列和TTL实现延迟重试
配置方式
-
拒绝消息，重新入队
channel.basicConsume("my_queue", false, new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties, byte[] body) throws IOException {
try {
// 处理消息
System.out.println("Received: " + new String(body));
channel.basicAck(envelope.getDeliveryTag(), false);
} catch (Exception e) {
// 处理失败，拒绝消息并重新入队
channel.basicNack(envelope.getDeliveryTag(), false, true);
}
}
});
适用场景
需要重试机制的场景，如网络抖动、依赖服务不可用等
高可用性
作用
通过集群和经销队里额，确保mq在节点出现故障仍然可以要运行，避免消息丢失。
镜像队列结构是一主多从，所有操作都是主节点完成，然后同步给镜像节 点，如果主节点宕机后，镜像节点会替代成新的主节点
实现原理
- 集群：多个mq节点组成的集群，共享数据和队列状态
- 镜像队列：将队列镜像到多个节点，确保队列的高可用性
配置方式
-
集群配置
rabbitmqctl join_cluster rabbit@node1
-
镜像队列配置
Map<String, Object> args = new HashMap<>();
args.put("x-ha-policy", "all"); // 镜像到所有节点
channel.queueDeclare("my_queue", true, false, false, args);
适用场景
适用于高可用的场景，如分布式系统、关键业务等
高可用性数据丢失怎么解决
在镜像队列主从同步的过程中，会出现在主从同步完成前，主节点就已经宕机，可能出现数据丢失。
我们可以通过仲裁队列来进行解决，和镜像队列一样，都是主从模式，支持主从数据同步但是不一样的点就是主从同步基于Raft协议，强一致性
并且使用起来也非常简单，不需要额外的配置，在声明队列的时候只要指定 这个是仲裁队列即可