RabbitMQ

成为死信的第一种消费情况：过期都没有被消费

队列

交换机exchange

C

多个消费者监听同一个队列，每个消费者之间是竞争关系，但是消费者的消费能力不一，那就导致多个消费者之间负载不均衡。解决办法：轮询机制（默认策略）

P

33条

队列内存空间有限

queue3

绑定

消息过期：出列--->死信

在这里指定routingKey=user.add，进入队列一和队列四，其他队列都没有消息

内容

X

生产者

核心概念

routingKey=user.delete

工作队列模式：点对点，多个p，一个x，一个queue，多个C

死信机制TTL（time to live）：消息的存活时间，下面是产生死信的几种情况

简单消息模式：点对点，多个p，一个x，一个queue，一个C

routingKey=user.add

100条消息轮询机制启动

转发routingkey=a.normal

场景举例：下单成功的一瞬间发消息，延迟时间是15min，时间结束以后消费者接受到消息，判断订单有没有付钱，每一笔订单都会校验。1、用户订单没付钱，触发取消订单 2、用户已经取消订单，甩掉消息  3、订单了付钱，甩掉消息

消费者

通配符模式：点对点，多个p，一个x，多个queue，一个队列对应一个C，交换机必须指定为TopicExchange

没有消费者

场景:A同学买火车票11:59分买票下单12:00定时任务执行 订单存活1分钟 有效12:30 定时任务执行 订单存活时间31分钟 失效取消 误差1分钟

发送消息

成为死信的第三种消费情况：拒绝消费，并且丢弃消息，该消息成为死信

queue2

内存的空间有限出现的两个问题：1、消息太多会出导致队列占用的内存太大 。 2、消息太多内存导致队列崩溃，重启以后速度非常慢。解决内存占用问题：设置队列的属性--->惰性队列，比普通队列多设置一个属性，只会占用很小的内存放消息，绝大部分消息都持久化到磁盘，当队列消息消费完，从磁盘中取出一部分放内存中。空间换时间--持久化需要时间解决崩溃后恢复慢问题：设置队列的属性--->仲裁队列，比普通队列多设置一个属性。Redis-AOF(全量数据恢复)-对redis所有的写操作都执行一遍用于恢复数据，RDB（快照模式）-记录了某个瞬间数据的状态，恢复速度快。仲裁队列的恢复模式类似于RDB。它还可以提升集群中两个镜像集群直接数据同步的效率（类似于redis的主从）。

定向模式：点对点，多个p，一个x，多个queue，一个队列对应一个C，交换机必须指定为DirectExchang

routingKey=user.select

X2

所有的队列和交换机绑定的时候发现交换机是FanoutExchange就不用指定任何的转发规则，P发消息的时候只需要发内容，做到的效果就是队列里面的消息都是一样的，类似于“群发”。场景应用：当生产者发送用户登录成功消息时候，三个消费者：购物车，订单，浏览记录，接收到消息，并行查询提前预热。问题：当希望一部分Queue收得到消息，一部分Queue收不到的消息情况，衍生出定向模式

queue4

由死信机制衍生出死信解决方案：延迟消息

ttl：10s

TopicExchange

发消息到收消息的时间存在误差：毫秒级别

拒绝消费，并且丢弃消息

超出队列容量限制

消息收到以后回调生产者告诉消息收到

在这里指定routingKey=user.add，进入队列一，其他队列都没有消息

routingkey断言转发的规则指定消息通过交换机转发给哪个队列

定时任务 30分钟运行一次 订单30分钟有效

这种模式的问题：消息堆积，解决方法：提升消费者消费能力

广播模式：点对点，多个p，一个x，多个queue，一个队列对应一个C，交换机必须指定为FanoutExchange

routingKey=user.*

ttl=15minexchange=x1

死信交换机

成为死信的第二种消费情况：超出大小限制：1、消息的体积大于队列容量  2、队列满了以后再来的消息直接成为死信（默认模式）  3、队列满了以后新来消息挤出队列头旧消息，旧消息成为死信（需要配置该模式）4、现在消息大小比如为1kb，新消息大小超过直接成为死信

队列实现持久化保证消息不丢失

DirectExchang

惰性队列和仲裁队列

出列--->死信

消费确认机制：a、自动确认：收到了消息，消息就会出列 b、手动确认c、手动拒绝：消费者异常。①拒绝的时候记录日志再消息丢掉，②消息放回去：消息出列再入列，消息的属性是有标识的，消息的属性字段会记录曾经被拒绝过

场景:A同学买火车票12:01分买票下单12:00 定时任务执行 订单不存在12:30 定时任务执行 订单存活时间29分钟 有效13:00 定时任务执行 订单存活时间59分钟 失效取消 误差29分钟

相当于网关

queue1

无所谓有无消费者

保证消息进入队列：使用回调函数实现

X1

所有的队列和交换机绑定的时候发现交换机是DirectExchang，就必须指定一个属性routingKey问题：定向模式只能保证消息进入部分队列里去，没有队列能够拿到全部消息。衍生出定向模式的衍生模式：通配符模式TopicExchange

持久化到磁盘

RabbitMQ高级

2. 镜像集群：特点：\\镜像集群会复制队列的数据到所有节点，实现数据的冗余存储。\\每个队列都有一个主节点和一个或多个镜像节点。\\镜像节点会复制主节点上的数据，保证数据的高可用性。优点：\\提供数据冗余，确保在某个节点故障时数据不会丢失。\\具有较高的可靠性和容错能力。缺点：\\网络开销：由于数据复制到多个节点，可能会增加网络开销。\\资源占用：复制数据会占用更多的系统资源。在选择普通集群和镜像集群时，需要根据具体的应用场景和需求进行权衡。如果对数据可靠性有较高要求，建议选择镜像集群。如果对数据可靠性有较高要求，建议选择镜像集群。如果对数据可靠性要求不高，且希望简单轻量，可以选择普通集群。

FanoutExchange

死信队列：没有消费者

转发routingkey=a.dead

内容：routingkey=a.dead

routingkey

由此可见定时任务是在订单有效期这种场景不适合的，误差太大了，但是类似给公司人员发过生日邮件这种场景就适合定时任务，时间精度要求不高，时间精度要求高的场景用延迟消息方案

消费者保证消费不丢失，类似卡夫卡的ack确认机制

1. 普通集群：特点：\\普通集群不会复制队列的数据。\\消息存储在一个节点上，如果该节点宕机，队列中的消息将会丢失。\\通过 Erlang 分布式机制实现节点间的通信和数据同步。优点：\\简单，易于设置和管理。\\适用于一些不要求高可靠性和数据冗余的场景。缺点：\\单一点故障：如果节点宕机，与该节点关联的队列数据将不可用。\\不适用于对数据可靠性有更高要求的场景。

消息模式：五种