勤能补拙是良训,一分辛苦一分才

在前面的文章中，我们介绍了mq如何防消息丢失，从消息从生产者发送到Broker的Exchange，再到Queue，再Deliver到消费者，各个环节都有可能会丢失消息。这里我们主要模拟一下两个场景：消息未持久化丢失和消费时消息丢失。

RabbitMQ初步到精通系列目录

小结一下，我们从注解RabbitHandler RabbitListener 入手，一步步追踪到 与Broker链接的创建，Queue的声明，接着，启动新线程 注册一个内部的消费者到Broker中，Broker有消息的时候会推送到本地的BlockingQueue中去。

前面学了很多都是基于java 的AMQP client 的内容，但到实际开发中运用呢，相信没有同学直接使用amqp client 吧。所以，最终还是需要回归到java 的王者Spring，无论spring也好，还是SpringBoot 都是基于amqp client再做了一层封装而已，为的也是让大家用的爽，专注于业务。由于大家基本SpringBoot用的最多，我们也就只涉及关于SpringBoot 的整合。

总的来说，amqp的代码相对简单的，最绕的就是消费者那块了。首先是靠 MainLoop驱动，其次，将消息内容的处理方法投递到了本地 BlockingQueue中，最后，靠启动线程取出Queue中的处理方法，进行本地消费。

总的来说实现延迟队列有3种形式：1. 队列TTL2.消息TTL3. 安装延迟插件使用TTL会有限制且不通用，架构也相对复杂，但也有一些业务失效时间是明确的也可以使用。使用插件会相对简单，但有些公司，中间件是独立管理的，安装插件还需要沟通，也不一定能够同意安装。所已，还是因地制宜。适合的就是最好的!

其实死信队列没什么神秘的内容，只是：1. 在原来的基础上增加了一套死信Exchange和死信Queue2. 与原来的Queue 和死信Exchange做好了绑定关系。

有的小伙伴会说，这还是慢啊，我发条消息还得等结果，发送性能难以保证，好，提供异步的方式，先往里面发，注册一个监听，靠异步返回的形式来确认消息的确发送成功了，若收到消息会有明确的成功失败，一直收不到监听返回，也可认为发送失败了。但实际应用中呢，我们一般不采取这种方式，系统中引入mq的一个原因是想让系统处理更快，加入rabbitmq的事务后，性能急剧下降，mq失去了它原有的轻盈，快速，变成了一只老年兔子，很稳但太慢。针对一批消息的确认，虽然性能较高了，但控制就不是很精准了，使用时自己权衡。

核心点：3.1 声明Direct 类型的Exchange3.2 绑定好对应的 Queue3.3 发送消息指定

从此模式开始，我们接触到了Exchange的创建，及绑定，以及使用了Exchange的类型 Fanout。而以前我们在simple模式及work模式中，用到的默认Exchange类型都是Direct类型。

此模式我们最应该注意的就是平均模式与公平模式的实现，这里是靠消费者的手工确认机制来实现的。

这是最简单的一个模式了，一般在实际的生产环境中，大家应该都不会使用一个消费者。只做入门的介绍。一个生产者，一个默认的交换机【图中没体现】，一个队列，一个消费者。生产者产生消费发送至交换机，交换机路由至队列，队列再投递给消费者进行消费。

Simple、work、Pub/Sub、Routing、Topics、RPC、由于第6、7种我们不经常用，本文只介绍前5种模式。

MQ的控制台页面中：可以观察到此页面涉及的各个TAB，和我们前面介绍到的rabbitMQ架构中涉及的名词 都是一致的。

那rabbitmq 遵循的协议是AMQP。高级消息队列协议。它是应用层协议的一个开放标准，为面向消息的中间件设计，基于此协议的客户端与消息中间件可传递消息，并不受产品、开发语言等条件的限制。如何证明呢？

MQ全称是，消息的队列，因为是队列，所以遵循FIFO 先进先出的原则，它是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削峰等问题实现高性能，高可用，可伸缩和最终一致性架构；使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。