RabbitMQ

分布式消息队列是是大型分布式系统不可缺少的中间件，主要解决应用耦合、异步消息、流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。 对于一个架构师来说，在大型系统设计中，会经常需要面对同步和异步等架构问题，搞明白这些问题，能更好地实现程序并行执行，减少等待或无效操作，以及充分利用计算机的性能！ 本文将详细讲解： 1.同步架构和异步架构的区别 2.异步架构的主要组成部分：消息生产者、消息消费者、分布式消息队列 3.异步架构的两种主要模型：点对点模型和发布订阅模型。 4. 消息队列的好处 5.消息队列相关产品 建议用10min通读，搞懂分布式消息队列的核心内容。 一、同步架构和异步架构的区别 1. 同步调用 是指从请求的发起一直到最终的处理完成期间，请求的调用方一直在同步阻塞等待调用的处理完成。 如图，在这个例子中客户端代码ClientCode，需要执行发送邮件sendEmail这样一个操作，它会调用EmailService进行发送，而EmailService会调用SmtpEmailAdapter这样一个类来进行处理，而这个类会调用远程的一个服务，通过SMTP和TCP协议把请求发送给它。 而远程服务器收到消息以后会对消息进行一系列的操作，然后将邮件发送出去，再进行返回。Adapter收到返回后，再返回给EmailService

MQ理论介绍 一、为什么需要消息队列(MQ) 主要原因是由于在高并发环境下，同步请求来不及处理，请求往往会发生阻塞。大量的请求到达访问数据库，导致行锁表锁，最后请求线程会堆积过多，从而触发 too many connection错误，引发雪崩效应。我们使用消息队列，通过异步处理请求，从而缓解系统的压力。核心：异步处理、流量削峰、应用解耦 二、应用场景 异步处理，流量削峰，应用解耦，消息通讯四个场景 2.1、异步处理 场景1：用户注册后，需要发送注册邮件和注册短信。 串行方式：将注册信息写入 数据库 成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端 并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提高处理的时间 假设三个业务节点每个使用50毫秒钟，不考虑网络等其他开销，则串行方式的时间是150毫秒，并行的时间可能是100毫秒。 因为CPU在单位时间内处理的请求数是一定的，假设CPU在1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次（1000/150）。 并行方式处理的请求量是10次（1000/100） 小结：如以上案例描述，传统的方式系统的性能（并发量，吞吐量，响应时间）会有瓶颈。如何解决这个问题？ 引入消息队列，将不是必须的业务逻辑，异步处理

上一篇博客中，我们实现了工作队列，并且我们的工作队列中的一个任务只会发给一个工作者，除非某个工作者未完成任务意外被杀死，会转发给另外的工作者。这篇博客中，我们会做一些改变，就是把消息发给多个消费者，这种模式称为 发布/订阅 （类似观察者模式）。 为了验证这种模式，我们准备构建一个简单的日志系统。这个系统包含两类程序，一类程序发动日志，另一类程序接收和处理日志。在我们的日志系统中，每一个运行的接收者程序都会收到日志。然后我们实现一个接收者将接收到的数据写到硬盘上，与此同时另一个接收者把接收到的消息展现在屏幕上。本质上来说，就是发布的日志消息会转发给所有的接收者。 1. 转发器（Exchanges） 前面的博客中我们主要的介绍都是发送者发送消息给队列，接收者从队列接收消息。下面我们会引入Exchanges，展示RabbitMQ的完整的消息模型。 RabbitMQ消息模型的核心理念是生产者永远不会直接发送任何消息给队列 ，一般的情况下生产者甚至不知道消息应该发送到哪些队列。相反的， 生产者只能发送消息给转发器（ Exchange ） 。转发器是非常简单的， 一边接收从生产者发来的消息，另一边把消息推送到队列中 。转发器必须清楚的知道如何处理它收到的每一条消息。是否应该追加到一个指定的队列？是否应该追加到多个队列？或者是否应该丢弃？这些规则通过转发器的类型进行定义。 下面列出一些可用的

创建spring boot工程，添加pom依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-stream-rabbit</artifactId> </dependency> View Code 添加消息接收SinkReceiver import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.cloud.stream.annotation.EnableBinding; import org.springframework.cloud.stream.annotation.StreamListener; import org.springframework.cloud.stream.messaging.Sink; @EnableBinding(Sink. class ) public class SinkReceiver { private static Logger logger= LoggerFactory.getLogger(SinkReceiver. class ); @StreamListener(Sink.INPUT) public

rabbitmq发布订阅 记得关注作者哦，关注不迷路！ 一、发布订阅模式 还记得我们上一个文章是如何发布消息的吗？ 回顾一下以前是如何发送消息的： channel.basicPublish( "" , QUEUE_NAME, null , message.getBytes()); 对的，以前我们发送消息是直接由生产者将消息发送到队列，可是这种方式官方是不推荐的！ RabbitMQ消息传递模型中的核心思想是生产者从不将任何消息直接发送到队列。实际上，生产者经常甚至根本不知道是否将消息传递到任何队列。 相反，生产者只能将消息发送到 交换机 。交流是一件非常简单的事情。一方面，它接收来自生产者的消息，另一方面，将它们推入队列。交易所必须确切知道如何处理收到的消息。是否应将其附加到特定队列？是否应该将其附加到许多队列中？还是应该丢弃它。规则由 交换类型 定义 。 你可以将交换机想象成一个分发器更好容易理解， 消息生产者你可以理解为皇帝，他所下发的命令都由圣旨传递，皇帝当然不可能亲自去送圣旨，所以这个工作由太监来承担，这里的太监就是交换机，由太监根据圣旨类型送到文武百官手里，这里文武百官也就是消费者。 大概看一下流程图： img 其中 X 就是交换机 交换机类型大概有： direct： 直连交换机 根据RouteKey转发到队列 任何发送到Direct

将同一个队列的消息发送给多个消费者的模式就是“发布/订阅”, 这种模式的基础是将消息广播到所有的接收器上。 实际上，RabbitMQ中消息传递模型的核心思想是： 生产者不直接发送消息到队列。 实际的运行环境中，生产者是不知道消息会发送到哪个队列上， 她只会将消息发送到一个交换器， 交换器也像一个生产线，她一边接收生产者发来的消息，另外一边则根据交换规则，将消息放到队列中。 交换器必须知道她所接收的消息是什么？它应该被放到哪个队列中？它应该被添加到多个队列吗？还是应该丢弃？ 这些规则都是按照交换器的规则来确定的。 交换器的规则有： direct （直连） topic （主题） headers （标题） fanout （分发）也有翻译为扇出的 我们将使用【fanout】类型创建一个名称为myexchange的交换器 channel.exchangeDeclare("myexchange", "fanout"); 分发交换器很简单，你通过名称也能想到，她是广播所有的消息 通过rabbitmqctl list_exchanges指令可以列出服务器上所有可用的交换器列表 这个列表里面所有以【amq.*】开头的交换器都是RabbitMQ默认创建的。在生产环境中，可以自己定义。 在之前的实例中，我们知道，发送消息到队列时根本没有使用交换器，但是消息也能发送到队列。