rabbitmq的消息确认和消息回退

最新推荐文章于 2024-04-30 16:09:10 发布
最新推荐文章于 2024-04-30 16:09:10 发布
阅读量1.3k 收藏 1
点赞数
分类专栏： springboot Spring Cloud rabbitmq 文章标签： java-rabbitmq rabbitmq java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_30690165/article/details/131063345
版权

theme: vue-pro

前言

前面章节我们至少知道了rabbitmq的几个核心组件, 比如 exchange queue 和 routing key

还有java编程方面的 channel 和 connection

但是这些还不够运用于生产环境

本章内容

  1. 消息确认机制(message confirm)
  2. 消息return机制

消息确认机制(confirm)

开始confirm机制, 生产者消息投递到exchange, exchange就会立即ack给生产者, 如果无法投递到exchange, 那么生产者就是产生nack

image.png

事务机制和 publisher confirm 机制确保的是消息能够正确地发送至 RabbitMQ，这里的“发送至 RabbitMQ”的含义是指消息被正确地发往至 RabbitMQ 的交换器，如果此交换器没有匹配的队列，那么消息也会丢失。

问: 事务机制为什么不讲?

答: 事务机制效率比较慢, P发送消息需要等待C的响应, 会导致极大的耗费性能

问: return机制或者confirm机制收到消息不成功后, 你要怎么处理呢?

答: 一般处理方式是: 重试几次, 如果还不通过, 那么打印日志, 交给人工处理

这里的重试可以考虑使用指数退避(重试频率从快到慢的过程)

异步方式消息确认

详细过程是在发送消息前保存消息到一个队列中, 在拿到遇到消息发送失败后, 我们拿取到队列中的消息, 然后尝试重试补偿

image.png

注意 Confirm 机制需要主动开启, 上图缺少了这段代码: channel.confirmSelect();

问: 这里引入redis保存这消息不合适吧?

答: 看起来这里还可以将消息保存到一个高并发队列中, 开一个定时器定时解决(立马再次发送消息大概率还是会失败, 每次等他个几百毫秒吧), 失败累计次数, 直到超过域值email通知运营人员

但是使用高并发队列只不过在内存中, 进程崩溃后改消息队列中的消息也将丢失

问: 那有别的方式吗?

答: 有, 保存到mysql或者直接持久化到queue中, 等到管理员找到原因并恢复后再次发送

同步消息确认

channel.queueDeclare(QUEUE_NAME, true, false, true, null);
channel.confirmSelect();
stopWatch.start();
for (int i = 0; i < 1000; i++) {
   channel.basicPublish("", QUEUE_NAME, MessageProperties.PERSISTENT_TEXT_PLAIN,
         String.format("hello%d", i).getBytes(StandardCharsets.UTF_8));
   // 单个消息确认机制
   boolean flag = channel.waitForConfirms();
   if (flag) {
      System.err.println("消息发送成功");
   }
}

但是1000次循环就需要调用 1000次 waitForConfirms 这效率特别低

channel.queueDeclare(QUEUE_NAME, true, false, true, null);
channel.confirmSelect();
int batchSize = 100;
int outstandingMessageCount = 0;
stopWatch.start();
for (int i = 0; i < 1000; i++) {
   channel.basicPublish("", QUEUE_NAME, MessageProperties.PERSISTENT_TEXT_PLAIN,
         String.format("hello%d", i).getBytes(StandardCharsets.UTF_8));
   outstandingMessageCount++;
   if (batchSize == outstandingMessageCount) {
      // 这是批量消息处理
      channel.waitForConfirms();
      outstandingMessageCount = 0;
   }
}

这里就改成100次消息发送, 处理一次同步操作消息等待

消息return机制

当前的消息通过exchange投递到queue不成功, 就会触发return机制的函数

image.png

mandatory参数的作用是什么?

mandatory参数的作用.png

文字描述: 在仅开启了生产者确认机制的情况下，交换机接收到消息后，会直接给消息生产者发送确认消息，如果发现该消息不可路由，那么消息会被直接丢弃，此时生产者是不知道消息被丢弃这个事件的。那么如何让无法被路由的消息帮我想办法处理一下？最起码通知我一声，我好自己处理啊。通过设置 mandatory 参数可以在当消息传递过程中不可达目的地时将消息返回给生产者。

immediate参数的作用(已弃用)

image.png

RabbitMQ 3.0版本开始去掉了对immediate参数的支持，原因是因为immediate参数会影响镜像队列的性能、增加了代码的复杂度，建议采用TTL和DLX的方法替代。

消息回退机制代码实现

Producer的思路非常简单, 设置mandatory = true, 然后channel.addReturnListener

public static final String EXCHANGE = "exchange";
   public static final String ROUTING_KEY = "";
   
   public static void main(String[] args) throws Exception {
      ConnectionFactory factory = RabbitUtils.INSTANCE.connectionFactory();
      Connection connection = factory.newConnection();
      Channel channel = connection.createChannel();
      
      channel.exchangeDeclare(EXCHANGE, BuiltinExchangeType.DIRECT, true,
            true, null);
      
      ConcurrentSkipListMap<Long, String> map = new ConcurrentSkipListMap<>();
      
      channel.confirmSelect();
      channel.addConfirmListener(new ConfirmListener() {
         @Override
         public void handleAck(long deliveryTag, boolean multiple) throws IOException {
            System.err.println("消息发送成功...");
            if (multiple) {
               ConcurrentNavigableMap<Long, String> headMap = map.headMap(deliveryTag);
               headMap.clear();
            } else {
               map.remove(deliveryTag);
            }
         }
         
         @Override
         public void handleNack(long deliveryTag, boolean multiple) throws IOException {
            System.err.println("消息发送失败");
            // 意味着这里存在多个消息被否定, 可以使用 head 拿到小于 deliveryTag 的消息, 全部进行重试
            if (multiple) {
               ConcurrentNavigableMap<Long, String> messageHeadMap = map.headMap(deliveryTag);
               // 这里可以将消息保存到数据库或者redis中
               messageHeadMap.forEach((id, s) -> {
                  System.err.println("id: " + id + " message: " + s);
               });
               messageHeadMap.clear();
            } else {
               String messageNode = map.remove(deliveryTag);
               // 这里可以将消息保存到数据库或者redis中
               System.err.println("message: " + messageNode);
            }
         }
      });
      
      channel.addReturnListener(returnMessage -> {
         System.err.println("消息被return回来了...");
         int replyCode = returnMessage.getReplyCode();
         String replyText = returnMessage.getReplyText();
         String exchange = returnMessage.getExchange();
         String routingKey = returnMessage.getRoutingKey();
//       AMQP.BasicProperties properties = returnMessage.getProperties();
         String message = new String(returnMessage.getBody(), Charset.defaultCharset());
         System.err.println("message: " + message);
         System.err.println("exchange: " + exchange);
         System.err.println("routingKey: " + routingKey);
         System.err.println("replyText: " + replyText);
         System.err.println("replyCode: " + replyCode);
      });
      
      String message = "message";
      map.put(channel.getNextPublishSeqNo(), message);
      channel.basicPublish(EXCHANGE, ROUTING_KEY, true, false, MessageProperties.PERSISTENT_TEXT_PLAIN,
            message.getBytes(Charset.defaultCharset()));
   }

image.png

Consumer:

public static final String QUEUE = "queue";
public static final String EXCHANGE = "exchange";

public static void main(String[] args) throws Exception {
   ConnectionFactory factory = RabbitUtils.INSTANCE.connectionFactory();
   Connection connection = factory.newConnection();
   Channel channel = connection.createChannel();
   
   channel.exchangeDeclare(EXCHANGE, BuiltinExchangeType.DIRECT, true, true, null);
   channel.queueDeclare(QUEUE, true, false, true, null);
   channel.queueBind(QUEUE, EXCHANGE, "");
   
   channel.basicConsume(QUEUE, false, (consumerTag, message) -> {
      System.err.println("消息消费成功, consumeTag: " + consumerTag + "  message: "
            + new String(message.getBody(), Charset.defaultCharset()));
      channel.basicAck(message.getEnvelope().getDeliveryTag(), false);
   }, consumerTag -> System.err.println("消息接受失败, consumeTag: " + consumerTag));
   
}

问题思考

有了 mandatory 参数和回退消息，我们获得了对无法投递消息的感知能力，有机会在生产者的消息无法被投递时发现并处理。

但有时候，我们并不知道该如何处理这些无法路由的消息，最多打个日志，然后触发报警，再来手动处理。而通过日志来处理这些无法路由的消息是很不优雅的做法，特别是当生产者所在的服务有多台机器的时候，手动复制日志会更加麻烦而且容易出错。

而且设置 mandatory 参数会增加生产者的复杂性，需要添加处理这些被退回的消息的逻辑。如果既不想丢失消息，又不想增加生产者的复杂性，该怎么做呢？

另一个return机制: exchange备机

来总结下前面的问题

  1. 消息回退增加消费者代码复杂度
  2. 回退回来的消息要怎么处理? 记录日志也不知道怎么处理? 难道要手动处理?

在 RabbitMQ 中，有一种备份交换机的机制存在，可以很好的应对这个问题。什么是备份交换机呢？

备份交换机可以理解为 RabbitMQ 中交换机的“备胎”，当我们为某一个交换机声明一个对应的备份交换机时， 就是为它创建一个备胎，**当交换机接收到一条不可路由消息时，将会把这条消息转发到备份交换机中，由备份交换机来进行转发和处理，通常备份交换机的类型为 Fanout ，这样就能把所有消息都投递到与其绑定的队列中，然后我们在备份交换机下绑定一个队列，这样所有那些原交换机无法被路由的消息，就会都进入这个队列了。**当然，我们还可以建立一个报警队列，用独立的消费者来进行监测和报警。

image.png

备机架构设计

image.png

备机和return机制同时存在默认走哪个机制?

备份exchange模式优先级高于消息return模式

什么情况的消息会进入备机?

消息无法投递到queue的原因, 我想想都有哪些?

  1. queue不存在
  2. queue满了
  3. 根据 routing key 找不到 queue (和第一种很像)

消息进入备机后, 我们该做什么?

答:

  1. 保存消息
  2. 报警告, 推消息告知管理员
  3. 最后在解决问题后将消息转发给正常的exchange

有哪些方法保存消息?

答:

  1. 可以保存到数据库, 但有IO上限, 不是很好的选择.
  2. 将消息持久化到queue中, 但是不创建自动消费的消费者, 我们可以在问题被发现并解决后再手动启动处理备份消息
  3. 保存到redis中, 方案不错, 但是在整个分布式系统中引入了新的变量, 导致项目不太问题

最终我还是选择了redis, 因为业务需求, 我们需要对备份的消息进行发送和查询甚至是删除操作, 持久化到queue不好操作, 当然如果你持久化到queue那么你需要保证消息

另一个原因是redis是分布式系统不可或缺的一个组件, 早晚都会用上的

我们虽然选择了redis方案, 但不意味着第二个方案(持久化到queue)不好, 我本人更加推荐使用方案二, 但是第二种方案我们需要及时处理问题, 否则可能导致消息爆满, 当然redis方案也是

发送消息的目的地是哪里?

正常是 exchange

那么怎么发送消息?

首先我们需要对消息进行包装, 不仅仅有内容还需要有发送地址

大致结构是这样:

消息id, 消息内容, 消息创建时间, 消息优先级
  • 消息id方式消息重复消费
  • 消息创建时间检查消息超过一定域值, 还没被消费, 后续可以做严重警告
  • 消息优先级: 可以当做消息重要性, 数字越大优先级越高
public class ConfirmConsumer {
   public static final String BACKUP_EXCHANGE = "backup.exchange";
   public static final String CONFIRM_EXCHANGE = "confirm.exchange";
   public static final String CONFIRM_QUEUE = "confirm.queue";
   
   public static void main(String[] args) throws Exception {
      ConnectionFactory factory = RabbitUtils.INSTANCE.connectionFactory();
      Connection connection = factory.newConnection();
      Channel channel = connection.createChannel();
      
      HashMap<String, Object> arguments = new HashMap<>();
      // 将exchange无法发送的消息, 转发给备份exchange
      arguments.put("alternate-exchange", BACKUP_EXCHANGE);
      channel.exchangeDeclare(CONFIRM_EXCHANGE, BuiltinExchangeType.DIRECT, true, true, arguments);
      channel.queueDeclare(CONFIRM_QUEUE, true, false, true, null);
      channel.queueBind(CONFIRM_QUEUE, CONFIRM_EXCHANGE, "");
      
      DeliverCallback deliverCallback = (consumerTag, message) -> {
         System.err.println("消息接收时间: "
               + DatePattern.NORM_DATETIME_FORMAT.format(new Date())
               + " consumerTag: " + consumerTag + " message: " + message);
         channel.basicAck(message.getEnvelope().getDeliveryTag(), false);
      };
      CancelCallback cancelCallback = System.err::println;
      channel.basicConsume(CONFIRM_QUEUE, false, deliverCallback, cancelCallback);
   }
}

注意上面这段代码:

HashMap<String, Object> arguments = new HashMap<>();
// 将exchange无法发送的消息, 转发给备份exchange
arguments.put("alternate-exchange", BACKUP_EXCHANGE);
channel.exchangeDeclare(CONFIRM_EXCHANGE, BuiltinExchangeType.DIRECT, true, true, arguments);

image.png

在正常的exchange上绑定备份exchange

public class BackupConsumer {
   public static final String BACKUP_EXCHANGE = "backup.exchange";
   public static final String BACKUP_QUEUE = "backup.queue";
   public static final String CONFIRM_EXCHANGE = "confirm.exchange";
   
   public static void main(String[] args) throws Exception {
      Scanner scanner = new Scanner(System.in);
      ConnectionFactory factory = RabbitUtils.INSTANCE.connectionFactory();
      Connection connection = factory.newConnection();
      Channel channel = connection.createChannel();
      
      channel.exchangeDeclare(BACKUP_EXCHANGE, BuiltinExchangeType.FANOUT, true, true, null);
      channel.queueDeclare(BACKUP_QUEUE, true, false, true, null);
      channel.queueBind(BACKUP_QUEUE, BACKUP_EXCHANGE, "");
      
      DeliverCallback deliverCallback = (consumerTag, message) -> {
         System.err.println("消息保存, 然后问题发现, 解决问题, 最后发送消息...");
         scanner.next();
         System.err.println("发送消息: " + ", messageId: " + message.getProperties().getMessageId()
               + ", 消息内容: " + new String(message.getBody(), Charset.defaultCharset()));
         channel.basicPublish(CONFIRM_EXCHANGE, "", message.getProperties(), message.getBody());
         channel.basicAck(message.getEnvelope().getDeliveryTag(), false);
      };
      CancelCallback cancelCallback = System.err::println;
      channel.basicConsume(BACKUP_QUEUE, false, deliverCallback, cancelCallback);
   }
}

public class WarningConsumer {
   public static final String BACKUP_EXCHANGE = "backup.exchange";
   public static final String WARNING_QUEUE = "warning.queue";
   
   public static void main(String[] args) throws Exception {
      ConnectionFactory factory = RabbitUtils.INSTANCE.connectionFactory();
      Connection connection = factory.newConnection();
      Channel channel = connection.createChannel();
      
      channel.exchangeDeclare(BACKUP_EXCHANGE, BuiltinExchangeType.FANOUT, true, true, null);
      channel.queueDeclare(WARNING_QUEUE, true, false, true, null);
      channel.queueBind(WARNING_QUEUE, BACKUP_EXCHANGE, "");
      
      DeliverCallback deliverCallback = (consumerTag, message) -> {
         AMQP.BasicProperties properties = message.getProperties();
         Integer priority = properties.getPriority();
         String messageId = properties.getMessageId();
         Date timestamp = properties.getTimestamp();
         
         System.err.println("日志警告, 消息等级: " + priority + ", 消息id: " + messageId
               + ", 消息创建时间: " + DatePattern.NORM_DATETIME_FORMAT.format(timestamp) + ", 消息内容: "
               + new String(message.getBody(), Charset.defaultCharset()));
         channel.basicAck(message.getEnvelope().getDeliveryTag(), false);
      };
      CancelCallback cancelCallback = System.err::println;
      channel.basicConsume(WARNING_QUEUE, false, deliverCallback, cancelCallback);
   }
}

public class Producer {
   
   public static final String BACKUP_EXCHANGE = "backup.exchange";
   public static final String CONFIRM_EXCHANGE = "confirm.exchange";
   
   public static void main(String[] args) throws Exception {
      ConnectionFactory factory = RabbitUtils.INSTANCE.connectionFactory();
      Connection connection = factory.newConnection();
      Channel channel = connection.createChannel();
      
      HashMap<String, Object> arguments = new HashMap<>();
      // 将exchange无法发送的消息, 转发给备份exchange
      arguments.put("alternate-exchange", BACKUP_EXCHANGE);
      channel.exchangeDeclare(CONFIRM_EXCHANGE, BuiltinExchangeType.DIRECT, true, true, arguments);
      
      channel.confirmSelect();
      channel.addConfirmListener((deliveryTag, multiple) -> {
         String dateTime = DatePattern.NORM_DATETIME_FORMAT.format(new Date());
         System.err.println(deliveryTag + ": 消息应答" + " '发送'时间为: " + dateTime);
      }, (deliveryTag, multiple) -> System.err.println(deliveryTag + ": 消息未得到应答"));
      
      // 消费者提供消息超时功能
      AMQP.BasicProperties.Builder builder = new AMQP.BasicProperties.Builder();
      builder.contentType("text/plain");
      builder.deliveryMode(2);
      builder.priority(0);
      for (int i = 0; i < 10; i++) {
         builder.timestamp(new Date());
         builder.messageId(UUID.fastUUID().toString(true));
         String message = "content: " + UUID.fastUUID().toString(false) + i;
         channel.basicPublish(CONFIRM_EXCHANGE, "",
               builder.build(), message.getBytes(Charset.defaultCharset()));
      }
   }
}

记住, 这里我们的备份消费者并没有做真实的操作, 而是使用

System.err.println("消息保存, 然后问题发现, 解决问题, 最后发送消息...");
scanner.next();
channel.basicPublish(CONFIRM_EXCHANGE, "", message.getProperties(), message.getBody());

模拟了管理员找问题, 解决问题最后将消息转发给正常的exchange的过程

渣渣→_→
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
RabbitMQ消息服务器-其他
06-11
RabbitMQ是由LShift提供的一个Advanced Message Queuing Protocol (AMQP) 的开源实现，由以高性能、健壮以及可伸缩性出名的Erlang写成，因此也是继承了这些优点。 AMQP里主要要说两个组件：Exchange和Queue（在AMQP 1.0里还会有变动），如下图所示，绿色的X就是Exchange，红色的是Queue，这两者都在Server端，又称作Broker，这部分是RabbitMQ实现的，而蓝色的则是客户端，通常有Producer和Consumer两种类型。
rabbitMq消息接收与消费
10-31
SpringBoot整合RabbitMq，简单的实现消息的生产与消费，可发送消息到rabbitMq,可实时接收消息。适合初学者。
5. RabbitMQ 简单工作模型及消息确认回调
weixin_52359996的博客
03-27 579
RabbitMQ 简单工作模型及消息确认回调 交换机消息确认，队列消息确认回调
RabbitMq 消息确认机制详解
weixin_52278591的博客
02-01 4299
消息从发送，到消费者接收，会经理多个过程,其中的每一步都可能导致消息丢失，常见的丢失原因包括： 生产者发送的消未送达exchange 消息到达exchange后未到达queue 针对这些问题，RabbitMQ分别给出了解决方案： 生产者确认机制 mq持久化消费者确认机制 失败重试机制 ​
SpringBoot 整合 RabbitMQ 实现消息回调、手动确认 （二） 有图 有源码
Xiang想
09-02 1445
RabbitMQ 生产者消息回调确保消息正确送达，消费者手动确认，确保消息成功被消费。有图有源码
RabbitMQ学习笔记：addReturnListener监听回退消息
OceanSky的专栏
10-26 2436
发布消息示例 channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, true, false, properties.build(), message.getBytes()); 参数： mandatory:如果为true, 消息不能路由到指定的队列时，则会调用basic.return方法将消息返回给生产者,会触发addReturnListener注册的...
RabbitMQ 发布确认+消息回退
XZB119211的博客
09-23 3048
RabbitMQ 发布确认+消息回退+备份交换机
RabbitMq——发布确认高级和消息回退
weixin_50616848的博客
03-19 3677
发布确认高级：消息在传递过程中，我们需要确定消息状态信息，开启发布确认高级模式，消息传递结束后会返回传递结果信息，若发送失败的消息，该消息会被存入缓存中，定时任务发送失败消息，交换机收到消息后，缓存会删除该信息。 如果只开启发布确认模式的话，当交换机收到生产者发送的消息后，会发布确认消息给生产者，如果发现路由不通，则会直接丢弃消息，此时生产者处于不知情状态，就会造成消息丢失。 消息回退：通过设置 mandatory 参数可以在当消息传递过程中不可达目的地时将消息返回给生产者，好让生产者做后续 。 案例
RabbitMQ消息回调，发布订阅模式与集群配置
chaojiyingxiong的博客
01-13 2185
在生产环境中由于一些不明原因，导致rabbitmq重启，在RabbitMQ重启期间生产者消息投递失败，导致消息丢失，需要手动处理和恢复。于是，我们开始思考，如何才能进行RabbitMQ的消息可靠投递呢？特别是在这样比较极端的情况，RabbitMQ集群不可用的时候，无法投递的消息该如何处理呢: 确保生产者与交换机的消息不丢失 在配置文件当中需要添加 spring.rabbitmq.publisher-confirm-type= NONE 禁用发布确认模式，是默认值 CORRE...
RabbitMQ系列（7）--RabbitMQ消息应答及消息未应答后重新入队
m0_64284147的博客
07-05 2067
RabbitMQ一旦向消费者传递一条消息，该消息就会被标记为删除，这种情况下消费者挂掉了正在处理的消息就会丢失，为了保证消息在发送的过程中不会丢失，RabbitMQ引入了应答机制，(1)true表示批量应答channel上未应答的消息，比如channel上有传送tag为5，6，7，8的消息，当前tag是8，那么此时5-8还未应答的消息就会被确认收到消息应答，但如果处理6或7消息失败了，5也会被应答，导致5消息丢失，所以一般情况下multiple为false。
rabbitmq消息可靠性之消息回调机制
qq_41992429的博客
01-12 2188
rabbitmq消息可靠性之消息回调机制
RabbitMQ消息模式之Confirm确认消息
01-07
理解Confirm消息确认机制 消息的确认，是指生产者投递消息后，如果Broker收到消息，则会给我们生产者一个应答。生产者进行接收应答，用来确定这条消息是否正常的发送到Broker，这种方式也是消息的可靠性投递的核心保障 消费端代码： package com.ue.confirm; import com.rabbitmq.client.Channel; import com.rabbitmq.client.Connection; import com.rabbitmq.client.ConnectionFactory; import com.rabbitmq.client.Queuein
JAVA获取rabbitmq消息总数过程详解
08-25
主要介绍了JAVA获取rabbitmq消息总数过程详解，公司使用的是rabbitMQ，需要做监控预警的job去监控rabbitMQ里面的堆积消息个数，如何使用rabbitMQ获取监控的队列里面的队列消息个数呢,需要的朋友可以参考下
C# .Net RabbitMQ消息队列发送和接收实例程序
04-21
用.Net 6.0 RabbitMQ.Client.Dll开源库写RabbitMQ的发送和接收程序，亲测可用。 包含了接收端监听程序，和发送端发送程序。
RabbitMQ消息中间件技术精讲.txt
01-21
RabbitMQ消息中间件技术精讲
谷粒商城实战(020 RabbitMQ-消息确认)
wang_book的博客
04-30 278
总时长 104:45:00 共408P此文章包含第258p-第p261的内容。
RabbitMq基础概念知识复习
m0_72363694的博客
04-27 307
消息拥有消息头和消息体，消息具有rounting key，主题交换机和扇形交换机都是分布与订阅的实现方式，主题交换机用于匹配接收的消息的rount key 动态匹配模式匹配到多个符合的队列，扇形fanout交换机则不会使用消息的路由key，即便在绑定队列的时候指定了Routing key，也不会有任何效果，它会向所有绑定到当前交换机的 队列广播消息，该交换机绑定队列的时候所有的rounting key为空，这样所有被绑定的队列都能收到交换机的消息，实现广播功能。4 rabbitMq应用场景，异步！
【消息队列】RabbitMQ五种消息模式
最新发布
weixin_62513677的博客
04-30 1083
Spring AMQP是基于AMQP协议定义的一套API规范，提供了模板来发送和接收消息，包含两部分，其中Spring-amqp是基础抽象，spring-rabbit是底层的默认实现。这是为了防止消息队列中的队列不存在，在进行消息队列初始化的时候不知道是先建立消费者，还是先建立生产者，所以都执行创建函数，但是创建的队列只有一个不会重复。发布者发送消息时，指定消息的RoutingKey，Exchange将消息路由到BindingKey与消息RoutingKey一致的队列。Work queue，工作队列。
RabbitMQ-死信队列
m0_74356429的博客
04-27 356
1、什么是死信在 RabbitMQ 中充当主角的就是消息，在不同场景下，消息会有不同地表现。死信就是消息在特定场景下的一种表现形式，这些场景包括：1. 消息被拒绝访问，即 RabbitMQ返回 basicNack 的信号时 或者拒绝basicRejectbasicNack3. 消息的过期时长或。4. 消息队列达到最大容量上述场景经常产生死信，即消息在这些场景中时，被称为死信。2、什么是死信队列死信队列就是用于储存死信的消息队列，在死信队列中，有且只有死信构成，不会存在其余类型的消息。
rabbitmq消息确认
09-07
RabbitMQ消息确认是为了解决消息丢失的问题。即使我们使用了RabbitMQ的持久化功能，仍然无法完全保证消息不会丢失。消息确认分为两种类型：消息发送确认和消费接收确认。[2] 消息发送确认用于确认生产者将消息发送...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值