zhou920786312的博客

我的部署和数据目录都在/data/rabbitmq目录下，只要将/data/rabbitmq的所有内容复制到新的磁盘目录就可以。

【代码】【无标题】

更多的说明看 RabbitMQ–扩展–2.1–性能测试–window.md。

上述的内存与磁盘报警分别为mem_alarm disk_free_alarm，如果这两个值为true，则需要及时响应。如果出现了内存告警，并且机器还有可用内存，可以通过命令调整内存阈值，解除告警。如果出现了内存告警，并且机器还有可用内存，可以通过命令调整内存阈值，解除告警。使用API可以查看mq状态。可以作为监控数据使用。

RabbitMQ的配置，可以通过环境变量、配置文件、运行时参数(和策略)等三种方式来定制化相应的服务。

负载均衡是一种计算机网络技术，用于在多个计算机(计算机集群)、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到最佳资源使用、最大化吞吐率、最小响应时间及避免过载的目的。使用带有负载均衡的多个服务器组件，取代单一的组件，可以通过冗余提高可靠性。试想如果前面配置的HAProxy主机192.168.0.9突然宕机或者网卡失效，那么虽然RabbitMQ集群没有任何故障，但是对于外界的客户端来说所有的连接都会被断开，结果将是灾难性的。确保负载均衡服务的可靠性同样显得十分重要。

在RabbitMQ 中可以使用Firehose功能来实现消息追踪，Firehose 可以记录每一次发送或者消费消息的记录，方便RabbitMQ 的使用者进行调试、排错等。

Shovel插件只提供数据迁移的作用，非复制。举例：C中心rabbitmq产生一条数据A，DR中心rabbitmq部署了Shovel插件后，会去C中心消费数据A，最终C中心rabbitmq没有数据A，DR中心rabbitmq有数据A。

可以将消息从一个RabbitMQ集群同步到另一个集群，但它并不直接处理消息消费。也就是说当主机房的消费者消费了消息，灾备机房队列中的消息并不会因此消失。联邦交换机不能用于做灾备双活，因为备份机房的消息会积压。

rabbitmq

rabbitmq

网络分区是在使用RabbitMQ 时所不得不面对的一个问题，网络分区的发生可能会引起消息丢失或者服务不可用等。可以简单地通过重启的方式或者配置自动化处理的方式来处理这个问题。

如果在使用RabbitMQ 的过程中出现了异常情况，通过查看RabbitMQ 的服务日志可以让你在处理异常的过程中事半功倍。RabbitMQ 日志中包含各种类型的事件，比如连接尝试、服务启动、插件安装及解析请求时的错误等。

【代码】RabbitMQ--扩展--02--性能测试。

cookie 相当于密钥令牌，集群中的RabbitMQ 节点需要通过交换密钥令牌以获得相互认证如果节点的密钥令牌不一致，那么在配置节点时就会有如下的报错，注意字体加粗部分。

【代码】RabbitMQ--集成Springboot--10--两种加载方式。

对应RabbitMQ中Queue。

//初始化消费者数量//最大消费者数量//手动确认消息// 单个消费者一次接收的消息数，默认250}}}}

【代码】RabbitMQ--集成Springboot--07--死信交换机和死信队列配置。

rabbitMQ有个方法channel.basicNack()能够让消息回到队列中，这样可以实现重试。但是这样没有明确重试次数，如果当前的消息一直重试的话，则后面的消息就会堆积起来，导致后面的消息无法消费。这是一个致命的缺点。因此这就需要设置重试次数来解决这种问题。下面提供几种解决方案。

【代码】RabbitMQ--集成Springboot--05--消息持久化。

【代码】RabbitMQ--集成Springboot--04--配置参数详解。

消息确认有2种，如下所示生产者 消息确认消费者 消息确认要使用消息确认，还需要修改配置文件。

我们看到，其实我们消息已经有一条消费了，但是因为我们未确认ACK，导致队列里面的消息还在。

就由指定的方法进行处理。

因为我需要MQ单独拿来测试使用，所以我新建一个分区。

当 Consumer 退出时候，Message 会一直重新分发，然后 RabbitMQ 会占用越来越多的内容，由于 RabbitMQ 会长时间运行，这个"内存泄漏"是致命的。持久化的消息在到达队列时就被写入磁盘，持久化的消息也会在内存中保存一份备份，这样可以提高一定的性能，当内存吃紧的时候会从内存中清除。Rabbit 会将持久化消息写入磁盘上的持久化日志文件，等消息被消费之后，Rabbit 会把这条消息标识为等待垃圾回收。消息内容保存在磁盘中，消息索引在磁盘和内存中都有。消息内容和索引都在磁盘中。

就是重复消费消息。

RabbitMQ服务重启，若交换机不设置持久化，交换机的元数据会丢失，消息不会丢失，不过消息再也不能发送到这个交换机中了。设置所有的消息持久化，可靠性会大大提高，可是对于性能上是一个巨大的影响，这是一个可靠性和吞吐量之间做一个权衡。RabbitMQ服务重启，若队列不设置持久化，元数据会丢失，数据也会丢失。消息可能会丢失，但不会重复。

在我们系统中有一个订单催付的场景，我们的客户在天猫下的订单，淘宝会及时将订单推送给我们，如果在用户设定的时间内未付款那么就会给用户推送一条短信提醒。但是，tmall商家对我们来说，肯定是要分大客户和小客户的，比如像苹果，小米这样大商家，理所当然，他们的订单必须得到优先处理。采用rabbitmq进行改造和优化，如果发现是大客户的订单给一个相对比较高的优先级，否则就是采用默认优先级。

上面的案例，使用定时任务，一直轮询数据，每秒查一次，取出需要被处理的数据，然后处理数据，这个方案可以吗？但是对于数据量比较大，并且时效性较强的场景，不可以使用定时任务。如果数据量比较少，确实可以这样做。

通过队列属性x-expires可以控制队列被自动删除前处于未使用状态的时间，未使用状态的时间 有如下含义。

rabbitmq

【代码】RabbitMQ--基础--10.2--死信队列。

高并发情况下，队列里面一瞬间就就积累了上万条数据，但是消费者无法同时处理这么多请求，这个时候当我们打开客户端，瞬间就有巨量的信息给推送过来、但是客户端是没有办法同时处理这么多数据的，结果就是消费者(客户端)挂掉了。Consumer2 消费了 5 条消息，但它都没有确认，由于 channel.basicQos(5, false) 的缘故，它就没再消费消息了。Consumer 消费了 15 条消息，因为它每消费一条就 ACK 一条，另外 5 条消息被另一个 Consumer2 给持有。

当发生故障导致发布出现问题时，不知道是哪个消息出现问题了，我们必须将整个批处理保存在内存中，以记录重要的信息。

为了避免这种情况发生，我们可以要求消费者在消费完消息后发送一个回执给RabbitMQ，RabbitMQ收到消息回执(Message acknowledgment)后才将该消息从Queue中移除。如果我们的开发人员在处理完业务逻辑后，忘记发送回执给RabbitMQ，这将会导致严重的问题，Queue中堆积的消息会越来越多，消费者重启后会重复消费这些消息并重复执行业务逻辑。消费者代码报错，没有收到消息，但是队列的消息少了，原因就是，MQ将异常内部消化了。

topic类型的交换机 实际上是 direct类型的交换机的一种都将消息路由到 BindingKey 和 RoutingKey 相匹配的队列中topic 在匹配规则上进行了扩展。使用了通配符工作流程消息生产者生产消息，把消息交给交换机 exchange交换机 exchange 根据 key 的规则模糊匹配到对应的队列，由队列的监听消费者接收消息消费。

Direct 模式在 Fanout 模式之上做了一个路由键 RoutingKey，对发送给交换机 Exchange 的消息进行筛选每个消费者监听自己的队列，并且设置带统配符的 routingkey生产者将消息发给broker，由交换机根据 routingkey 来转发消息到指定的队列。

交换机类型为 fanout相对于Work queues模式多了一个交换机，此处的资源是共享的一个生产者对应多个消费者。会把所有发送到该交换机的消息路由到所有与该交换机绑定的队列中，无视 BindingKey。