CYK_byte的博客

试想一个问题：当 RabbitMQ 一个集群中有 3 个节点时，我们写代码时，因该访问哪个节点呢？当然时任意一个节点都可以~如果配置文件中写死访问的是 node1，但是 node1 挂了，不就是变相的等于 mq集群 整体不可用了吗，所以最好是有一个统一的入口，一个节点故障时，流量可以及时转移到其他节点.如果所有客户端都和 node1 建立连接，那么 node1 的负担会大大增加，而其他节点的负担不大导致资源浪费.2）使用 HAProxy 就可以实现流量的负载均衡.

1）RabbitMQ 普通队列在一个节点宕机之后，其他节点无法读写宕机节点的队列，为了解决这个问题，引入了仲裁队列.2）仲裁队列通过 Raft 协议，实现了不同节点间队列消息数据的复制，使得在 创建这个队列的节点 宕机时，其他节点仍然可以使用该队列进行服务.Ps：仲裁队列时 RabbitMQ3.8 版本的重要改动，是 镜像队列 的替代方案（设计上有缺陷）. 镜像队列已被弃用，并计划在将来的版本中移除.

1）普通模式中所有节点没有主从之分，所有节点的元数据（交换机、队列、绑定等）都是一致的.例如只要有任意一个节点上面 新增交换机， 那么这个交换机的元数据也会被复制到其他节点上.2）比较特殊的是队列，队列中的消息数据只保存在创建他的节点上，其他节点只保存元数据（队列名称、配置...）和指针（指向创建该队列的节点）例如 node1 创建 cyk.queue，那么 node2 只保存 队列的元数据 和 指向 node1 节点的指针，而 cyk.queue 中的消息，只会存在于 node1 节点中。

a）消息顺序性：消费者消费的消息的顺序 和 生产者发送消息的顺序是一致的.例如 生产者 发送消息顺序是 msg1、msg2、msg3，那么消费者也需要按照 msg1、msg2、msg3 的顺序进行消费.b）顺序不一致可能会导致哪些问题？消息1：修改 用户318 的昵称为 “白天”.消息2：修改 用户318 的昵称为 “黑夜”.那么，按正常的逻辑来讲，用户318 的名称最后因该为 “黑夜”，但如果 消息1 是最后一个被消费者消费的消息，那么 用户318 的名称就变成了 “白天”.

假设 key 不存在，那么通过 setnx 操作后，就会成功设置 key，并且在这之后无论多少次调用 setnx，都不会在影响第一次调用 setnx 操作后的结果.这个方案基本上就覆盖了 90% 的应用场景. 可能网上也还有很多其他资料描述其他的方法，但基本上都是围绕 全局唯一ID 的拓展（本质的思想都一样）.假设 i 初始为 0， 第一次调用后会 i = 1，并且后面每次调用都会影响第一调用后的结果（第二次 i++ ，i 就等于 2）.因此，对于可靠性要求高的场景，建议使用。

a）TTL（Time To Live 过期时间），RabbitMQ 可以对消息和队列设置 TTL. 当消息到达存活时间之后，还没有被消费，就会被自动清除.给消息设置TTL：MQ 扫描到队列头部消息（先进先出）过期了，就会剔除消息（这里会存在一个问题：当队列头部的消息还没过期，而队列头部之后的元素过期了却不会被清理，需要等到头部元素过期被清理后，才会依次扫描后面的元素）.给队列。

消息重试机制就是在消息处理失败之后重新发送，主要时为了解决消息发送过程可能会出现的问题，例如 网络故障、服务临时不可用 等.Ps：如果时程序逻辑引起的错误，那么即使重试多少次都是没有用的，但是可以通过配置重试次数来解决.

前面讲到了 生产者消息确认机制 和 消费者消息确认机制，保证了消息传输的可靠性，但是这还不够，试想如果 Broker 突然崩溃，那么所有的 交换机、队列、消息 不就全部都没了（RabbitMQ 以内存为主，硬盘为辅，默认交换机和队列都是非持久化的）. 因此需要持久化机制.a）交换机持久化如果交换机不设置持久化，那么在 rabbitmq 服务重启之后，相关的交换机元数据就会丢失，对一个长期使用的交换机来说，建议设置成持久化的.

为了保证信息 从生产者 发送到 队列，因此引入了生产者的消息确认机制.通过事务机制实现.通过发送确认机制（confirm 和 return）实现.因为事务机制比较消耗性能，在实际工作中用的也不多，因此这里主要介绍confirm 和 return机制来实现发送放的确认.a）confirm 确认模式如上图，confirm 确认模式主要保障于 生产者 到 交换机 的消息可靠性.如果 Exchange成功收到消息，那么 ConfirmCallback 这个回调 ack 参数就为true。

为了保证消息从 队列 到 消费者正确消费，那么就引入了消费者消息确认机制.a）消费者在订阅队列时，可以指定 autoAck 参数，根据这个参数设置，消息确认机制分为以下两种（以下讲到的方法和参数来自于 RabbitMQ 原生的 SDK，非 Spring 提供）.自动确认：当 autoAck = true 时，RabbitMQ 会自动把发送出去的消息置为确认，然后不管消费者是否真正的消费这些消息，都会从内存中删除.（适合对消息可靠性要求不高的场景）.

RabbitMQ 的队列在有多个消费者订阅时，默认会通过轮询的机制将消息分发给不同的消费者，但是有些消费者消费速度慢，有些消费者消费速度快，就会导致消费速度慢的消费者影响整个的任务的吞吐量下降例如，公司有1个正式员工和1个实习生，现在有 10 个任务分配平均给他们（各 5 个），而由于实习生干活比较慢，就会导致整个完成任务的吞吐量下降.消息分发机制给 “正式工” 多分一些任务，给 “实习生” 少分一些任务.

RabbitMQ 的 AMQP 协议实现了事务机制，允许开发者保证消息的发送和接收时原子性的，也就是说，要么消息全都发送成功，要么全都发送失败（只与发送方有关）.

本篇文章来自于笔者之前写过的一个系列 —— “根据源码，模拟实现 RabbitMQ” 系列，不妨可以去看看~

a）使用 RabbitMQ 发送消息时，发送消息的类型为 Map，map 里面我 put 了一个 类型，如下图：b）这里有一个前提：我清楚使用 org.springframework.amqp.rabbit.core.RabbitTemplate 来发送消息到 RabbitMQ 队列时，消息的序列化是由 MessageConverter 完成的。

MQ），中文是消息队列，字面来看就是存放消息的队列。也就是事件驱动架构中的Broker。Ps：以下区别面试可能会考而本篇主要讲解的就是 RabbitMQ ，他是是基于Erlang使用 @Bean 注解注入即可@Bean@Bean再尝试发送数据，结果如下：Ps：注意发送方与接收方必须使用相同的MessageConverter。

MessageConverter，注入到 Spring 容器中使用 @Bean 注解注入即可@Bean@Bean再尝试发送数据，结果如下：Ps：注意发送方与接收方必须使用相同的。

什么是 AMQP?全称，是用于在应用程序之间传递业务消息的开放标准。该。什么是 SpringAMQP?Spring AMQP是基于AMQP协议定义的一套API规范，提供了模板。包含两部分，其中spring-amqp是基础抽象，spring-rabbit是底层的默认实现。

在Centos7虚拟机中使用Docker来安装。

前面我们已经解决了消息可靠性问题，以及延迟消息问题 和 消息堆积问题.这最后一章，我们就来解决以下 mq 的可用性 和 并发能力.

对于传统的队列来讲，如果没有开启消息持久化，所有接收到的消息都是放在内存里面的，目的就是为了加快消息投递的速度，这也是 RabbitMQ 的一个很优势——响应速度快.但是他也带来了一个问题，RabbitMQ 设置了一个内存预警值（内存存储的上限，默认是 40%），如果在消息堆积的情况下，很容易就到达这个预警值，此时，RabbitMQ 就会处于一个暂停状态，会阻止生产者投递消息进来，然后把内存中的一部分消息清理出来，刷出到磁盘中，这动作也叫 “page out”

想要知道什么是死信交换机，先来看看什么是死信（dead letter）~消费者使用 basic.reject 或 basic.nack 声明消费失败，并且消息的 requeue 参数设置为 false（消息不重新加入到队列中）.消息设置了过期时间，到了时间没有被消费掉.要投递的队列消息堆积满了（队列设置了最大消息数目），最早的消息可能会成为死信（LRU 算法淘汰的消息）.

4 种可靠性保证

InputStream、OutputStream、DataInputStream、DataOutputStream、RandomAccessFile、Scanner、PrintWrite

续章：自主扩展 RabbitMQ 额外功能

续章：自主扩展 RabbitMQ 额外功能之死信问题处理

续章：自主扩展 RabbitMQ 额外功能

续章：自主扩展 RabbitMQ 额外功能

续章：独立扩展 RabbitMQ 额外功能

根据源码，自己手敲一个 RabbitMQ？

根据源码，自己手敲一个 RabbitMQ？

根据源码，自己手敲一个 RabbitMQ？

根据源码，自己手敲一个 RabbitMQ？

根据源码，自己手敲一个 RabbitMQ？

根据源码，自己手敲一个 RabbitMQ？

根据源码，自己手敲一个 RabbitMQ？

通过 ByteArrayOutputStream 和 ByteArrayInputStream 实现序列化和反序列化

根据源码，自己手敲一个 RabbitMQ？

根据源码，自己手敲一个 RabbitMQ ？