Blueeyedboy521的博客

RabbitMQ是基于Erlang语言编写，而Erlang又是一个面向并发的语言，天然支持集群模式。RabbitMQ的集群有两种模式：镜像集群虽然支持主从，但是主从同步不是强一致性，某些情况下可能有数据丢失的风险。因此在RabbitMQ的3.8版本以后，推出了新的功能：仲裁队列来替代镜像集群，底层采用Raft协议确保主从数据的一致性。普通集群，或者叫标准集群(classic cluster），局部提下列特征：参考：RabbitMQ高级特性-搭建RabbitMQ普通集群镜像集群：本质是主从模式，具备下面的特征

1）启动一个新的MQ容器：2）进入容器控制台：3）停止mq进程4）重置RabbitMQ中的数据：5）加入mq1：6）再次启动mq进程我们先查看下quorum.queue这个队列目前的副本情况，进入mq1容器：执行命令：结果：现在，我们让mq4也加入进来：结果：再次查看：查看控制台，发现quorum.queue的镜像数量也从原来的 +2 变成了 +3：...

从RabbitMQ 3.8版本开始，引入了新的仲裁队列，他具备与镜像队里类似的功能，但使用更加方便。在任意控制台添加一个队列，一定要选择队列类型为Quorum类型。在任意控制台查看队列：可以看到，仲裁队列的 + 2字样。代表这个队列有2个镜像节点。因为仲裁队列默认的镜像数为5。如果你的集群有7个节点，那么镜像数肯定是5；而我们集群只有3个节点，因此镜像数量就是3.可以参考对镜像集群的测试，效果是一样的。...

在刚刚的案例中，一旦创建队列的主机宕机，队列就会不可用。不具备高可用能力。如果要解决这个问题，必须使用官方提供的镜像集群方案。官方文档地址：https://www.rabbitmq.com/ha.html默认情况下，队列只保存在创建该队列的节点上。而镜像模式下，创建队列的节点被称为该队列的主节点，队列还会拷贝到集群中的其它节点，也叫做该队列的镜像节点。但是，不同队列可以在集群中的任意节点上创建，因此不同队列的主节点可以不同。甚至，一个队列的主节点可能是另一个队列的镜像节点。用户发送给队列的一切请求，例如发

我们通过docker模拟集群搭建，端口分配如下：RabbitMQ底层依赖于Erlang，而Erlang虚拟机就是一个面向分布式的语言，默认就支持集群模式。集群模式中的每个RabbitMQ 节点使用 cookie 来确定它们是否被允许相互通信。要使两个节点能够通信，它们必须具有相同的共享秘密，称为Erlang cookie。cookie 只是一串最多 255 个字符的字母数字字符。每个集群节点必须具有相同的 cookie。实例之间也需要它来相互通信。我们先在之前启动的mq容器中获取一个cookie值，作为集群

当生产者发送消息的速度超过了消费者处理消息的速度，就会导致队列中的消息堆积，知道队列存储消息达到上限。最早接收到的消息，可能就会成为死信，会被丢弃，这就是消息堆积的问题。从RabbitMQ的3.6.0版本开始，就增加了Lazy Queues的概念，也就是惰性队列。惰性队列的特征如下：而要设置一个队列为惰性队列，只需要在声明队列时，指定x-queue-mode属性为lazy即可。可以通过命令行将一个运行中的队列修改为惰性队列2、用SpringAMQP声明惰性队列@Bean的方式注解方式测试发送消

如下情况的消息会成为死信：如果该队列配置了dead-letter-exchange属性，指定了一个交换机，name队列中的死信就会投递到这个交换机中，而这个交换机称为死信交换机（Dead Letter Exchange，简称DLX）队列发现消费者无法处理消息时，比如失败次数太多，队列就会根据配置的死信交换机，路由到死信队列，在之前的消费失败处理策略中RepublishMessageRecoverer（重试耗尽后，将失败消息投递到指定的交换机），是由消费者来投递到error.queue。比如下对比：TTL（

消息从生产者发送到exchange，再到queue，再到消费者，有哪些导致消息丢失的可能性？RabbitMQ提供了publisher confirm机制来避免消息发送到MQ过程中丢失。消息发送到MQ以后，会返回一个结果给发送者，表示消息是否处理成功。结果有两种请求：在publisher服务的application.yml中添加配置配置说明每个RabbitTemplate只能配置一个ReturnCallback，因此需要在项目启动的过程之，配置：3、配置ConfirmCallback(消息投递到交换机成

一、场景先看这么几个面试题：如何保证消息的可靠性投递？即如何确定消息是否发送成功？如果失败如何处理（补偿机制）？如何保证消息不被重复消费？或者说，如何保证消息消费时的幂等性？二、消息的可靠性投递1、消息确认消息确认包括主要 生产者发送确认 和 消费者接受确认 ，因为发送消息的过程中我们是无法确认消息是否能路由等，一旦消息丢失我们就无法处理，所以需要确认消息，避免消息丢失。1.1、生产者确认我们知道生产者与消费者是完全隔离的，不做任何配置的情况下，生产者是不知道消息是否真正到达 Rabbit