保暖透气大裤衩LeoLee的博客

大伙可以到我的RabbitMQ专栏获取更多信息RabbitMQ应用问题消息可靠性的保障 ​​​​​​​消息补偿机制 消息的幂等性保障 ​​​​​​​乐观锁解决方案 ​​​​​​​消息补偿机制这个图看起来好像很复杂，其实只做到了三件事情：发消息 收到消息确认 检查比对是不是收到消息了详细说明消息补偿流程发生业务操作，业务数据写入数据库 生产者将消息发送给MQ的队列Q1 发送了一条与step2中一摸一样的延迟消息到对了Q3 消费者监听Q1，获取到了step2中

什么是消息追踪在使用任何消息中间件的过程中，难免会遇到消息由于某些意外事件丢失的情况。对于RabbitMQ而言：可能是生产者、消费者于MQ的连接不稳定，网络波动甚至断连，RabbitMQ也针对生产者和消费者分别提供了对应的消息可靠性机制 也有可能是交换机于队列之间的分发策略导致的消息丢失 RabbitMQ自身的集群策略也有可能导致消息的丢失 ......此时就要采取一些较为完善的消息追踪机制，来跟踪消息从产生到被消费整个传递的链路，从而协助运维和开发人员快速定位问题。对于Rabbit

大伙可以到我的RabbitMQ专栏获取更多信息demo示例这里拿概述什么是延迟队列延迟队列，即消息到达队列后不会被立即消费，只有到达指定的时间后，才会被消费场景：下单后，30分钟为结算，自动取消该订单，被锁商品重回库存 新用户注册1小时之后，发短信问候实现方式：定时器：以某个时间间隔去轮询订单表中的下单时间并于当前时间比对，超过30分钟就取消该订单。该方式不优雅，性能消耗大，数据库压力大。 MQ延迟队列：当用户下单之后，订单生成，就发送一条消息到MQ延迟队列，该消息30分钟

大伙可以到我的RabbitMQ专栏获取更多信息demo示例这里拿概述死信队列，缩写DLX（dead letter exchange 死信交换机），当消息称为dead message之后，会被重新发送到另一个交换机，这个交换机就是DLX。当msg在Queue中过期之后，并没有直接被丢弃，而是会被当前的Queue转发给死信交换机DLX，DLX再重新发送给另外一个Queue供其他消费者消费掉为什么缩写不是DLQ或者是死信交换机呢？因为在其他MQ产品中是没有交换机这个概念的，所以在Rab

大伙可以到我的RabbitMQ专栏获取更多信息demo示例这里拿概述什么是TTLTTL全程：time to live（存活时间/过期时间） 当消息被RabbitMQ broker接收到并由exchange分配到对应的queue之后，MQ会开始根据TTL来清除消息，到达TTL时间的消息如果还没有被消费，就被清除 在RabbitMQ中可以对某条消息设置过期时间，也可以对某个队列设置过期时间场景举例常见的有：订单超时未付款自动取消 与死信队列结合用过定时任务执行器TTL的使用

大伙可以到我的RabbitMQ专栏获取更多信息demo示例这里拿概述在之前介绍的MQ的文章中——什么是MQ：消息队列的基本概念和优劣势，我提到了MQ对于处理高并发场景的能力，即削峰填谷：当请求并发增高的时候，所有业务请求首先放入MQ 业务系统则在保证系统正常平稳的情况下，尽力从MQ获取业务信息，按照自己的“节奏”处理业务 过多的业务积压在MQ中，拉长了整体业务的执行时长，这就是填谷上述过程中，第二步其实就是对消费端的限流，帮助MQ的各个消费者平稳的度过业务请求的高峰，其实还有一个场景.

大伙可以到我的RabbitMQ专栏获取更多信息demo示例这里拿概述上一篇文章RabbitMQ高级特性——消息的可靠投递（confirm模式与return模式）中介绍了RabbitMQ提供的两种保证消息投递可靠性的方式：confirm确认模式 return 退回模式这两种方式实质上是提供了对消息生产者侧的消息可靠性保证，保证了生产者的消息能正确的进入预期的队列中。本文将介绍一下Consumer Ack，这是一种面向消费者的消息可靠性保证方案。Consumer Ackack——ac

概述顾名思义，就是MQ在整个msg的生产到消费者接收到msg过程中的可靠性。RabbitMQ提供了一下两种方式来保证消息投递的可靠性：confirm确认模式 return 退回模式回顾一下rabbitmq整个消息的投递过程producer--->rabbitmq broker--->exchanger--->queue--->cunsumerconfirm确认模式中producer将消息发送给exchanger时候，将设置confirmCallback，之后消

大伙可以到我的RabbitMQ专栏获取更多信息demo示例这里拿不多bb直接上菜依赖生产者和消费者都需要引入该依赖 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </depend

大伙可以到我的RabbitMQ专栏获取更多信息demo示例这里拿模式说明Topics模式，也是功能最为强大的一种模式，与routing模式类似，只不过是通过通配符来进行message与queue之间的匹配。当交换机的模式为topic模式时，根据message的routing key去匹配queue的通配符，以上图为例，Q1的通配符为 *.orange* ，Q2的通配符为 *.*.rabbit 和 lazy.#* 和 # 都是占位符，* 代表一个单词，# 代表0个或者多个单词，单词直接

大伙可以到我的RabbitMQ专栏获取更多信息模式说明以日志存储使用场景为例，日志分为不同级别：error、info、warning、debug、trace等，不同日志级别的日志量也是不一样的，级别越高日志量相对越小。通常情况下因为不同级别日志的数量级不一样，其对应的处理方式也不一样：有些情况下日志需要入库，数据库不能承受大量日志存储，一般来说数量级较小的日志界别可以直接入库，例如error级别的日志；info级别的日志由于数量级较大可能会先暂存于缓存中，之后再对其做细致的处理。在此

大伙可以到我的RabbitMQ专栏获取更多信息模式说明Publish/Subscribe模式，也叫订阅模式，在该模式中，使用到了Exchanger（交换机），消息的传递过程发生了变化：Publisher（生产者）：消息现在不直接发送到Queue中了，而是把消息发送给Exchanger Consumer（消费者）：消息的接收者，会一直等待消息的到来 Queue（队列）：消息队列接收消息并缓存消息 Exchanger（交换机）： 接收生产者发送的消息 处理消息的分发，如将消息传递给某

模式说明Work queues：显而易见，与简单模式不同的是，Work queues 模式存在多个消费者，多个消费者其实是竞争关系，C1 C2只有一个能从MQ队列中获取到消息应用场景：对于任务过重或者任务较多情况下，使用Work queues模式可以提高任务的处理速度比如P端的任务每秒有1000个，但是每个C端每秒只能处理500个，所以两个C端共同“竞争”MQ中的任务就可以处理1000个消息了，需要注意的是C1和C2获得的消息互不相同。其实Work queues模式就是在简单模式上的一对

概述本篇将要通过一个Demo来进一步的了解RabbitMQ，关于RabbitMQ的基本介绍可以参考我的上一篇文章：初识RabbitMQ：RabbitMQ基本概念和运行方式控制台的基本使用怎么安装和开启RabbitMQ控制台就不在此讨论了，网上相关文档有很多QAQ登陆控制台开启控制台后，打开控制台，控制台地址默认关口是15672：http://localhost:15672/#/默认用户账号密码：guest/guest登陆后：控制台基本介绍Overview：MQ运行

AMQPAMQP全称Advanced Message Queuing Protocol（高级消息队列协议），是一个网络协议，是应用层协议的一个开放标准，为面向消息的中间件而设计。基于此协议的客户端于消息中间件可以传递消息，一个平台中立、产品中立、语言中立的协议（并不受客户端、中间件产品、不同开发语言等条件的限制）。Publisher（生产者）产生消息的源Consumer（消费者）从MQ获取消息Exchange（交换机）功能真的类似于网络交换机，是用来分发消息的 将消息分