程序员笔记

RabbitMQ的镜像队列是将消息副本存储在一组节点上，以提高可用性和可靠性。镜像队列将队列中的消息复制到一个或多个其他节点上，并使这些节点上的队列保持同步。当一个节点失败时，其他节点上的队列不受影响，因为它们上面都有消息的备份。这提高了消息的可靠性和可用性。镜像队列的设置可以在创建队列时定义。您可以指定要创建的节点数和要在哪些节点上运行备份队列。RabbitMQ支持同步和异步镜像模式。在同步模式下，消息必须被复制到所有备份节点，而在异步模式下，消息可以被复制到一个或多个备份节点。

当生产者将消息发送到RabbitMQ的时候，队列中的消息会尽可能地存储在内存之中，这样可以更加快速地将消息发送给消费者。如果要将普通队列转换为隋性队列，那么我们需要忍受性能损耗，需要将缓存中的消息转存到磁盘中，然后才能接收新的消息。惰性队列会将收到的消息直接存入文件系统中，而不管是持久化的或者是非持久化的。这样减少了内存的消耗，但是会增加I/O的使用，如果消息是持久化的，那么这样的I/O操作不可避免。注意如果惰性队列中存储的是非持久化的消息，内存的使用率会一直很稳定，但是重启后消息一样会丢失。

交换器、队列、消息都可以设置是否持久化。交换器和队列持久化的含义是元数据持久化。消息持久化的含义是消息本身持久化。将交换器、队列、消息都设置了持久化之后能百分之百保证数据不丢失吗？答案是不能从消费者来说，如果在订阅消费队列时将 autoAck 参数设置为 true，那么当消费者接收到相关消息之后，还没来得及处理就宕机了，这样也算数据丢失。这种情况很好解决，将autoAck 参数设置为 false，并进行手动确认。

下面的链接是最快最简单的一种集群部署方法上的的例子中，没有映射端口，所以没法从宿主机外部连接容器，下面的yml文件中，暴露了端口。每个容器应用都映射了宿主机的端口，分别是5602，5612，5622docker compse文件如下通过docker-compose up命令，就可以启动三个集群的容器了。

上一节，我们用docker-compose搭建了一个RabbitMQ集群，这一节我们来分析一下集群的原理。

一般情况下，可以使用默认的内建配置来有效地运行RabbitMQ，并且大多数情况下也并不需要修改任何 RabbitMQ的配置。当然，为了更加有效地操控 RabbitMQ，也可以利用调节系统范围内的参数来达到定制化的需求。RabbitMQ提供了三种方式来定制化服务：(1)环境变量（Enviroment Variables )。RabbitMQ服务端参数可以通过环境变量进行配置，例如，节点名称、RabbitMQ配置文件的地址、节点内部通信端口等。(2）配置文件（Configuration File )

我们还是利用docker来安装RabbitMQ集群。3分钟安装一个集群，开始。前提条件，docker安装了docker-compose。进入控制台：http://192.168.56.201:15672/#/如上面所示，我们进入ID为a8abe421a79a的容器。用cat命令，输出到docker-compose.yml。启动完成后，发现确实是启了三个RabbitMQ的容器。账号默认是：用户名：user，密码：bitnami。这是最简单的方式安装一个RabbitMQ集群。

RabbitMQ默认创建的vhost 为“/”，如果不需要多个 vhost 或者对 vhost的概念不是很理解，那么用这个默认的vhost 也是非常合理的，使用默认的用户名 guest 和密码 guest 就可以访问它。RabbitMQ management插件可以提供Web管理界面用来管理如前面所述的虚拟主机、用户等，也可以用来管理队列、交换器、绑定关系、策略、参数等，还可以用来监控 RabbitMQ服务的状态及一些数据统计类信息，可谓是功能强大，基本上能够涵盖所有RabbitMQ管理的功能。

Message Queue的需求由来已久，80年代最早在金融交易中，高盛等公司采用Teknekron公司的产品，当时的Message queuing软件叫做：the information bus（TIB）。TIB被电信和通讯公司采用，路透社收购了Teknekron公司。之后，IBM开发了MQSeries，微软开发了Microsoft Message Queue（MSMQ）。这些商业MQ供应商的问题是厂商锁定，价格高昂。

上一节我们写了一段原生API来进行生产和消费的例子。实际上SpringBoot对原生RabbitMQ客户端做了二次封装，让我们使用API的代价更低。

在上一节中，我们使用docker部署了RabbitMQ，这一节我们将写一段生产者和消费者的代码。将用到rabbitmq的原生API来进行生产和发送消息。

容器下安装rabbitmq