Fanout

RabbitMQ 1. RabbitMQ的使用场景有哪些？ 抢购活动，削峰填谷，防止系统崩塌。 延迟信息处理，比如10分钟之后给下单未付款的用户发送邮件提醒。解耦系统，对于新增的功能可以单独写模块扩展，比如用户确认评价之后，新增了给用户返积分的功能，这个时候不用在业务代码里添加新增积分的功能，只需要把新增积分的接口订阅确认评价的消息队列即可，后面再添加任何功能只需要订阅对应的消息队列即可。 2. RabbitMQ有哪些重要的角色？ RabbitMQ中重要的角色有：生产者、消费者和代理： [图片上传失败...(image-40f1e0-1604821335945)] 生产者：消息的创建者，负责创建和推送数据到消息服务器； 消费者：消息的接收方，用于处理数据和确认消息； 代理：就是RabbitMQ本身，用于扮演“快递”的角色，本身不生产消息，只是扮演“快递”的角色。 3. RabbitMQ有哪些重要的组件？ ConnectionFactory（连接管理器）：应用程序与Rabbit之间建立连接的管理器，程序代码中使用。 Channel（信道）：消息推送使用的通道。 Exchange（交换器）：用于接受、分配消息。 Queue（队列）：用于存储生产者的消息。 RoutingKey（路由键）：用于把生成者的数据分配到交换器上。 BindingKey（绑定键）：用于把交换器的消息绑定到队列上。

六种工作模式 官网介绍：https://www.rabbitmq.com/getstarted.html 简单模式：一个生产者，一个消费者 work模式：一个生产者，多个消费者，每个消费者获取到的消息唯一。 订阅模式：一个生产者发送的消息会被多个消费者获取。 路由模式：发送消息到交换机并且要指定路由key ，消费者将队列绑定到交换机时需要指定路由key topic模式：将路由键和某模式进行匹配，此时队列需要绑定在一个模式上，“#”匹配一个词或多个词，“ *”只匹配一个词。 简单模式/work模式 Channel channel = rabbitTemplate.getConnectionFactory().createConnection().createChannel( false ); channel.queueDeclare("yangsimple", false , false , false , null ); channel.basicPublish( "", "yangsimple", null , "simple message" .getBytes()); System.out.println( "basic publish" ); channel.close(); 订阅模式/路由模式 // 生产者 Connection connection =

​ 写在前面：全文12000多 字，从为什么需要用消息队列，到rabbitMQ安装使用，如何使用 JavaAPI生产消费消息，以及使用消息队列带来的一些常见问题。绝对很适合新手入门学习。 为什么需要消息队列 异步处理 削峰限流 秒杀活动，一般会因为流量过大，导致应用挂掉。加入消息队列可控制活动人数，缓解短时间的高流量。 应用解耦 双十一购物节，订单系统需要通知库存系统，传统做法是订单系统直接调用库存系统的接口，库存系统出现故障时订单就会失败。可在订单系统和库存系统中间加一个MQ，达到应用解耦的需求。 A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃...... 日志处理 消息队列有哪些 Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？ 特性 ActiveMQ RabbitMQ RocketMQ Kafka 单机吞吐量 万级，比 RocketMQ、Kafka 低一个数量级 同 ActiveMQ 10 万级，支撑高吞吐 10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景 topic 数量对吞吐量的影响 topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的

一般而言，如果你选择RabbitMQ，那肯定就是把可靠性放在第一位。毕竟，RabbitMQ可是金融行业消息队列的标配。如果把性能放在第一位，那毫无疑问，必须是Kafka。但是，可靠性毕竟是相对的，就拿大火的阿里云，AWS云，或者传统的IBM小型机，Oracle数据库，没有谁敢说自己可靠性100%，都是说几个9。所以，本文的目的很明确，就是尽可能的提高我们RabbitMQ的可靠性，从发送、存储、消费、集群、监控、告警等多个维度给出可行性方案，指导开发者以及运维人员获取更加可靠的消息投递，保障我们的业务系统安全、可靠、稳定的运行。 数据可靠性是和RabbitMQ节点、生产者、消费者以及服务器等息息相关的。本文比较长，大概分为如下几个段落： 确认机制 生产者 消费者 队列镜像 告警 监控和Metrics 健康检查 如下是一张RabbitMQ架构图，本文对可靠性的分析，会涉及到架构图中的方方面面： 1. 确认机制 当连接出现问题的时候，在客户端和服务端之间的消息可能正在投递中，还没有被Broker接收，它们可能正在被编码或者解码，或者一些其他的情况。在这种场景下，消息并没有被投递，那么它们是需要被重新投递以保障业务稳定性。确认机制让服务端和客户端知道什么时候需要做这些事情，它对于生产者和消费者保障数据安全是非常重要的。 确认机制能被用在两个方向：允许消费者告诉服务器（Broker

关于 MQ 的定义 Message Queue （ MQ ）消息队列中间件，通常我们在网上看到的对其定义是将消息的发送和接受分离来实现应用程序的异步和解耦，给人的直觉是 MQ 是异步的，用来解耦的。但这个只是 MQ 的效果，而不是目的。 MQ 真正的目的是为了通讯，屏蔽底层复杂的通讯协议，定义了一套应用层上更加简单的通讯协议。 一套分布式系统中两个模块之间通讯要么是 HTTP ，要么是 TCP ，但这两种协议其实都是原始的协议。前者实现通讯就必须要做到各客户端都有 WebServer ，而且不支持长连接；后者就更加原始了 — 粘包、心跳、私有的协议。 而 MQ 所要做就是在基于这些现有的协议之上构建一个更简单的通讯（生产者/消费者）模型。它定义了两个对象 —发送数据的叫生产者，接受数据的叫消费者，提供一个 SDK 给我们自己定义生产者和消费者实现消息通讯，且无视底层通讯协议。 带 Broker 的流派 这个流派通常有一台服务器作为 Broker ，所有的消息都通过它进行中转。生产者把消息发送给它就结束自己的任务了，最后 Broker 则把消息主动推送给消费者（或者消费者主动轮询）。 重 Topic 的 MQ Kafka 、 Active MQ 就属于这个流派：生产者发送 key 和数据到 Broker ，由 Broker 比较 key 之后决定给哪个消费者。 在这种模式下，

前几篇我们介绍了如果通过RabbitMQ发布一个简单的消息，再到工作队列，多个消费者进行消费，最后再到工作队列的分发与消息的应答机制（ACK）； 之前我们分享的这几种模式,都是被消费之后就从队列中被删除了,理想状态下不会被重复消费,试想我们另外一种场景,比如我之前做的小说业务,用户在登录成功后,需要将临时账户的金币和书架的书籍信息同步到正式账户。 如果我们跟登录融合在一块，登录成功之后，如果用户账户或者书架同步失败，那么势必影响我们整个登录的体验。为了更好地做到用户无感知，不需要用户做更多的操作，那么我们就使用消息队列的方式，来进行异步同步。 发布订阅模式 这就是我们一个用户数据同步的流程图，也是RabbitMQ发布订阅的流程图，大家可能注意到了中间怎么多了一个 交换机 。 这里要注意，使用发布订阅模式，这里必须将交换机与队列进行绑定，如果不绑定，直接发送消息，这个消息是不会发送到任何队列的，更不会被消费。 交换机种类 交换机总共分四种类型：分别是direct、topic、headers、fanout。这次我们主要讲fanout，因为这是我们本次需要用到的交换机类型。 fanout顾名思义就是广播模式。它会把消息推送给所有订阅它的队列。 代码 生产者 public class Send { /** * 交换机名称 */ private final static String

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 说到消息中间件，大部分人的第一印象可能是Kafka。毕竟Kafka自问世以来，就顶着高并发，大流量的光环。当然了Kafka也不负众望，在大数据处理方面一直独领风骚。 这里想说说另一款同样优秀的消息中间件RabbitMQ。 选RabbitMQ还是Kafka 如果单机数据量没有到十万级以上，我觉得选哪个都OK，如果超过百万甚至到了千万级那么建议选择Kafka。 对了还有重要的一点，RabbitMQ支持事务，而Kafka不支持。所以如果你的业务系统要求支持事务，那么只能选RabbitMQ。这也是很多金融系统选择RabbitMQ作为消息中间件的原因。 RabbitMQ基本概念 先来说一下消息中间件的通用模型，所有的消息中间件的模型基本都是这样。 而RabbitMQ是基于AMQP协议实现的。模型大概是这个样子，如下图所示 重点关注中间两个框框，下面依次解读一下。 信道 建立TCP链接是一件很费时的事情，所以很多提供高并发服务的软件都支持TCP链接复用，比如HTTP协议的KeepAlive就是为了复用TCP链接准备的。所以RabbitMQ提出了信道的概念，一个TCP链接里面可以支持多个信道同时通信，以提高通信效率。如下图所示。 broker 一个启动的RabbitMQ实例

目录 一、simple模式 simple模式实现-生产者 simple模式实现-消费者 二、work模式（能者多劳模式） work模式实现-生产者 work模式实现-消费者 三、订阅模式-fanout fanout模式实现-生产者 fanout模式实现-消费者 四、订阅模式-direct direct模式实现-生产者 direct模式实现-消费者 五、订阅模式-topic topic模式实现-生产者 topic模式实现-消费者 六、 订阅模式-headers 七、RPC 一、simple模式 即简单的点对点消息模型。开启mq服务，开启进程P 生产者向mq 写消息，进程C消费者监听mq，消费消息。 simple模式实现-生产者 simple模式实现-消费者 二、work模式（能者多劳模式） 一个生产者P，对应了多个消费者C。这些多个C，消费的消息各自不同，C1和C2 消费的消息，构成所有消息的一个全集。可开启C的消费竞争 channel.basicQos(1);C1和C2 能者多劳。 work模式实现-生产者 work模式实现-消费者 三、订阅模式-fanout 订阅模式中会用到交换机。根据交换机类型的不同，订阅模式的效果也会有所不同。 所有发送到该交换器的消息全部发送到其对应的队列中 fanout模式实现-生产者 fanout模式实现-消费者 四、订阅模式-direct

消息中间件简介 MQ全称（Message Queue）`又名消息队列，是一种异步通讯的中间件。 可以将它理解成邮局，发送者将消息传递到邮局，然后由邮局帮我们发送给具体的消息接收者（消费者），具体发送过程与时间我们无需关心，它也不会干扰我进行其它事情。常见的MQ有 kafka 、 activemq 、 rocketMQ 、 rabbitmq 等等** 消息中间件的应用场景 跨系统数据传递、高并发流量削峰、数据异步处理。。。。 消息中间件对比 综上，各种对比之后，有如下建议： 一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了； 后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高； 不过现在确实越来越多的公司会去用 RocketMQ，确实很不错，毕竟是阿里出品，但社区可能有突然黄掉的风险（目前 RocketMQ 已捐给 Apache ，但 GitHub 上的活跃度其实不算高）对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。 所以

RabbitMQ Exchange类型： Direct交换机：完全按照Key进行投递 Topic交换机：对Key进行模式匹配后进行投递： *匹配一个词，#匹配一个或多个词 Fanout交换机：不需要key，通过广播模式，将消息投递到该交换机绑定的所有队列 Headers交换机： 根据消息头部决定队列消息分发 1. Direct Exchange: 默认交换机 /** * Direct 交换机：完全按照RouteKey进行消息投递(默认交换机) * @author zhiwei_yang * @time 2020-8-4-9:45 */ @Slf4j public class DirectExchange { private final static String QUEUE_NAME = "DIRECT_EXCHANGE_QUEUE"; private final static String ROUTE_KEY = QUEUE_NAME; private final static String EXCHANGE_NAME = "DirectExchange"; public static void main(String[] argv) throws Exception { //创建连接内部的通道，用于发送和接收信息 Channel channel = RabbitMqUtil