amqp

一、什么是消息队列 MQ (Message Quene) : 翻译为 消息队列 ,通过典型的 ⽣产者 和 消费者 模型,⽣产者不断向消息队列中⽣产消息，消费者不断的从队列中获取消息。因为消息的⽣产和消费都是异步的，⽽且只关⼼消息的发送和接收，没有业务逻辑的侵⼊,轻松的实现系统间解耦。别名为 消息中间件 通过利⽤⾼效可靠的消息传递机制进⾏平台⽆关的数据交流，并基于数据通信来进⾏分布式系统的集成。 二、为什么要使用MQ 1.解耦 现在我有一个系统A，系统A可以产生一个userId,然后，现在有系统B和系统C都需要这个userId去做相关的操作,可以写成如下操作 如果有一天，系统B的负责人告诉系统A的负责人，现在系统B的SystemBNeed2do(String userId)这个接口不再使用了，让系统A别去调它了。那么就需要从代码的基础上去修改了。这样紧密的耦合关系会导致很多麻烦，如果使用消息中间件就不会出现以上问题。 2.异步 我们再来看看下面这种情况：系统A还是直接调用系统B、C、D 假设系统A运算出userId具体的值需要50ms，调用系统B的接口需要300ms，调用系统C的接口需要300ms，调用系统D的接口需要300ms。那么这次请求就需要50+300+300+300=950ms 并且我们得知，系统A做的是主要的业务，而系统B、C、D是非主要的业务。比如系统A处理的是订单下单

1. 消息可靠性 RabbitMQ 的消息可靠性，一般是业务系统接入消息中间件时首要考虑的问题，一般通过三个方面保障： 发送可靠性：确保消息成功发送到 Broker。 存储可靠性：Broker 对消息持久化，确保消息不会丢失。 消费可靠性：确保消息成功被消费。 1. 发送可靠性 一般消息发送可靠性分为 3 个层级： At most once：最多一次，消息可能会丢失，但绝不会重复传输。 At least once：最少一次，消息绝不会丢失，但可能会重复传输。 Exactly once：恰好一次，每条消息肯定会被传输一次且仅传输一次。 RabbitMQ 支持其中的“最多一次”和“最少一次”。 其中“最少一次”投递实现需要考虑以下这几个方面的内容： 消息生产者需要开启事务机制或者 publisher confirm 机制，以确保消息可以可靠地传输到 RabbitMQ 中。 消息生产者需要配合使用 mandatory 参数或者备份交换器来确保消息能够从交换器路由到队列中，进而能够保存下来而不被丢弃。 “最多一次”的方式无需考虑以上那些方面，生产者随意发送，不过这样很难确保消息会成功发送。 2. 消费可靠性 消费者在消费消息的同时，需要将 autoAck 设置为 false，然后通过手动确认的方式去确认已经正确消费的消息，以免在消费端引起不必要的消息丢失。 3. 代码示例 // 可靠生产

RabbitMQ简介： RabbitMQ即一个消息队列，主要是用来实现应用程序的异步和解耦。同时RabbitMQ也能起到消息缓冲，消息分发的作用。RabbitMQ使用的是AMQP（Advanced Message Queue Protocol/高级消息队列协议/）协议，它是一种二进制协议。 RabbitMQ的工作原理： RabbitMQ有4个组件，生产者（发送消息者）、Exchange、Queue队列、消费者（消息接收者）。当生产者发出消息时，会先经过Exchange，有Exchange转发给队列，然后由消息接收者消费。 消息中间件：系统间通信的。 通常使用的有：一、HTTP。二、RPC （同步请求：也就是需要服务提供者提供一个服务，需要消费者回应之后服务提供者才能去做其他事情）。 三、消息队列 （异步请求，解耦、缓冲） 异步： 也就是和同步相反。 解耦： 就是提供者和消费者之间的关系不需要紧紧相连，通过中间的消息队列即可实现解耦。 缓冲： 就是加入服务提供者提供了很多消息给消费者，这个时候如果没有消息队列就容易直接将消费者压垮掉，但是有了消息队列之后，可以直接将大量的消息传入消息队列实现了一个缓冲的作用。 这个时候又出现了一个新的消息中间件——RabbitMQ，它的愿景是取代一切其他的消息中间件。 来源： oschina 链接： https://my.oschina.net/u

RabbitMQ是目前非常热门的一款消息中间件，不管是互联网大厂还是中小企业都在大量使用。作为一名合格的开发者，有必要对RabbitMQ有所了解，本文是RabbitMQ快速入门文章，主要内容包括RabbitMQ是什么、RabbitMQ核心概念、常用交换器类型、用Docker安装RabbitMQ等。 RabbitMQ简介 以熟悉的电商场景为例，如果商品服务和订单服务是两个不同的微服务，在下单的过程中订单服务需要调用商品服务进行扣库存操作。按照传统的方式，下单过程要等到调用完毕之后才能返回下单成功，如果网络产生波动等原因使得商品服务扣库存延迟或者失败，会带来较差的用户体验，如果在高并发的场景下，这样的处理显然是不合适的，那怎么进行优化呢？这就需要消息队列登场了。 消息队列提供一个异步通信机制，消息的发送者不必一直等待到消息被成功处理才返回，而是立即返回。消息中间件负责处理网络通信，如果网络连接不可用，消息被暂存于队列当中，当网络畅通的时候在将消息转发给相应的应用程序或者服务，当然前提是这些服务订阅了该队列。如果在商品服务和订单服务之间使用消息中间件，既可以提高并发量，又降低服务之间的耦合度。 RabbitMQ就是这样一款我们苦苦追寻的消息队列。RabbitMQ是一个开源的消息代理的队列服务器，用来通过普通协议在完全不同的应用之间共享数据。 RabbitMQ是使用Erlang语言来编写的

安装 RabbitMQ 延迟队列插件 RabbitMQ 延迟队列插件未安装直接使用的话，会报错： unknown exchange type 'x-delayed-message' 插件下载地址：https://www.rabbitmq.com/community-plugins.html 。下载 Erlang 可执行文件之后，复制到rabbit服务的插件目录（自己的安装目录，我的是 C:\Program Files\RabbitMQ Server\rabbitmq_server-3.7.14\plugins ）中，然后开启插件服务： rabbitmq-plugins enable rabbitmq_delayed_message_exchange 测试步骤 创建测试项目的目录 mq 从 https://github.com/php-amqplib/php-amqplib 下载AMQP库（当然也可以通过 composer 安装，这里为了简单直接自己处理了），放入 mq 目录 编写 index.php，实现自动加载 创建 test 目录，里面分别创建 mqc.php 消费者和 mqp.php 生产者两个文件 跑脚本，测试消息的生产和消费： php -f index.php delayP p 3 生产消息，延时3秒 php -f index.php delayC c 消费消息 目录结构

在 Spring Cloud 体系的项目中，配置中心主要用于提供分布式的配置管理，其中有一个重要的注解：@RefreshScope，如果代码中需要动态刷新配置，在需要的类上加上该注解就行。本文分享一下笔者遇到与 @ConditionalOnSingleCandidate 注解冲突的问题 问题背景 项目再引入 RabbitMQ,在自定义 connectionFactory 时，手滑加上了 @RefreshScope @Bean @RefreshScope public CachingConnectionFactory connectionFactory() { CachingConnectionFactory connectionFactory = new CachingConnectionFactory(); connectionFactory.setAddresses("172.17.0.111"); connectionFactory.setUsername("guest"); connectionFactory.setPassword("guest"); connectionFactory.setVirtualHost("/"); return connectionFactory; } 系统报错无法注入 RabbitTemplate org.springframework

学习目标 会使用Spring AMQP 利用MQ实现搜索和静态页面的数据同步 1、简介 Sprin有很多不同的项目，其中就有对AMQP的支持： Spring AMQP的页面： http://projects.spring.io/spring-amqp/ 注意这里一段描述： ​ Spring-amqp是对AMQP协议的抽象实现，而spring-rabbit 是对协议的具体实现，也是目前的唯一实现。底层使用的就是RabbitMQ。 1.2.依赖和配置 添加AMQP的启动器： <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </dependency> 在 application.yml 中添加RabbitMQ地址： spring: rabbitmq: host: 192.168.56.101 username: leyou password: leyou virtual-host: /leyou 1.3.监听者 在SpringAmqp中，对消息的消费者进行了封装和抽象，一个普通的JavaBean中的普通方法，只要通过简单的注解，就可以成为一个消费者。 @Component public class Listener {

一、安装activemq（windows） 下载后解压到指定目录 http://activemq.apache.org/components/classic/download/ 配置文件D:\software\apache-activemq-5.15.9\conf 1）jetty.xml 配置控制台地址和端口： <bean id="jettyPort" class="org.apache.activemq.web.WebConsolePort" init-method="start"> <!-- the default port number for the web console --> <property name="host" value="0.0.0.0"/> <property name="port" value="8161"/> </bean> 角色： <bean id="securityConstraint" class="org.eclipse.jetty.util.security.Constraint"> <property name="name" value="BASIC" /> <property name="roles" value="user,admin" /> <!-- set authenticate=false to disable login -

RabbitMQ基础知识 一、背景 RabbitMQ是一个由erlang开发的AMQP（Advanced Message Queue ）的开源实现。AMQP 的出现其实也是应了广大人民群众的需求，虽然在同步消息通讯的世界里有很多公开标准（如 COBAR的 IIOP ，或者是 SOAP 等），但是在异步消息处理中却不是这样，只有大企业有一些商业实现（如微软的 MSMQ ，IBM 的 Websphere MQ 等），因此，在 2006 年的 6 月，Cisco 、Redhat、iMatix 等联合制定了 AMQP 的公开标准。 　　RabbitMQ是由RabbitMQ Technologies Ltd开发并且提供商业支持的。该公司在2010年4月被SpringSource（VMWare的一个部门）收购。在2013年5月被并入Pivotal。其实VMWare，Pivotal和EMC本质上是一家的。不同的是VMWare是独立上市子公司，而Pivotal是整合了EMC的某些资源，现在并没有上市。 　　RabbitMQ的官网是http://www.rabbitmq.com 花絮：本篇文章是一个系列的文章，本片是开篇，后续会陆陆续续的整理出来，我会现在我自己个人博客发表出来(www.battleheart.cn)，因为在自己的博客里面可以先修改了完善有些不对的地方，等完善后再发到博客园

1. 前言 RabbitMQ 是一个消息队列，说到消息队列，大家可能多多少少有听过，它主要的功能是用来实现应用服务的异步与解耦，同时也能起到削峰填谷、消息分发的作用。（了解源码可+求求: 1791743380） 消息队列在比较主要的一个作用是用来做应用服务的解耦，消息从消息的生产者传递到消息队列，消费者从消息队列中获取消息并进行消费，生产者不需要管是谁在消费消息，消费者也无需关注消息是由谁来生产的。在分布式的系统中，消息队列也会被用在其他地方，比如分布式事务的支持，代表如阿里开源的 RocketMQ 。 当然，我们本篇文章的主角还是 RabbitMQ 。 2. RabbitMQ 介绍 RabbitMQ 是实现 AMQP（高级消息队列协议）的消息中间件的一种，最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。 RabbitMQ 主要是为了实现系统之间的双向解耦而实现的。当生产者大量产生数据时，消费者无法快速消费，那么需要一个中间层。保存这个数据。 AMQP，即 Advanced Message Queuing Protocol，高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。AMQP 的主要特征是面向消息、队列、路由（包括点对点和发布