本系列教程主要针对使用java语言进行Rabbitmq的相关编程。阅读前请确认已经安装过rabbit服务。关于如何安装rabbitmq，请参考如何使用rabbitmq.
RabbitMQ 是一套开源（MPL）的消息队列服务软件，是由 LShift 提供的一个 Advanced Message Queuing Protocol (AMQP) 的开源实现，由以高性能、健壮以及可伸缩性出名的 Erlang 写成。
RabbitMQ 是一个消息代理。这主要的原理十分简单，就是通过接受和转发消息。你可以把它想象成邮局：当你将一个包裹送到邮局，你会相信邮递员先生最终会将邮件送到接件人手上。RabbitMQ就好比一个邮箱，邮局或邮递员。
要解决该问题，就要用到RabbitMQ中持久化的概念，所谓持久化，就是RabbitMQ会将内存中的数据(Exchange 交换器，Queue 队列，Message 消息)固化到磁盘，以防异常情况发生时，数据丢失。
Spring Cloud Bus致力于提供分布式消息总线的功能。目前，Spring Cloud Bus支持使用AMQP协议（如Kafka、Rabbit等）消息代理作为通道。
国外的营销触达通道比较单一，主要以EDM为主。国内因为渠道的变化营销场景就复杂很多，当前国内做用户的营销触达主要的场景通道都有哪些。
一、 微服务系统中有多个服务应用，也会有多个配置文件。此时也可用 springcloud bus 来实现对配置文件的管理。
Github上下载jhipster-jhipster源码。 https://github.com/jhipster/jhipster-registry/releases
我们通常会使用消息代理来构建一个主题，然后把微服务架构中的所有服务都连接到这个主题上去，当我们向该主题发送消息时，所有订阅该主题的服务都会收到消息并进行消费。使用 Spring Cloud Bus 可以方便地构建起这套机制，所以 Spring Cloud Bus 又被称为消息总线。Spring Cloud Bus 配合 Spring Cloud Config 使用可以实现配置的动态刷新。目前 Spring Cloud Bus 支持两种消息代理：RabbitMQ 和 Kafka，下面以 RabbitMQ 为例来演示下使用Spring Cloud Bus 动态刷新配置的功能。
本系列教程主要针对使用Java语言进行Rabbitmq的相关编程。阅读前请确认已经安装过rabbit服务。关于如何安装rabbitmq，请参考如何使用rabbitmq.
> 公众号：[Java小咖秀](https://t.1yb.co/jwkk)，网站：[javaxks.com](https://www.javaxks.com)
作者 | 我思知我在 来源 | https://blog.csdn.net/qq_32828253/article/details/110450249 七种模式介绍与应用场景 简单模式（Hello World） 如何设计 QQ、微信、微博、Github 等第三方账号登陆 ？（附表设计） 做最简单的事情，一个生产者对应一个消费者，RabbitMQ相当于一个消息代理，负责将A的消息转发给B 应用场景： 将发送的电子邮件放到消息队列，然后邮件服务在队列中获取邮件并发送给收件人 工作队列模式（Work queu
其实，还有1种场景需要考虑：当消费者接收到消息后，还没处理完业务逻辑，消费者挂掉了，那消息也算丢失了？，比如用户下单，订单中心发送了1个消息到RabbitMQ里的队列，积分中心收到这个消息，准备给这个下单的用户增加20积分，但积分还没增加成功呢，积分中心自己挂掉了，导致数据出现问题。
RabbitMQ是一个消息中间件：它接收并转发消息。您可以把它想象为一个邮局：当您把需要寄出的邮件投递到邮箱，邮差最终会把邮件送给您的收件人。在这个比喻中，RabbitMQ就是一个邮箱，也可以理解成邮局和邮递员。
在之前的一篇博客RabbitMQ入门：认识并安装RabbitMQ（以Windows系统为例）中，我们安装了RabbitMQ并且对其也有的初步的认识，今天就来写个入门小例子来加深概念理解并了解代码怎么实现。
2、cms 页面发布接口执行页面静态化，并将静态化页面(html文件)存储至GridFS中。
作为主流的MQ消息队列中间件，RabbitMQ也是具备了生产者消费者的模型，那么也就是说生产者把消息发送后，消费者来作为接收具体的消息。本文章主要详细的概述RabbitMQ的生产者投递和消费者监听。
在 RabbitMQ 中，交换机有四种类型：Direct、Fanout、Topic 和 Headers。每种交换机类型都有不同的路由规则，可以更好地满足不同应用场景的需求。
1、假设写错了host （如：factory.setHost(“locathost”); ）报错：
在微服务架构中，为了更方便的向微服务实例广播消息，我们通常会构建一个消息中心，让所有的服务实例都连接上来，而该消息中心所发布的消息都会被微服务实例监听和消费，我们把这种机制叫做消息总线(SpringCloud Bus)
Dapr 是一个可移植的、事件驱动的运行时，它使任何开发人员能够轻松构建出弹性的、无状态和有状态的应用程序，并可运行在云平台或边缘计算中，它同时也支持多种编程语言和开发框架。Dapr 确保开发人员专注于编写业务逻辑，不必分神解决分布式系统难题，从而显著提高了生产力。Dapr 降低了构建微服务架构类现代云原生应用的门槛。
amqp是一种通用的消息队列数据传输协议，典型的MQ应用RabbitMQ就实现了amqp协议，所以，我们在使用amqp-client链接rabbitmq时，可以使用amqp的链接协议连接rabbitmq。但是博主在尝试使用amqp协议链接时，碰到了一个隐藏的连接协议规范问题，故记录在此。
RabbitMQ无疑是目前最流行的消息队列之一，对各种语言环境的支持也很丰富，作为一个.NET developer有必要学习和了解这一工具。消息队列的使用场景大概有3种：
Channel channel.exchangeDeclare()： type：有direct、fanout、topic三种 durable：true、false true：服务器重启会保留下来Exchange。警告：仅设置此选项，不代表消息持久化。 即不保证重启后消息还在。原文：true if we are declaring a durable exchange (the exchange will survive a server restart) autoDelete:true、false.tru
RabbitMQ是一个消息队列，它能够接收和转发消息。这个过程就像寄快递一样，把物件打包给快递小哥，快递小哥会负责把物件派送到正确的地址。
微服务架构是一个分布式架构，微服务系统按业务划分服务单元，一个微服务系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性较高，如果出现了错误和异常，很难去定位。主要体现在一个请求可能需要调用很多个服务，而内部服务的调用复杂性决定了问题难以定位。所以在微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题能够快速定位的目的。
本次结合着B站某MQ视频以及最近在MQ上的实践聊一聊个人在使用rabbitMQ中所得。
做最简单的事情，一个生产者对应一个消费者，RabbitMQ相当于一个消息代理，负责将A的消息转发给B 应用场景： 将发送的电子邮件放到消息队列，然后邮件服务在队列中获取邮件并发送给收件人 工作队列模式（Work queues）
RabbitMQ是一个消息队列，我们可以使用RabbitMQ 做消息队列，消息通知的业务功能，而且根据网上的不可靠消息得出，RabbitMQ 的性能水平甚至比 activeMQ 还要好，所以也是我选择认真去学习RabbitMQ的原因，当然我也有做个关于 activeMQ 的一些简单的 Demo 有机会的话可以分享出来~
RabbitMQ是开源的消息中间件，它是轻量级的，支持多种消息传递协议，可以部署在分布式和联合配置中，以满足高级别、高可用性需求。并且可在许多操作系统和云环境上运行，并为大多数流行语言提供了广泛的开发工具。（这里只介绍JAVA下的RabbitMQ的使用，感兴趣的可以查看官方文档：http://www.rabbitmq.com/getstarted.html）；
随着业务越来越复杂，系统也随之进行各种拆分，特别是随着微服务架构的兴起，看似一个简单的应用，后台可能很多服务在支撑；一个请求可能需要多个服务的调用；当请求迟缓或不可用时，无法得知是哪个微服务引起的，这时就需要解决如何快速定位服务故障点，Zipkin 分布式跟踪系统就能很好的解决这样的问题。
MQTT（Message Queuing Telemetry Transport，消息队列遥测传输协议），是一种基于发布/订阅（publish/subscribe）模式的轻量级通讯协议，该协议构建于TCP/IP协议上。MQTT最大优点在于，可以以极少的代码和有限的带宽，为连接远程设备提供实时可靠的消息服务。
MQ（Message Quene）：翻译为消息队列，通过典型的生产者和消费者模型，生产者不断向消息队列中生产消息，消费者不断的从队列中获取消息。因为消息的生产和消费都是异步的，而且只关心消息的发送和接收，没有业务逻辑的侵入，轻松的实现系统间解耦。别名为消息中间件通过利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。
参考网站： http://blog.chinaunix.net/topic/surpershi/ http://blog.csdn.net/lwkcn/article/details/25086467 http://snoopyxdy.blog.163.com/blog/static/60117440201352615631930/
安装RabbitMQ 延迟交换机 在三台节点上安装延迟交换机插件 1.进入RabbitMQ 插件目录
RabbitMQ远程调用测试，使用外部机器192.168.174.132上的RabbitMQ，使用之前需要对远程调用进行配置，操作过程见另一篇“解决RabbitMQ远程不能访问的问题” http://www.linuxidc.com/Linux/2014-10/107917.htm 。
将阿里云同一个VPC下的RabbitMQ集群的消息从一个网段集群迁移到另一个网段集群。消息中间件的消息是即时消费，为何还有历史消息，因为是历史遗留问题。故要迁移
安装插件后会生成新的Exchange类型x-delayed-message，该类型消息支持延迟投递机制,接收到消息后并未立即将消息投递至目标队列中，而是存储在mnesia(一个分布式数据系统)表中，并且当前节点是磁盘节点，那么节点重启后，消息还能保留。检测消息延迟时间，如达到可投递时间时并将其通过x-delayed-type类型标记的交换机类型投递至目标队列。但是要注意的是，如果集群中只有一个磁盘节点，如果说磁盘节点丢失，或者节点上的插件失效。意味着消息将会丢失。
本文基于docker来安装RabbitMQ，通过pull当前最新版本rabbitmq:3.8.5-management即可，之后通过如下的命令即可运行：
官方安装指南：https://www.rabbitmq.com/install-rpm.html
在服务级级别的测试中需要考虑被执行任务的优先级机制，也就是通过线程优先级来进行，设置优先级的目的是在资源非常紧张的情况下，让优先级高的任务优先执行，而优先级低的任务排后执行，当然这样的一种设置机制只能是异步的模式下执行，如果是设计在同步的模式下执行，那这个设计从系统上来说就缺少宏观维度的思考。在RabbitMQ的机制中也是提供了队列的优先级机制，这样设计的目的也是在在生产者生产过快，而消费者消费不过来的情况下，也就是资源在紧张或者说是在有限的情况下，设置的队列优先级高的任务它的消息优先进行消费，而优先级低的消息排后消费。当然，如果是在资源不紧张的情况下，设置优先级其实没多大的意义，因为这个时候优先过来的消息先进行消费，也谈不上排队的机制和优先级的机制。
RabbitMQ的重回队列解决了RabbitMQ由于异常情况导致消息收不到的原因，但是一般在企业不怎么实用重回队列，更多使用的是死信队列的机制，这样来保障消费端能够接收到具体的消息，其实本质上都是为了消息消费者这层的可靠性的保障机制。
SpringCloudBus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。 在上一篇写出了springcloud对微服务的集中配置，那么就出现了一个问题，如果修改配置了怎么实现不需重启服务来实现配置的更新，下面有集中解决方法。 1.使用/refresh手动刷新配置 缺点：单点刷新，如果集群服务多的话，无论是工作量还是维护上都十分麻烦。 使用上一篇的config-client服务，加入依赖， spring-boot-starter-
2、Queue：队列，rabbitmq的内部对象，用于存储消息，其属性类似于Exchange，同样可以设置是否持久化、自动删除等。 消费者重Queue中获取消息并消费。多个消费者可以订阅同一个Queue，这时Queue中的消息会被平均分摊给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理。
最简单的一个消费者和一个生产者模式，生产者生成消息，消费者监听消息，若是消费者监听到它所需要的消息，就会消费该消息，这种消息是次性的，被消费了就没有了。
RabbitMQ 支持多种语言访问，以 Java 为例看下一般使用 RabbitMQ 的步骤。
在RabbitMQ的生产端把消息发送到Exchange后，然后Exchange与Queue来建立映射关系从而保障消费端能够接收到消息，保障在业务端的消息可靠性，这是正常情况的一种逻辑思维。在异常的情况下，消息到队列中消费端并不能够收到消息，那么就需要重试的机制，也就是重回队列的机制。其实重试的机制在服务端的业务保障性体系中是必须需要考虑的，因为总有特殊的情况导致发送的请求在请求方并没有收到请求，比如服务这层出现TimeOut，以及连接数出现瓶颈，那么这个时候整体程序的瓶颈是在服务这层，那么既然涉及到重试的机制，一般重试是几次了？另外需要思考的是重试的间隔是需要多少秒之间？其实重试的间隔以及重试的次数就需要和具体技术的负责人根据业务的形态来进行考虑，这中间也是需要考虑到幂等性的问题。但是作为服务端质量体系保障的一个部分，质量负责人以及对应测试这部分的同学必须得有这个技术底蕴和测试场景的意识，需要更加系统宏观的站在全局的角度来考虑服务这层重试以及不重试给产品带来的风险管控。当然，在本文章体系中重点核心探讨的是RabbitMQ的重回队列的机制应用。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
