Rabbitmq笔记

rabbitmq概述

定义：RabbitMQ 即一个消息队列，主要是用来实现应用程序的异步和解耦，同时也能起到消息缓冲，消息分发的作用。

作用：

1. 流量消峰
2. 应用解耦
3. 异步处理（不同服务之间的响应时间不同，导致服务器之间会进行等待，使用mq获取服务的消息）

MQ分类

• ActiveMQ：优点：单机吞吐量万级，时效性ms级，可用性高，基于主从架构实现可用性高没消息可靠性较低的概率丢失数据
• Kafka：为大数据而生的消息中间件，百万级的TPS吞吐量，在数据采集，传输，存储的过程中发挥作用，优点：吞吐量高
• RocketMQ：优点：单机吞吐量十万级，可用性非常高，分布式架构，消息可以做到 0 丢失，MQ 功能较为完善，还是分布式的，扩展性好，支持 10 亿级别的消息堆积，不会因为堆积导致性能下降

RabbitMQ:由于 erlang 语言的高并发特性，性能较好；吞吐量到万级，MQ 功能比较完善，健壮、稳定、易用、跨平台、支持多种语言。

核心

生产者：产生数据发送消息的程序是生产者

交换机：交换机是 RabbitMQ 非常重要的一个部件，一方面它接收来自生产者的消息，另一方面它将消息推送到队列中。交换机必须确切的知道如何处理它接收到的消息，是将这些消息推送到特定队列还是推送到多个队列，亦或者是把消息丢弃，这个得由交换机类型决定。

对列：队列是 RabbitMQ 内部使用的一种数据结构，尽管消息流经 RabbitMQ 和应用程序，但它们只能存储在队列中。队列仅受主机的内存和磁盘限制约束，本质上是一个大的消息缓冲区。许多生产者可以将消息发送到一个队列，许多消费者可以尝试从一个队列接收数据。这就是我们使用队列的方式。

消费者：消费与接收具有相似的含义。消费者大多时候是一个等待接收消息的程序。请注意生产者，消费者和消息中间件很多时候并不在一个机器上。同一个应用程序既可以是生产者又可以是消费者。

生产者与交换机绑定，交换机绑定多个对列，一个对列与一个消费者绑定（如果两个消费者对应一个对列者消息只有一个消费者收到）

模式

1. 简单模式
2. 工作模式
3. 发布订阅模式
4. 路由模式
5. 主题模式
6. 发布确认模式

RabbitMQ工作原理：

术语

Broker：接收和分发新消息的应用，RabbitMQ Server 就是 Message Broker
Virtual host：出于多租户和安全因素设计的，把 AMQP 的基本组件划分到一个虚拟的分组中，类似与网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ Server 提供的服务时，可以划分出多个 vhost，多个用户在自己的 vhost 创建 exchange / queue 等。
Connection：Producer 和 Channel 与 broker 之间的连接。
Channel：如果每一次访问 RabbitMQ 都建立一个 Connection，在消息量大的时候建立 TCP Connection 的开销将是巨大的，效率也较低。Channel 是在 Connection 内部建立的逻辑连接，如果应用程序支持多线程，通常每个 Thread 建立单独的 Channel 进行通讯。AMQP 包含了 channel id 帮助客户端和 Message broker 识别 channel，所以 channel 之间是完全隔离的。Channel 作为轻量级的 Connection 极大减少了操作系统建立 TCP Connection 的开销。
Exchange：Message 到达 broker 的第一站，根据分发规则，匹配查询表中的 routing key，分发到 queue 中去。常用的类型有：direct（point-to-point）， topic (publish-subscribe) and fanout (multicast)
Queue：消息最终被放到这里等待被 comsumer 取走。
Binding：exchange 和 queue 之间的虚拟连接，binding 中可以包含有 routing key，binding 信息被保存到 exchange 中的查询表中，用于 message 的分发依据。

基础rabbitmq使用

生产者

public class Producer {
 private final static String QUEUE_NAME = "hello";
 public static void main(String[] args) throws Exception {
 //创建一个连接工厂
 ConnectionFactory factory = new ConnectionFactory();
 factory.setHost("182.92.234.71");
 factory.setUsername("admin");
 factory.setPassword("123");
 //channel 实现了自动 close 接口 自动关闭 不需要显示关闭
 try(Connection connection = factory.newConnection();Channel channel = 
connection.createChannel()) {
 /**
 * 生成一个队列
 * 1.队列名称
 * 2.队列里面的消息是否持久化 默认消息存储在内存中
 * 3.该队列是否只供一个消费者进行消费 是否进行共享 true 可以多个消费者消费
 * 4.是否自动删除 最后一个消费者端开连接以后 该队列是否自动删除 true 自动删除
 * 5.其他参数
 */
 channel.queueDeclare(QUEUE_NAME,false,false,false,null);
 String message="hello world";
 /**
 * 发送一个消息
 * 1.发送到那个交换机
 * 2.路由的 key 是哪个
 * 3.其他的参数信息
 * 4.发送消息的消息体
 */
 channel.basicPublish("",QUEUE_NAME,null,message.getBytes());
 System.out.println("消息发送完毕");
 }
 } }

消费者

public class Consumer {
 private final static String QUEUE_NAME = "hello";
 public static void main(String[] args) throws Exception {
 ConnectionFactory factory = new ConnectionFactory();
 factory.setHost("182.92.234.71");
 factory.setUsername("admin");
 factory.setPassword("123");
 Connection connection = factory.newConnection();
 Channel channel = connection.createChannel();
 System.out.println("等待接收消息....");
 //推送的消息如何进行消费的接口回调
 DeliverCallback deliverCallback=(consumerTag,delivery)->{
 String message= new String(delivery.getBody());
 System.out.println(message);
 };
 //取消消费的一个回调接口 如在消费的时候队列被删除掉了
 CancelCallback cancelCallback=(consumerTag)->{
 System.out.println("消息消费被中断"）
 };
 /**
 * 消费者消费消息
 * 1.消费哪个队列
 * 2.消费成功之后是否要自动应答 true 代表自动应答 false 手动应答
 * 3.消费者未成功消费的回调
 */
 channel.basicConsume(QUEUE_NAME,true,deliverCallback,cancelCallback);
 } }

工作模式

工作对列

概念

工作队列(又称任务队列)的主要思想是避免立即执行资源密集型任务，而不得不等待它完成。相反我们安排任务在之后执行。我们把任务封装为消息并将其发送到队列。在后台运行的工作进程将弹出任务并最终执行作业。当有多个工作线程时，这些工作线程将一起处理这些任务。

轮询分发

mq的所有分发方式，自动设置，不需要进行额外编码，不同进程间处理业务时间不同可能有不同的分发策略，默认轮询分发

消息应答

防止消息没有处理前的丢失，消费者在接收到消息并且处理该消息之后，告诉 rabbitmq 它已经处理了，rabbitmq 可以把该消息删除了。

自动应答

消息发送后立即被认为传送成功，仅适用在消费者可以高效并以某种速率能够处理这些消息的情况下使用

消息应答方法

A.Channel.basicAck(用于肯定确认)RabbitMQ 已知道该消息并且成功的处理消息，可以将其丢弃了

B.Channel.basicNack(用于否定确认)

C.Channel.basicReject(用于否定确认) 与 Channel.basicNack 相比少一个参数不处理该消息了直接拒绝，可以将其丢弃了

默认消息采用的是自动应答，要想实现消息消费不丢失，需要设置为手动应答

multiple 的 true 和 false 代表不同意思true代表批量应答channel上未应答的消息

消息重新入队

将消息回收分发给其他线程

//消息标记tag，false代表只应答接受到的那个传递的消息。true为应答所有消息包括传递过来的消息  ，消费者应答方式 
channel.basicAck(delivery.getEnvelope().getDeliveryTag(),false);
//生产者，发布方式
channel.basicPublish("",QUEUE_NAME,MessageProperties.PERSISTENT_TEXT_PLAIN,message.getBytes());

mq对列持久化

概念：保证mq停掉服务后消息生产者发送过来的消息不会丢失

对列持久化

mq重启非持久化的对列会被删除，为保证对列不删除需要实现对列持久化

boolean durable=true； 
channel.queueDeclare(name,durable,false,false,null)

持久化对列需要删除以前声明的对列或者重新创建新对列

消息持久化：

//该方法不保证强有力的持久化
channel.basicPublish("",QUEUE_NAME,MessageProperties.PERSISTENT_TEXT_PLAIN,message.getBytes());

不公平分发

解决机器性能不一致问题

//消费方设定
channel.basicQos(1);

预期值

消息的发送是异步，channel上不止一个消息所以设置缓冲区大小避免无止境的未确认大小的消息，达到预期值停止在通道传递更多值

预取值在消费方设定

int count=3;
//设置预取值
channel.basicQos(count);

确认发布

生产者将信道设置为confirm模式，在该信道上的消息设置唯一的ID，消息入队后发送broker给生产者，如果对列与消息有持久化则在确定消息写入磁盘后发出

confirm 模式最大的好处在于他是异步的，一旦发布一条消息，生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用便可以通过回调方法来处理该确认消息，如果 RabbitMQ 因为自身内部错误导致消息丢失，就会发送一条 nack 消息，生产者应用程序同样可以在回调方法中处理该 nack 消息。

确认发布策略

发布去人默认是没开启得

  Channel channel = connection.createChannel();
channel.confirmSelect();

单个确认发布

一种同步确认发布的方式，只有他被确认或超时后，后续的才能继续发布（缺点：发布速度慢）

public static void publishMessageIndividually() throws Exception {
 try (Channel channel = RabbitMqUtils.getChannel()) {
 String queueName = UUID.randomUUID().toString();
 channel.queueDeclare(queueName, false, false, false, null);
 //开启发布确认
 channel.confirmSelect();
 long begin = System.currentTimeMillis();
 for (int i = 0; i < MESSAGE_COUNT; i++) {
 String message = i + "";
 channel.basicPublish("", queueName, null, message.getBytes());
 //服务端返回 false 或超时时间内未返回，生产者可以消息重发
 boolean flag = channel.waitForConfirms();
 if(flag){
 System.out.println("消息发送成功");
 }
 }
 long end = System.currentTimeMillis();
 System.out.println("发布" + MESSAGE_COUNT + "个单独确认消息,耗时" + (end - begin) + 
"ms");
 } }

批量确认发布

批量发布消息，一起确认（缺点：发生故障无法判断是哪个消息）

public static void publishMessageBatch() throws Exception {
 try (Channel channel = RabbitMqUtils.getChannel()) {
 String queueName = UUID.randomUUID().toString();
 channel.queueDeclare(queueName, false, false, false, null);
 //开启发布确认
 channel.confirmSelect();
 //批量确认消息大小
 int batchSize = 100;
 //未确认消息个数
 int outstandingMessageCount = 0;
 long begin = System.currentTimeMillis();
 for (int i = 0; i < MESSAGE_COUNT; i++) {
 String message = i + "";
 channel.basicPublish("", queueName, null, message.getBytes());
 outstandingMessageCount++;
 if (outstandingMessageCount == batchSize) {
 channel.waitForConfirms();
 outstandingMessageCount = 0;
 }
 }
 //为了确保还有剩余没有确认消息 再次确认
 if (outstandingMessageCount > 0) {
 channel.waitForConfirms();
 }
 long end = System.currentTimeMillis();
 System.out.println("发布" + MESSAGE_COUNT + "个批量确认消息,耗时" + (end - begin) + 
"ms");
 } }

异步确认发布

利用回调函数来达到消息可靠性传递，中间件也是通过函数回调来保证是否投递成功

异步确认发布：

public static void publishMessageAsync() throws Exception {
 try (Channel channel = RabbitMqUtils.getChannel()) {
 String queueName = UUID.randomUUID().toString();
 channel.queueDeclare(queueName, false, false, false, null);
 //开启发布确认
 channel.confirmSelect();
 /**
 * 线程安全有序的一个哈希表，适用于高并发的情况
 * 1.轻松的将序号与消息进行关联
 * 2.轻松批量删除条目 只要给到序列号
 * 3.支持并发访问
 */
 ConcurrentSkipListMap<Long, String> outstandingConfirms = new 
ConcurrentSkipListMap<>();
 /**
 * 确认收到消息的一个回调
 * 1.消息序列号
 * 2.true 可以确认小于等于当前序列号的消息
 * false 确认当前序列号消息
 */
 ConfirmCallback ackCallback = (sequenceNumber, multiple) -> {
 if (multiple) {
 //返回的是小于等于当前序列号的未确认消息 是一个 map
 ConcurrentNavigableMap<Long, String> confirmed = 
outstandingConfirms.headMap(sequenceNumber, true);
 //清除该部分未确认消息
 confirmed.clear();
 }else{
 //只清除当前序列号的消息
 outstandingConfirms.remove(sequenceNumber);
 }
 };
 ConfirmCallback nackCallback = (sequenceNumber, multiple) -> {
 String message = outstandingConfirms.get(sequenceNumber);
 System.out.println("发布的消息"+message+"未被确认，序列号"+sequenceNumber);
 };
 /**
 * 添加一个异步确认的监听器
 * 1.确认收到消息的回调
 * 2.未收到消息的回调
 */
 channel.addConfirmListener(ackCallback, null);
 long begin = System.currentTimeMillis();
 for (int i = 0; i < MESSAGE_COUNT; i++) {
 String message = "消息" + i;
 /**
 * channel.getNextPublishSeqNo()获取下一个消息的序列号
 * 通过序列号与消息体进行一个关联
 * 全部都是未确认的消息体
 */
 outstandingConfirms.put(channel.getNextPublishSeqNo(), message);
 channel.basicPublish("", queueName, null, message.getBytes());
 }
 long end = System.currentTimeMillis();
 System.out.println("发布" + MESSAGE_COUNT + "个异步确认消息,耗时" + (end - begin) + 
"ms");
 } }

异步未确认消息的处理：把未确认的消息放到一个基于内存的能被发布线程访问的队列，比如说用 ConcurrentLinkedQueue 这个队列在 confirm callbacks 与发布线程之间进行消息的传递。

交换机

生产者只能将消息发送给交换机，其工作内容简单，接受生产者传来的消息然后将其推入对列，减缓及必须确切的知道如何处理收到的消息，翻到特定对列还是丢弃是交换机的类型决定的

类型：

直接，主题，标题，扇出

//第一个参数指定交换机的名称，空字符串表示默认或无名称交换机，消息能路由发送到对列中其实
//是由 routingKey(bindingkey)绑定 key 指定的
channel.basicPublish("",QUEUE_NAME,MessageProperties.PERSISTENT_TEXT_PLAIN,message.getBytes());
  

临时对列

连接rabbit时都需要一个全新的空对列，我们可以创建一个具有随机名称的队列，或者能让服务器为我们选择一个随机队列名称那就更好了。其次一旦我们断开了消费者的连接，队列将被自动删除。

//临时创建对列
String queue=channel.queueDeclare().getQueue();

绑定

binding：exchange和queue之间的桥梁

Fanout（扇出）

将接受到的消息广播到他知道的所有对列

Direct exchange

消息只去到绑定的routingKey对列中，其他未绑定的信息类型将被丢弃

多重绑定

当然如果 exchange 的绑定类型是 direct，但是它绑定的多个队列的 key 如果都相同，在这种情况下虽然绑定类型是 direct 但是它表现的就和 fanout 有点类似了，就跟广播差不多，如上

topics

发送到类型是 topic 交换机的消息的 routing_key 不能随意写，必须满足一定的要求，它必须是一个单词列表，以点号分隔开**。这些单词可以是任意单词，比如说：“stock.usd.nyse”, “nyse.vmw”, “quick.orange.rabbit”.这种类型的。当然这个单词列表最多不能超过 255 个字节。在这个规则列表中，其中有两个替换符是大家需要注意的**

*****(星号)可以代替一个单词

#(井号)可以替代零个或多个单词**

死信对列

概念：无法被消费的对列

来源：1.消息 TTL 过期 2.队列达到最大长度(队列满了，无法再添加数据到 mq 中) 3.消息被拒绝(basic.reject 或 basic.nack)并且 requeue=false.

延迟对列

延时队列,队列内部是有序的，最重要的特性就体现在它的延时属性上，延时队列中的元素是希望在指定时间到了以后或之前取出和处理，简单来说，延时队列就是用来存放需要在指定时间被处理的元素的队列。

使用场景：

1.订单在十分钟之内未支付则自动取消

2.新创建的店铺，如果在十天内都没有上传过商品，则自动发送消息提醒。

3.用户注册成功后，如果三天内没有登陆则进行短信提醒。

4.用户发起退款，如果三天内没有得到处理则通知相关运营人员。

5.预定会议后，需要在预定的时间点前十分钟通知各个与会人员参加会议

TTL：MQ中一个消息多重对列的属性表明一条消息或者该队列中的所有消息的最大存活时间，（ms）如果一条消息设置了 TTL 属性或者进入了设置 TTL 属性的队列，那么这条消息如果在 TTL 设置的时间内没有被消费，则会成为"死信"。如果同时配置了队列的 TTL 和消息的TTL，那么较小的那个值将会被使用，有两种方式设置 TTL。

对列TTL

创建两个队列 QA 和 QB，两者队列 TTL 分别设置为 10S 和 40S，然后在创建一个交换机 X 和死信交换机 Y，它们的类型都是 direct，创建一个死信队列 QD，

延时队列在需要延时处理的场景下非常有用，使用 RabbitMQ 来实现延时队列可以很好的利用RabbitMQ 的特性，如：消息可靠发送、消息可靠投递、死信队列来保障消息至少被消费一次以及未被正确处理的消息不会被丢弃。另外，通过 RabbitMQ 集群的特性，可以很好的解决单点故障问题，不会因为单个节点挂掉导致延时队列不可用或者消息丢失。

确认发布

不明原因导致mq重启，在重启期间生产者消息投递失败，导致消息丢失，需要手动处理和恢复

确认发布机制方案

回退消息

在仅开启了生产者确认机制的情况下，交换机接收到消息后，会直接给消息生产者发送确认消息，如果发现该消息不可路由，那么消息会被直接丢弃，此时生产者是不知道消息被丢弃这个事件的。通过mandatory参数可以在当消息传递过程中不可达目的地时将消息返回给生产者

备份交换机

幂等性

概念：用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。举个最简单的例子，那就是支付，用户购买商品后支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额发现多扣钱了，流水记录也变成了两条。在以前的单应用系统中，我们只需要把数据操作放入事务中即可，发生错误立即回滚，但是再响应客户端的时候也有可能出现网络中断或者异常等等

消息重复消费：

消费者在消费 MQ 中的消息时，MQ 已把消息发送给消费者，消费者在给 MQ 返回 ack 时网络中断，故 MQ 未收到确认信息，该条消息会重新发给其他的消费者，或者在网络重连后再次发送给该消费者，但实际上该消费者已成功消费了该条消息，造成消费者消费了重复的消息

解决：MQ 消费者的幂等性的解决一般使用全局 ID 或者写个唯一标识比如时间戳 或者 UUID 或者订单消费者消费 MQ 中的消息也可利用 MQ 的该 id 来判断，或者可按自己的规则生成一个全局唯一 id，每次消费消息时用该 id 先判断该消息是否已消费过。

消费端的幂等性保障

在海量订单生成的业务高峰期，生产端有可能就会重复发生了消息，这时候消费端就要实现幂等性，这就意味着我们的消息永远不会被消费多次，即使我们收到了一样的消息。业界主流的幂等性有两种操作:a.唯一 ID+指纹码机制,利用数据库主键去重, b.利用 redis 的原子性去实现

唯一ID+指纹码机制

指纹码:我们的一些规则或者时间戳加别的服务给到的唯一信息码,它并不一定是我们系统生成的，基本都是由我们的业务规则拼接而来，但是一定要保证唯一性，然后就利用查询语句进行判断这个 id 是否存在数据库中,优势就是实现简单就一个拼接，然后查询判断是否重复；劣势就是在高并发时，如果是单个数据库就会有写入性能瓶颈当然也可以采用分库分表提升性能，但也不是我们最推荐的方式。

redis原子性

利用Redis执行setnx命令，天然具有幂等性，从而实现不重复消费

优先级对列

场景：为高级用户开绿色通道

代码添加优先级

Map<String, Object> params = new HashMap();
params.put("x-max-priority", 10);
channel.queueDeclare("hello", true, false, false, params);

惰性队列：

消息保存在内存中还是在磁盘上，正常情况下在内存中，惰性对列将消息保存在磁盘中（如果消费者宕机导致消息长时间无法消费）

Map<String, Object> args = new HashMap<String, Object>();
args.put("x-queue-mode", "lazy");
channel.queueDeclare("myqueue", false, false, false, args);

MQ集群

1.修改 3 台机器的主机名称
vim /etc/hostname
2.配置各个节点的 hosts 文件，让各个节点都能互相识别对方
vim /etc/hosts
10.211.55.74 node1
10.211.55.75 node2
10.211.55.76 node3
 3.以确保各个节点的 cookie 文件使用的是同一个值
在 node1 上执行远程操作命令
scp /var/lib/rabbitmq/.erlang.cookie root@node2:/var/lib/rabbitmq/.erlang.cookie
scp /var/lib/rabbitmq/.erlang.cookie root@node3:/var/lib/rabbitmq/.erlang.cookie
4.启动 RabbitMQ 服务,顺带启动 Erlang 虚拟机和 RbbitMQ 应用服务(在三台节点上分别执行以
下命令)
rabbitmq-server -detached
5.在节点 2 执行
rabbitmqctl stop_app
(rabbitmqctl stop 会将 Erlang 虚拟机关闭，rabbitmqctl stop_app 只关闭 RabbitMQ 服务)
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@node1
rabbitmqctl start_app(只启动应用服务)
6.在节点 3 执行
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@node2
rabbitmqctl start_app
7.集群状态
rabbitmqctl cluster_status
8.需要重新设置用户
创建账号
rabbitmqctl add_user admin 123
设置用户角色
rabbitmqctl set_user_tags admin administrator
设置用户权限
rabbitmqctl set_permissions -p "/" admin ".*" ".*" ".*"
9.解除集群节点(node2 和 node3 机器分别执行)
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl start_app
rabbitmqctl cluster_status
rabbitmqctl forget_cluster_node rabbit@node2(node1 机器上执行)

镜像对列

防止宕机，备份一份到其他mq

(不同机器上创建的对列在其他机器上根本就没有，如果一个mq宕机则对列消失，其他机器无法接收该机器的对列)

如果 RabbitMQ 集群中只有一个 Broker 节点，那么该节点的失效将导致整体服务的临时性不可用，并且也可能会导致消息的丢失。可以将所有消息都设置为持久化，并且对应队列的durable属性也设置为true，但是这样仍然无法避免由于缓存导致的问题：因为消息在发送之后和被写入磁盘井执行刷盘动作之间存在一个短暂却会产生问题的时间窗。通过 publisherconfirm 机制能够确保客户端知道哪些消息己经存入磁盘，尽管如此，一般不希望遇到因单点故障导致的服务不可用。引入镜像队列(Mirror Queue)的机制，可以将队列镜像到集群中的其他 Broker 节点之上，如果集群中的一个节点失效了，队列能自动地切换到镜像中的另一个节点上以保证服务的可用性。

Haproxy+Keepalive实现高可用负载均衡

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UF6H7Wcd-1665208136267)(D:\typoya\File\spring源码\image\image-20221007172421908.png)]

Federation Exchange

消息数据同步机制，减少网路延迟上的时间差异

Federation Queue

联邦队列可以在多个 Broker 节点(或者集群)之间为单个队列提供均衡负载的功能。一个联邦队列可以连接一个或者多个上游队列(upstream queue)，并从这些上游队列中获取消息以满足本地消费者消费消息的需求。