特殊说明： 解决问题的光鲜，藏着磕Bug的痛苦。 万物皆入轮回，谁也躲不掉！ 以上文章，均是我实际操作，写出来的笔记资料，不会出现全文盗用别人文章！烦请各位，请勿直接盗用！
看下官方说明：https://www.rabbitmq.com/tutorials/tutorial-four-java.html
reactor-rabbitmq对rabbitmq的api进行封装，改造为reactive streams模式，提供了Non-blocking Back-pressure以及End-to-end Reactive Pipeline特性。
在开发过程中，有一些消息需要不同消费者进行不同的处理，如电商网站的同一条促销信息需要短信发送、邮件发送、站内信发送等。此时可以使用发布订阅模式(Publish/Subscribe)
第一篇博文深入浅出JMS(一)–JMS基本概念，我们介绍了JMS的两种消息模型：点对点和发布订阅模型，以及消息被消费的两个方式：同步和异步，JMS编程模型的对象，最后说了JMS的优点。
之前我们已经对直连模式进行了讲解，并且用代码实现了发送端和接收端，但是发送端和接收端的代码有很多的重复的，我们就需要优化代码，提取冗余的代码为工具类。
MQ全称Message Queue（消息队列），是在消息的传输过程中保 存消息的容器。多用于系统之间的异步通信 同步通信相当于两个人当面对话，你一言我一语。必须及时回复。
之前我们写生产者消费者模型的时候，会有很多冗余代码，比如生产者和消费者都需要创建连接工厂、设置连接配置、以及关闭资源等操作。
（1）创建工程springjms_producer，在POM文件中引入SpringJms 、activeMQ以及单元测试相关依赖
work queues 与入门程序的 简单模式 相比，多了一个或一些消费端，多个消费端共同消费同一个队列中的消息。 应用场景：对于任务过重或任务较多情况使用工作队列可以提高任务处理的速度。
官网说：在这一部分中，我们将做一些完全不同的事情-我们将消息传达给多个消费者。这种模式称为“发布/订阅”。
RabbitMQ的特性是保障数据的一致性，稳定性和可靠性。但是如何来保障这些了？这就有了很多的保障机制。在前面的文章体系中也是介绍到RabbitMQ中的生产者负责把消息发送到Exchange，并不需要关心Queue是什么，那么问题就出现了，如果生产者发送的MQ消息消费者没有收到了？这如何可以做到前面说的数据的一致性以及可靠性了。我们可以结合现实的例子来看这部分，比如我向别人借了100元，然后我要了对方的银行卡号，把钱还给了对方，但是我给对方没有说，那么其实对方是不知道的，所以在对方的心理我始终还是欠他100元的，其实这样的案例在我实际的生活就出现过，当然是很多年前的事了，总是这过程确认反馈的机制。技术也是需要符合人性的，那么RabbitMQ为了做到数据的一致性的保障，在生产者端就有Confirm的确认机制。
继上两期的ActiveMQ的概念原理和经典示例之后，本期将隆重推出ActiveMQ是如何与SpringMVC进行集成使用的。 老规矩，在开始之前，先来点与之相关的干货。 — 常见协议 — 物理层 以太网·调制解调器·电力线通信(PLC)·SONET/SDH · 光导纤维等 数据链路层 Wi-Fi(IEEE 802.11) · ATM · DTM · 令牌环·以太网· GPRS · HDLC · PPP · L2TP ·PPTP ·STP 等 网络层协议 IP (IPv4 · IPv6) ·
mysql应该是我们在日常工作中使用到的一个非常普遍的数据库，虽然mysql现在是oracle公司的，但是它是开源的，市场占有率还是非常高的。
RabbitMQ的重回队列解决了RabbitMQ由于异常情况导致消息收不到的原因，但是一般在企业不怎么实用重回队列，更多使用的是死信队列的机制，这样来保障消费端能够接收到具体的消息，其实本质上都是为了消息消费者这层的可靠性的保障机制。
之前我们使用rabbitMq 网页客户端 开放了 15672 的端口，要想是的 java客户端访问服务器成功，需要开放 5672 的端口号。在服务器安全组设置
快速入门：消息的生产者和消费者 生产者的代码步骤： 1：获取到连接的工厂 ConnectionFactory 2：从工厂中获取到一个连接：connection 3：重建一个数据通信的通道，可以发送和接收消息对象：channel 4：通过channel发送消息 5：关闭流 代码编写： public class Procuder { public static void main(String[] args) throws IOException, TimeoutException {
channel.basicConsume(queueName,true,consumer);中的true为收到消息后自动确认，改为false取消自动确认。
1、假设写错了host （如：factory.setHost(“locathost”); ）报错：
工作队列模式就是一个生产者，两个消费者。在初步入门的Hello World简单模式里面我们了解到。简单模式就是一个生产者一个消费者，中间通过中间件进行消息通信。
声明：本系列文章是根据b站狂神课进行 学习记录。原b站链接：https://www.bilibili.com/video/BV1dX4y1V73G?p=12，侵权删。
AMQP协议（Advanced Message Queuing Protrocol） -- 高级消息队列协议、应用层
ActiveMQ的延时消息是一个让人又爱又恨的功能，具体使用可参考上篇ActiveMQ笔记(6)：消息延时投递，在很多需要消息延时投递的业务场景十分有用，但是也有一个缺陷，在一些大访问量的场景，如果瞬间向MQ发送海量的延时消息，超过MQ的调度能力，就会造成很多消息到了该投递的时刻，却没有投递出去，形成积压，一直停留在ActiveMQ web控制台的Scheduled面板中。 下面的代码演示了，如何清理activemq中的延时消息（包括：全部清空及清空指定时间段的延时消息），这也是目前唯一可行的办法。 为了演
安装插件后会生成新的Exchange类型x-delayed-message，该类型消息支持延迟投递机制,接收到消息后并未立即将消息投递至目标队列中，而是存储在mnesia(一个分布式数据系统)表中，并且当前节点是磁盘节点，那么节点重启后，消息还能保留。检测消息延迟时间，如达到可投递时间时并将其通过x-delayed-type类型标记的交换机类型投递至目标队列。但是要注意的是，如果集群中只有一个磁盘节点，如果说磁盘节点丢失，或者节点上的插件失效。意味着消息将会丢失。
RabbitMQ共有六种工作模式：简单模式（Simple）、工作队列模式（Work Queue）、发布订阅模（Publish/Subscribe）、路由模式（Routing）、通配符模式（Topics）、远程调用模式（RPC，不常用，课程不对此模式进行讲解)
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
spring-boot-actuator-2.0.4.RELEASE-sources.jar!/org/springframework/boot/actuate/redis/RedisHealthIndicator.java
Spring Cloud Bus 可以与多种消息代理一起使用，例如 RabbitMQ 和 Kafka。在本节中，我们将介绍如何使用 Spring Cloud Bus 集成 RabbitMQ。
安装RabbitMQ 延迟交换机 在三台节点上安装延迟交换机插件 1.进入RabbitMQ 插件目录
红色 Queue：绑定的是 usa.# ，因此凡是以 usa. 开头的 routing key 都会被匹配到 黄色 Queue：绑定的是 #.news ，因此凡是以 .news 结尾的 routing key 都会被匹配,
在实际开发中，很多场景需要异步处理，这时就需要用到RabbitMQ，而且随着场景的增多程序可能需要连接多个RabbitMQ。SpringBoot本身提供了默认的配置可以快速配置连接RabbitMQ，但是只能连接一个RabbitMQ，当需要连接多个RabbitMQ时，默认的配置就不太适用了，需要单独编写每个连接。
出处：www.cnblogs.com/haixiang/p/10864339.html
在RabbitMQ的生产端把消息发送到Exchange后，然后Exchange与Queue来建立映射关系从而保障消费端能够接收到消息，保障在业务端的消息可靠性，这是正常情况的一种逻辑思维。在异常的情况下，消息到队列中消费端并不能够收到消息，那么就需要重试的机制，也就是重回队列的机制。其实重试的机制在服务端的业务保障性体系中是必须需要考虑的，因为总有特殊的情况导致发送的请求在请求方并没有收到请求，比如服务这层出现TimeOut，以及连接数出现瓶颈，那么这个时候整体程序的瓶颈是在服务这层，那么既然涉及到重试的机制，一般重试是几次了？另外需要思考的是重试的间隔是需要多少秒之间？其实重试的间隔以及重试的次数就需要和具体技术的负责人根据业务的形态来进行考虑，这中间也是需要考虑到幂等性的问题。但是作为服务端质量体系保障的一个部分，质量负责人以及对应测试这部分的同学必须得有这个技术底蕴和测试场景的意识，需要更加系统宏观的站在全局的角度来考虑服务这层重试以及不重试给产品带来的风险管控。当然，在本文章体系中重点核心探讨的是RabbitMQ的重回队列的机制应用。
一些常量定义： /** * @Auther: ZhangShenao * @Date: 2019/1/6 16:26 * @Description: */ public interface Constants { String BROKER_URL = "nio://localhost:61617"; String QUEUE_NAME = "Test-Queue"; String TOPIC_NAME = "Test-Topic"; String CONSUMER_
死信队列是指队列上的消息变成死信后，能够后发送到另外一个交换机，这个交换机 就是 DLX 。
ActiveMQ 是 Apache 提供的一个开源的消息系统，很好地支持了 JMS 规范。在使用ActiveMQ 时需要在 pom 文件中引入 spring-boot-starter-activemq。
RabbitMQ通配符模式，也被称为主题模式（Topic Pattern），是一种消息传递模式，它允许消息生产者将消息发送到一个交换机（exchange），并使用通配符形式的路由键来描述消息的特性。消费者则可以使用通配符匹配来订阅感兴趣的消息。
这个模式和之前的相比还是有一点的变化，我们还是去官网去看这个模型图。首先是必要的生产者和消费者，中间的X代表交换机，这里我们会用到交换机，然后这里有两个队列，然后在分发给两个消费者。
与简单模式相比，工作队列模式(Work Queue)多了一些消费者，该模式也使用direct交换机，应用于处理消息较多的情况。特点如下：
JMS即Java Message Service，Java消息服务。主要用于在生产者和消费者之间进行消息传递，生产者负责产生消息，而消费者负责接收消息。
如果将Spring Boot应用程序打包为 war 或 ear 文件并将其部署到Java EE应用程序服务器，则可以使用应用程序服务器的内置事务管理器。
前面一篇介绍了使用工厂方式创建消费者，其中一个不太友好的地方就在配置都是硬编码的方式，不太灵活，那么是否可以结合前一篇的FactoryBean来实现从配置中来灵活的创建消费者呢？
1. 下载 ActiveMQ , 到 activemq 官网上下载 Windows 或者 Linux 对应的安装包
之前已经利用代码，将一些数据放到了队列里面，现在我们要实现利用代码从队列里面拿出数据。
JMS的全称是Java Message Service，即Java消息服务。它主要用于在生产者和消费者之间进行消息传递，生产者负责产生消息，而消费者负责接收消息。把它应用到实际的业务需求中的话我们可以在特定的时候利用生产者生成一消息，并进行发送，对应的消费者在接收到对应的消息后去完成对应的业务逻辑。对于消息的传递有两种类型，一种是点对点的，即一个生产者和一个消费者一一对应；另一种是发布/订阅模式，即一个生产者产生消息并进行发送后，可以由多个消费者进行接收。
先以 java 应用程序的方式连接 RabbitMQ ，后期再考虑与 Spring Boot 整合工作。
在服务级级别的测试中需要考虑被执行任务的优先级机制，也就是通过线程优先级来进行，设置优先级的目的是在资源非常紧张的情况下，让优先级高的任务优先执行，而优先级低的任务排后执行，当然这样的一种设置机制只能是异步的模式下执行，如果是设计在同步的模式下执行，那这个设计从系统上来说就缺少宏观维度的思考。在RabbitMQ的机制中也是提供了队列的优先级机制，这样设计的目的也是在在生产者生产过快，而消费者消费不过来的情况下，也就是资源在紧张或者说是在有限的情况下，设置的队列优先级高的任务它的消息优先进行消费，而优先级低的消息排后消费。当然，如果是在资源不紧张的情况下，设置优先级其实没多大的意义，因为这个时候优先过来的消息先进行消费，也谈不上排队的机制和优先级的机制。
路由的这种模式和发布订阅的模式相比多了一个路由的环节。要求队列在绑定在绑定到交换机的时候指定到对应的路由。路由的作用是什么呢？作为一种分发的规则。可以按照相应的条件指定和分发。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
