RabbitMQ的应用场景以及基本原理介绍
rabbitmq运行机制和原理
rabbitmq运行机制和原理RabbitMQ是一个开源的消息代理软件，它支持多种消息协议。
RabbitMQ使用AMQP(Advanced Message Queuing Protocol)协议来进行消息处理。
它通常用于构建异步通信架构和分布式系统。
本文将对RabbitMQ的运行机制和原理进行详细阐述。
1. 客户端连接RabbitMQ面向TCP连接，客户端使用TCP连接进行与RabbitMQ服务器的通信。
客户端使用AMQP协议与RabbitMQ交换消息，AMQP协议定义了消息如何格式化，通过哪些路由来传递。
2. 交换机当客户端向RabbitMQ发送消息时，它需要指定消息的目标。
目标由交换机和路由键两部分组成。
交换机的作用是将消息路由到一个或多个队列中。
在RabbitMQ中，有四种交换机类型：直接交换机(direct exchange)、分发交换机(fanout exchange)、主题交换机(topic exchange)和标头交换机(headers exchange)。
3. 队列队列是RabbitMQ中的基本消息存储区。
当消息进入队列时，它是没有路由键的，队列会将消息放置到与消费者预订队列相对应的队列中。
队列中的消息只能被一个消费者消费，这是因为消费者通常需要对消息进行修改或处理。
4. 绑定绑定是交换机和队列之间的关系。
在RabbitMQ中，当消息进入交换机时，必须指定一个路由键。
交换机使用该键将消息传递到一个队列中。
一个交换机可以绑定到多个队列，一个队列也可以绑定到多个交换机。
5. 生产者和消费者生产者负责将消息发送到RabbitMQ服务器，消费者则从RabbitMQ服务器读取消息并进行处理。
生产者和消费者必须处理RabbitMQ中的连接、交换和队列等信息。
6. 消息确认RabbitMQ提供了两种消息确认模式：一种是自动确认模式，另一种则是显式确认模式。
在自动确认模式下，消费者消费消息后，服务器就会立即将其标记为已确认。
rabbitmq消费原理
rabbitmq消费原理RabbitMQ是一个常用的消息中间件，用于在应用程序之间传递消息。
它基于AMQP（高级消息队列协议）规范，提供了可靠的消息传递机制，支持高可用性和扩展性。
本文将介绍RabbitMQ的消费原理，帮助读者更好地理解和使用RabbitMQ。
一、消息队列的概念在深入讲解RabbitMQ的消费原理之前，我们先来了解一下消息队列的概念。
消息队列是一种应用程序之间传递消息的方法，通过将消息发送到队列中，然后消费者从队列中取出消息进行处理。
消息队列的好处是可以解耦生产者和消费者，提高系统的可靠性和可扩展性。
二、RabbitMQ的工作原理RabbitMQ的工作原理可以简单概括为：生产者将消息发送到交换机，交换机将消息路由到队列，消费者从队列中取出消息进行处理。
下面我们分步骤详细介绍RabbitMQ的消费原理。
1. 创建连接和通道在使用RabbitMQ之前，首先需要建立与RabbitMQ服务器的连接。
连接是一个TCP连接，用于发送和接收消息。
每个连接可以创建一个或多个通道，通道是一个轻量级的逻辑连接，用于发送和接收消息。
2. 创建交换机和队列交换机是消息的分发中心，它接收生产者发送的消息，并根据一定的规则将消息路由到队列。
RabbitMQ提供了几种常见的交换机类型，如直连交换机、扇形交换机和主题交换机等。
根据实际需求，选择合适的交换机类型。
队列是消息的存储区，生产者发送的消息最终都会存储在队列中等待消费者取出。
队列可以被多个消费者共享，每个消息只能被一个消费者消费。
3. 绑定交换机和队列在将消息发送到队列之前，需要将交换机和队列进行绑定。
绑定的过程中需要指定路由键（Routing Key），路由键用于交换机将消息路由到特定的队列。
消息的路由规则由交换机类型和绑定时的路由键决定。
4. 消费消息当队列中有消息时，消费者可以通过订阅队列的方式来消费消息。
消费者可以通过基本消费（Basic Consume）方法订阅队列，一旦有消息到达队列，就会立即通知消费者，并将消息推送给消费者进行处理。
rabbitmq知识点
rabbitmq知识点
RabbitMQ是一种开源的消息代理软件，用于在应用程序之间传递消息。
RabbitMQ是一种可靠、可扩展、易于部署的消息系统，可以用于处理高容量的数据流，并支持多种协议。
以下是关于RabbitMQ 的一些知识点：
1. RabbitMQ的工作原理
RabbitMQ使用AMQP（高级消息队列协议）来进行消息传递。
它包含一个消息发布者、一个消息代理（RabbitMQ服务器）和一个或多个消息消费者。
发布者将消息发送到消息代理，代理将消息存储在一个队列中，等待消费者来消费它。
2. RabbitMQ的应用场景
RabbitMQ在异步通信场景中应用广泛，如：分布式系统、微服务架构、多语言环境、消息队列和任务队列等场景。
3. RabbitMQ的重要概念
RabbitMQ中的重要概念包括：消息、生产者、消费者、交换机、队列、绑定、路由键等。
4. RabbitMQ的可靠性保证
RabbitMQ具有可靠性保证，可以通过消息的确认、持久化等机制来确保消息不会丢失或重复消费。
5. RabbitMQ的高可用性
RabbitMQ支持集群部署，可以实现高可用性和负载均衡，提高系统的稳定性和可用性。
6. RabbitMQ的性能优化
在使用RabbitMQ时需要注意性能优化，如：使用消息压缩、消息批量发送、消息预取等措施来提高RabbitMQ的性能。
7. RabbitMQ的安全性
RabbitMQ支持SSL和TLS等安全机制，可以确保消息传递的安全性和可靠性。
以上是关于RabbitMQ的一些知识点，希望对大家有所帮助。
rabbitmq延迟队列原理
rabbitmq延迟队列原理RabbitMQ延迟队列原理随着消息队列的应用越来越广泛，我们可以看到越来越多的情况需要我们使用延迟队列来解决问题。
RabbitMQ是一个主流的开源消息队列，在RabbitMQ中我们也可以使用延迟队列来完成一些需求。
本文主要介绍RabbitMQ延迟队列的原理。
一、什么是延迟队列？延迟队列即在消息发送过程中，可以指定消息的生存时间TTL，当TTL时间到达时，消息才会被消费。
这样可以将消息暂时保存在队列中，确保队列中的消息在一定时间后才会被消费。
二、如何实现延迟队列？在RabbitMQ中，实现延迟队列有两种方式：1. 使用x-delayed-message插件RabbitMQ提供了一个称为延迟插件（x-delayed-message）的插件，该插件可用于实现延迟队列。
该插件提供了一个专用的x-delayed-message交换机类型，它可以按照指定的时间对消息进行延迟处理。
2. 使用消息TTL和DLXRabbitMQ中生产消息时可以设置TTL（Time To Live），表示消息的生存时间。
当消息的生存时间到达后，消息会被队列从队列中删除。
我们也可以使用死信交换机（Dead Letter Exchange，DLX），将已经存在一定时间的消息转移到另一个队列中，以实现消息的延迟处理。
三、延迟队列的实现机制使用插件方式：1. 安装插件使用rabbitmq-plugins命令安装插件，例如：rabbitmq-plugins enable rabbitmq_delayed_message_exchange2. 创建延迟交换机创建x-delayed-message类型的延迟交换机，例如：channel.exchangeDeclare("delayed_exchange", "x-delayed-message", true, false, new HashMap<String, Object>() {{put("x-delayed-type", "direct");}});3. 创建队列创建一个普通的队列，例如：channel.queueDeclare("delayed_queue", true, false, false, null);4. 绑定交换机和队列将队列绑定到延迟交换机上，例如：channel.queueBind("delayed_queue", "delayed_exchange", "delayed_queue", new HashMap<String, Object>() {{put("x-delay", 5000);}});使用TTL和DLX方式：1. 创建队列创建一个普通的队列，例如：channel.queueDeclare("queue", true, false, false, new HashMap<String, Object>() {{put("x-dead-letter-exchange", "dlx_exchange");put("x-dead-letter-routing-key", "dlx_routing_key");}});2. 创建DLX创建一个DLX，将队列绑定到该DLX上，例如：channel.exchangeDeclare("dlx_exchange", "direct", true, false,null);channel.queueDeclare("dlx_queue", true, false, false, null); channel.queueBind("dlx_queue", "dlx_exchange","dlx_routing_key", null);3. 发送消息发送一个带有TTL属性的消息到队列中，例如：AMQP.BasicProperties.Builder builder = newAMQP.BasicProperties.Builder();builder.expiration("5000");channel.basicPublish("", "queue", builder.build(), "Hello, RabbitMQ!".getBytes());四、延迟队列的应用场景1. 订单支付超时在电商平台的订单系统中，如果用户在规定时间内未完成支付，系统需要取消该订单。
rabbitmq 知识点总结
rabbitmq 知识点总结RabbitMQ 知识点总结RabbitMQ 是一个开源的消息中间件，它实现了高级消息队列协议（AMQP），主要用于应用程序之间的异步消息传递。
本文将对RabbitMQ 的相关知识点进行总结，包括基本概念、主要特性、使用场景以及与其他消息队列系统的比较等。
一、基本概念1. 消息队列：消息队列是一种存储消息的容器，应用程序可以通过消息队列进行异步通信，发送方将消息放入队列，接收方从队列中获取消息进行处理。
2. 生产者：生产者是消息的发送方，将消息发送到队列中。
3. 消费者：消费者是消息的接收方，从队列中获取消息并进行处理。
4. 队列：队列是消息的存储空间，消息按照先进先出（FIFO）的顺序进行存储和处理。
二、主要特性1. 可靠性：RabbitMQ 提供了多种机制来保证消息的可靠性，如消息持久化、消息确认机制等。
2. 灵活的路由：RabbitMQ 支持多种路由方式，如直连路由、主题路由、扇型路由等，可以根据需求灵活地进行消息路由。
3. 高并发：RabbitMQ 采用多线程模型，可以支持高并发的消息处理。
4. 可扩展性：RabbitMQ 支持集群部署，可以通过增加节点来实现系统的水平扩展。
5. 消息确认机制：RabbitMQ 提供了消息确认机制，可以确保消息被消费者正确接收，避免消息丢失或重复消费的问题。
三、使用场景1. 异步任务处理：将耗时的任务放入消息队列中，由消费者异步处理，提高系统的并发能力。
2. 应用解耦：通过消息队列实现应用之间的解耦，提高系统的可维护性和可扩展性。
3. 流量削峰：当系统并发请求过多时，可以将请求放入消息队列中，由消费者按照系统处理能力进行消费，避免系统崩溃或响应变慢。
4. 日志收集：将系统日志通过消息队列发送到日志处理系统，实现日志的集中存储和分析。
5. 分布式系统：在分布式系统中，可以使用 RabbitMQ 进行消息传递和协调。
四、与其他消息队列系统的比较1. ActiveMQ：RabbitMQ 相对于 ActiveMQ 来说，性能更高、可靠性更好，而且支持更多的特性和协议。
2021-04-25RabbitMQ七种队列模式应用场景案例分析(通俗易懂)
RabbitMQ 七种队列模式应用场景案例分析（通俗易懂）七种模式介绍与应用场景简单模式（Hello World）做最简单的事情，一个生产者对应一个消费者，RabbitMQ相当于一个消息代理，负责将A的消息转发给B应用场景：将发送的电子邮件放到消息队列，然后邮件服务在队列中获取邮件并发送给收件人工作队列模式（Work queues）在多个消费者之间分配任务（竞争的消费者模式），一个生产者对应多个消费者，一般适用于执行资源密集型任务，单个消费者处理不过来，需要多个消费者进行处理应用场景：一个订单的处理需要10s，有多个订单可以同时放到消息队列，然后让多个消费者同时处理，这样就是并行了，而不是单个消费者的串行情况订阅模式（Publish/Subscribe）一次向许多消费者发送消息，一个生产者发送的消息会被多个消费者获取，也就是将消息将广播到所有的消费者中。
应用场景：更新商品库存后需要通知多个缓存和多个数据库，这里的结构应该是：•一个fanout类型交换机扇出两个个消息队列，分别为缓存消息队列、数据库消息队列•一个缓存消息队列对应着多个缓存消费者•一个数据库消息队列对应着多个数据库消费者路由模式（Routing）有选择地（Routing key）接收消息，发送消息到交换机并且要指定路由key ，消费者将队列绑定到交换机时需要指定路由key，仅消费指定路由key的消息应用场景：如在商品库存中增加了1台iphone12，iphone12促销活动消费者指定routing key为iphone12，只有此促销活动会接收到消息，其它促销活动不关心也不会消费此routing key的消息主题模式（Topics）根据主题（Topics）来接收消息，将路由key和某模式进行匹配，此时队列需要绑定在一个模式上，#匹配一个词或多个词，*只匹配一个词。
应用场景：同上，iphone促销活动可以接收主题为iphone的消息，如iphone12、iphone13等远程过程调用（RPC）如果我们需要在远程计算机上运行功能并等待结果就可以使用RPC，具体流程可以看图。
rabbitmq集群,消费者消费消息原理
rabbitmq集群,消费者消费消息原理1. 引言1.1 什么是RabbitMQ集群RabbitMQ是一个开源的消息代理软件，实现了AMQP（高级消息队列协议）标准，用于在分布式环境中传递消息。
RabbitMQ集群是将多个RabbitMQ代理配置在一起，以提高可靠性、可扩展性和性能。
当一个节点发生故障时，集群可以继续运行，确保消息的可靠传递。
RabbitMQ集群通过将数据和负载分布在多个节点上来实现高可用性。
每个节点都可以独立处理消息的存储和传递，同时还可以与其他节点进行通信，以确保消息的正确路由和传递。
集群中的节点可以动态地加入或退出，使得系统具有较高的弹性和可伸缩性。
RabbitMQ集群是一种强大的消息传递解决方案，能够提供高可用性、可扩展性和性能，是构建分布式系统和微服务架构的理想选择。
通过合理配置和管理集群，可以确保消息的可靠传递，保障系统的稳定性和可靠性。
1.2 什么是消费者消费消息消费者消费消息是指在RabbitMQ集群中，消费者通过订阅队列来获取并处理消息的过程。
消费者在消费消息时需要考虑到消息的确认、分配和重试机制，以确保消息能够被正确地处理并达到预期的效果。
消费者消费消息的流程通常包括以下步骤：1. 连接到RabbitMQ集群：消费者需要先建立与RabbitMQ集群的连接，并订阅感兴趣的队列。
2. 接收消息：一旦消费者订阅了队列，RabbitMQ集群就会将消息发送给消费者，消费者可以通过消费者端的订阅函数获取消息。
3. 处理消息：消费者收到消息后会进行相应的处理，可能是执行某些逻辑操作、更新数据库或发送响应。
4. 消息确认：消费者在处理完消息后需要向RabbitMQ集群发送确认消息，以告知RabbitMQ该消息已被处理，并可以在队列中删除。
5. 消息重试：如果消费者在处理消息时发生错误或失败，可以根据消费者消息重试机制进行相应的处理，例如重新发送消息或将消息放回队列中等待后续处理。
RabbitMQ介绍与PHP应用，及碰到问题解决
RabbitMQ介绍与PHP应⽤，及碰到问题解决⼀. RabbitMQ 简介MQ全称为Message Queue, 消息队列（MQ）是⼀种应⽤程序对应⽤程序的通信⽅法。
应⽤程序通过读写出⼊队列的消息（针对应⽤程序的数据）来通信，⽽⽆需专⽤连接来链接它们。
消息传递指的是程序之间通过在消息中发送数据进⾏通信，⽽不是通过直接调⽤彼此来通信，直接调⽤通常是⽤于诸如远程过程调⽤的技术。
排队指的是应⽤程序通过队列来通信。
队列的使⽤除去了接收和发送应⽤程序同时执⾏的要求。
RabbitMQ是使⽤Erlang语⾔开发的开源消息队列系统，基于AMQP协议来实现。
AMQP的主要特征是⾯向消息、队列、路由(包括点对点和发布/订阅)、可靠性、安全。
AMQP协议更多⽤在企业系统内，对数据⼀致性、稳定性和可靠性要求很⾼的场景，对性能和吞吐量的要求还在其次。
⼆. RabbitMQ 使⽤场景1. 解耦（为⾯向服务的架构（SOA）提供基本的最终⼀致性实现）场景说明：⽤户下单后，订单系统需要通知库存系统。
传统的做法是，订单系统调⽤库存系统的接⼝。
传统模式的缺点：假如库存系统⽆法访问，则订单减库存将失败，从⽽导致订单失败订单系统与库存系统耦合引⼊消息队列订单系统：⽤户下单后，订单系统完成持久化处理，将消息写⼊消息队列，返回⽤户订单下单成功库存系统：订阅下单的消息，采⽤拉/推的⽅式，获取下单信息，库存系统根据下单信息，进⾏库存操作假如：在下单时库存系统不能正常使⽤。
也不影响正常下单，因为下单后，订单系统写⼊消息队列就不再关⼼其他的后续操作了。
实现订单系统与库存系统的应⽤解耦为了保证库存肯定有，可以将队列⼤⼩设置成库存数量，或者采⽤其他⽅式解决。
基于消息的模型，关⼼的是“通知”，⽽⾮“处理”。
短信、邮件通知、缓存刷新等操作使⽤消息队列进⾏通知。
消息队列和RPC的区别与⽐较：RPC: 异步调⽤，及时获得调⽤结果，具有强⼀致性结果，关⼼业务调⽤处理结果。
RabbitMQ从零到集群高可用.NetCore（.NET5）-RabbitMQ简介和六种。。。
RabbitMQ从零到集群⾼可⽤.NetCore（.NET5）-RabbitMQ简介和六种。
系列⽂章：⼀、RabbitMQ简介是⼀个开源的消息代理和队列服务器，⽤来通过普通协议在完全不同的应⽤之间共享数据，RabbitMQ是使⽤Erlang(⾼并发语⾔)语⾔来编写的，并且RabbitMQ是基于AMQP协议的。
1.1 AMQP协议Advanced Message Queuing Protocol(⾼级消息队列协议)1.2 AMQP专业术语：（多路复⽤->在同⼀个线程中开启多个通道进⾏操作）Server：⼜称broker，接受客户端的链接，实现AMQP实体服务Connection:连接，应⽤程序与broker的⽹络连接Channel:⽹络信道，⼏乎所有的操作都在channel中进⾏，Channel是进⾏消息读写的通道。
客户端可以建⽴多个channel，每个channel代表⼀个会话任务。
Message:消息，服务器与应⽤程序之间传送的数据，由Properties和Body组成.Properties可以对消息进⾏修饰，必须消息的优先级、延迟等⾼级特性；Body则是消息体内容。
virtualhost: 虚拟地址，⽤于进⾏逻辑隔离，最上层的消息路由。
⼀个virtual host⾥⾯可以有若⼲个Exchange和Queue，同⼀个Virtual Host ⾥⾯不能有相同名称的Exchange 或 Queue。
Exchange：交换机，接收消息，根据路由键转单消息到绑定队列Binding: Exchange和Queue之间的虚拟链接，binding中可以包换routing keyRouting key: ⼀个路由规则，虚拟机可⽤它来确定如何路由⼀个特定消息。
（如负载均衡）1.3 RabbitMQ整体架构ClientA(⽣产者)发送消息到Exchange1(交换机)，同时带上RouteKey(路由Key)，Exchange1找到绑定交换机为它和绑定传⼊的RouteKey的队列，把消息转发到对应的队列，消费者Client1，Client2,Client3只需要指定对应的队列名即可以消费队列数据。
rabbitMQ教程（三）一篇文章看懂rabbitMQ
rabbitMQ教程（三）⼀篇⽂章看懂rabbitMQ⼀、rabbitMQ是什么： RabbitMQ,遵循AMQP协议，由内在⾼并发的erlanng语⾔开发，⽤在实时的对可靠性要求⽐较⾼的消息传递上。
学过websocket的来理解rabbitMQ应该是⾮常简单的了，websocket是基于服务器和页⾯之间的通信协议，⼀次握⼿，多次通信。
⽽rabbitMQ就像是服务器之间的socket，⼀个服务器连上MQ监听，⽽另⼀个服务器只要通过MQ发送消息就能被监听服务器所接收。
但是MQ和socket还是有区别的，socket相当于是页⾯直接监听服务器。
⽽MQ就是服务器之间的中转站，例如邮箱，⼀个⼈投递信件给邮箱，另⼀个⼈去邮箱取，他们中间没有直接的关系，所以耦合度相⽐socket⼩了很多。
上图是最简单的MQ关系，⽣产者-MQ队列-消费者⼆、MQ使⽤场景： 别啥固定式使⽤场景了，说的透彻⼀点，他就是服务器之间通信的，前⾯博⽂中提到的Httpclient也可以做到，但是这个相对于其他通信在中间做了⼀个中间仓库。
好处1：降低了两台服务器之间的耦合，哪怕是⼀台服务器挂了，另外⼀台服务器也不会报错或者休克，反正他监听的是MQ，只要服务器恢复再重新连上MQ发送消息，监听服务器就能再次接收。
好处2：MQ作为⼀个仓库，本⾝就提供了⾮常强⼤的功能，例如不再是简单的⼀对⼀功能，还能⼀对多，多对⼀，⾃⼰脑补保险箱场景，只要有特定的密码，谁都能存，谁都能取。
也就是说能实现群发消息和以此衍⽣的功能。
好处3：现在普遍化的持久化功能，当MQ挂掉可以存储在磁盘等下重启恢复。
（需要设置）三、专业术语介绍：1. ⽣产者：在现实⽣活中就好⽐制造商品的⼯⼚，他们是商品的⽣产者。
⽣产者只意味着发送。
发送消息的程序称之为⼀个⽣产者。
2. 队列：rabbitMQ就像⼀个仓库，⼀个仓库⾥⾯可以有很多队列，每个队列才是服务器之间消息通信的载体。
RabbitMQ（消息中间件）在工作中的应用场景
RabbitMQ（消息中间件）在⼯作中的应⽤场景1、跨系统的异步通信，所有需要异步交互的地⽅都可以使⽤消息队列。
就像我们除了打电话（同步）以外，还需要发短信，发电⼦邮件（异步）的通讯⽅式。
2、多个应⽤之间的耦合，由于消息是平台⽆关和语⾔⽆关的，⽽且语义上也不再是函数调⽤，因此更适合作为多个应⽤之间的松耦合的接⼝。
基于消息队列的耦合，不需要发送⽅和接收⽅同时在线。
在企业应⽤集成（EAI）中，⽂件传输，共享数据库，消息队列，远程过程调⽤都可以作为集成的⽅法。
3、应⽤内的同步变异步，⽐如订单处理，就可以由前端应⽤将订单信息放到队列，后端应⽤从队列⾥依次获得消息处理，⾼峰时的⼤量订单可以积压在队列⾥慢慢处理掉。
由于同步通常意味着阻塞，⽽⼤量线程的阻塞会降低计算机的性能。
4、消息驱动的架构（EDA），系统分解为消息队列，和消息制造者和消息消费者，⼀个处理流程可以根据需要拆成多个阶段（Stage），阶段之间⽤队列连接起来，前⼀个阶段处理的结果放⼊队列，后⼀个阶段从队列中获取消息继续处理。
5、应⽤需要更灵活的耦合⽅式，如发布订阅，⽐如可以指定路由规则。
6、跨局域⽹，甚⾄跨城市的通讯（CDN⾏业），⽐如北京机房与⼴州机房的应⽤程序的通信。
这⾥还有⼀种情况，同时有⼤量⽤户注册你的软件，再⾼并发情况下注册请求开始出现⼀些问题，例如邮件接⼝承受不住，或是分析信息时的⼤量计算使cpu满载，这将会出现虽然⽤户数据记录很快的添加到数据库中了，但是却卡在发邮件或分析信息时的情况，导致请求的响应时间⼤幅增长，甚⾄出现超时，这就有点不划算了。
⾯对这种情况⼀般也是将这些操作放⼊消息队列（⽣产者消费者模型），消息队列慢慢的进⾏处理，同时可以很快的完成注册请求，不会影响⽤户使⽤其他功能。
rabbitmq实现原理
rabbitmq实现原理
RabbitMQ是一个开源的消息代理软件，它实现了高度可靠的消息传输机制。
RabbitMQ基于AMQP协议，采用分布式架构，可以支持多种编程语言。
RabbitMQ的实现原理主要包括以下几个方面：
1. 消息队列的建立
RabbitMQ会创建多个消息队列，每个队列都有一个唯一的名称。
当需要将消息发送到队列中时，客户端需要通过指定队列名称来确定消息所属的队列。
2. 消息的发送和接收
客户端可以通过发送消息的方式将消息发送到特定的队列中，也可以通过订阅队列的方式接收队列中的消息。
RabbitMQ的消息传递方式采用了推拉模式，可以根据客户端的需求进行消息的推送或者拉取。
3. 消息的持久化
RabbitMQ可以将消息持久化到磁盘中，以确保即使在服务器宕机的情况下，消息也不会丢失。
客户端可以在发送消息时指定消息的持久化方式。
4. 消息的路由
RabbitMQ可以通过路由键将消息路由到不同的队列中，这样就可以根据消息的属性将消息发送到特定的队列中。
RabbitMQ支持多种不同的路由方式，包括直接路由、主题路由和扇形路由。
5. 消息的确认和重试
RabbitMQ可以通过消息确认机制，确保消息被成功处理。
如果消息没有被成功处理，RabbitMQ还可以进行消息重试，以确保消息被正确处理。
总的来说，RabbitMQ的实现原理非常稳健和可靠，可以满足各种不同的消息传递需求。
rabbitmq底层原理
rabbitmq底层原理RabbitMQ是一个开源的消息代理软件，它实现了高效的消息传递机制，广泛应用于企业与Web应用中。
RabbitMQ的核心是一个消息队列，它将消息从一个应用程序传递到另一个应用程序，以实现异步通信。
本文将探讨RabbitMQ的底层原理，包括消息队列的实现、消息的路由与交换、以及高可用性的实现。
一、消息队列的实现RabbitMQ的消息队列是基于AMQP（Advanced Message Queuing Protocol）协议实现的。
AMQP协议定义了消息队列的基本操作，包括生产者向消息队列发送消息、消费者从消息队列中取出消息等。
RabbitMQ的消息队列由三部分组成：Exchange、Queue和Binding。
Exchange是消息的路由中心，它接收生产者发送的消息，并根据消息的路由键将消息发送给相应的消息队列。
Exchange有四种类型：direct、fanout、topic和headers。
不同类型的Exchange实现了不同的路由策略，以满足不同的应用场景。
例如，direct类型的Exchange将消息发送给与消息路由键完全匹配的队列；而topic类型的Exchange将消息发送给与消息路由键模式匹配的队列。
Queue是消息的存储中心，它保存生产者发送的消息，直到消费者取出消息。
Queue有多种属性，包括名称、持久化、自动删除等。
持久化属性可以使消息在RabbitMQ重启后仍然存在；自动删除属性可以使消息在没有消费者订阅时自动删除。
Binding是Exchange和Queue之间的关系，它将Exchange和Queue绑定在一起，以实现消息的路由。
Binding有两个属性：路由键和参数。
路由键指定了消息发送到哪个Queue，而参数可以用来过滤消息。
二、消息的路由与交换在RabbitMQ中，生产者将消息发送到Exchange，Exchange将消息发送给与之绑定的Queue。
rabbitmq的工作原理
rabbitmq的工作原理RabbitMQ是一种消息队列软件，在分布式系统中被广泛使用。
RabbitMQ基于AMQP（高级消息队列协议）的实现，并通过发布/订阅模式来处理消息。
1. 消息队列的定义及作用消息队列是一种应用程序间通信的方式，用于在系统中传递消息。
它可以将消息从一个应用程序异步的传送到另一个应用程序，从而实现应用程序间的解耦。
消息队列还可以优化系统的性能和可伸缩性。
2. RabbitMQ的基本概念RabbitMQ中包含一些基本概念，如队列（queue）、交换机（exchange）和绑定（binding）。
队列是消息的载体，在RabbitMQ中，消息被存储在队列中。
可以通过消息消费者从队列中获取消息。
每个队列都有一个默认的交换机，用于传递来自生产者的消息。
交换机用于路由消息，它接收来自生产者的消息，并将其路由到相应的队列。
交换机根据绑定的规则决定将消息发送到哪个队列。
在RabbitMQ中，交换机有四种类型：直接交换机、主题交换机、标头交换机和扇形交换机。
绑定定义了队列和交换机之间的关系。
绑定指定了消息应该路由到哪个队列。
3. 消息的发送和接收流程在RabbitMQ中，消息的发送和接收流程如下：生产者将消息发送给特定的交换机，交换机将消息路由到相应的队列。
消费者从队列中获取消息并进行处理。
具体地，发送消息的流程如下：① 生产者将消息发送给特定的交换机（exchange）；② 交换机根据绑定规则将消息路由到相应的队列（queue）；③ 消费者从队列中获取消息进行处理。
接收消息的流程如下：① 消费者从指定的队列中取出一条消息；② 消费者处理这条消息，完成后发送确认消息给消息队列；③ 消息队列接收到确认消息后，将该消息从队列中删除。
4. RabbitMQ的工作模式RabbitMQ支持两种工作模式：竞争消费者模式和订阅模式。
竞争消费者模式是一种消息队列模式，其中有多个消费者订阅了同一个队列。
消息被平均分配给每个消费者，这样每个消费者都可以获得部分消息。
rabbmitmq的使用场景
rabbmitmq的使用场景引言：RabbitMQ是一个可靠、灵活且易于使用的开源消息队列中间件。
它采用AMQP协议作为通信协议，广泛应用于各种场景中。
本文将介绍RabbitMQ的使用场景，分为以下几个方面：1. 分布式系统之间的通信RabbitMQ作为一种消息队列中间件，可以优雅地解决分布式系统之间的通信问题。
对于一个复杂的系统，各个组件之间需要进行大量的消息传递，包括请求、响应、事件通知等。
使用RabbitMQ可以轻松地实现这些消息的异步传递，同时保证消息的可靠性和顺序性。
通过RabbitMQ，各个组件之间可以解耦，提高系统的可维护性和可扩展性。
2. 应用程序之间的解耦在一个大型应用系统中，各个模块之间的耦合度通常很高，一个模块的改动往往涉及到其他模块的改动。
通过引入RabbitMQ作为消息传递机制，可以将各个模块解耦，使得它们之间的依赖尽量减少。
每个模块只需关心自己感兴趣的消息，而不需要关心消息的发送者和接收者是谁。
这样，系统的维护成本和开发周期都可以得到有效控制。
3. 异步任务处理在一个高并发的应用场景中，某些任务耗时较长，无法通过同步方式进行处理。
传统的解决方案是将这些任务交给线程池来处理，但是线程池的资源有限，一旦任务过多，就会导致线程阻塞或耗尽。
而使用RabbitMQ作为任务队列，则可以将这些任务提交到消息队列中，由消费者异步地处理。
这样可以有效避免任务阻塞和资源耗尽的问题，提高系统的稳定性和性能。
4. 日志收集与分析在一个分布式架构下，各个节点的日志分散在不同的地方，如果需要进行日志的收集和分析，会非常困难。
通过引入RabbitMQ，可以将各个节点的日志发送到消息队列中，而不必关心具体的日志存储位置。
然后，将消费者与消息队列连接，对日志进行收集、解析和分析。
这样可以实现集中式的日志管理，方便系统维护和故障排查。
结论：RabbitMQ作为一种消息队列中间件，可以被广泛应用于分布式系统之间的通信、应用程序之间的解耦、异步任务处理以及日志收集与分析等场景。
rabbit mq 原理
rabbit mq 原理RabbitMQ 是一个开源的消息队列系统，它可以用于构建分布式应用程序，处理大量的消息传递。
RabbitMQ 的原理是基于 AMQP （高级消息队列协议），它使用消息队列来实现应用程序之间的异步通信。
RabbitMQ 的工作原理主要包括以下几个方面：1. 生产者和消费者，生产者负责将消息发送到 RabbitMQ 服务器，而消费者则从服务器中获取消息并进行处理。
这种模式可以实现解耦，生产者和消费者之间不需要直接通信，它们只需要通过消息队列进行交互。
2. Exchange，Exchange 是消息的路由中心，它接收来自生产者的消息，并根据一定的规则将消息发送到特定的队列中。
Exchange 可以根据不同的路由规则将消息发送到不同的队列中，实现消息的分发和路由。
3. Queue，Queue 是消息的存储和传递中心，它存储来自Exchange 的消息，并将消息传递给消费者进行处理。
队列中的消息遵循先进先出的原则，消费者可以按照自己的速度处理消息。
4. Binding，Binding 是 Exchange 和 Queue 之间的绑定关系，它定义了消息从 Exchange 到达 Queue 的路由规则。
通过 Binding，可以将特定类型的消息路由到特定的队列中。
5. Virtual Host，RabbitMQ 支持虚拟主机的概念，每个虚拟主机相当于一个独立的消息队列系统，它可以拥有自己的 Exchange、Queue、Binding 等资源，实现不同应用之间的隔离。
总的来说，RabbitMQ 的原理是基于消息队列的模式，通过生产者、消费者、Exchange、Queue、Binding 等组件的协作，实现了应用程序之间的异步通信和解耦。
它提供了可靠的消息传递机制，保证了消息的可靠性和稳定性，是构建分布式应用程序的重要工具之一。
RabbitMQ使用以及原理解析
RabbitMQ使⽤以及原理解析RabbitMQ使⽤以及原理解析RabbitMQ是⼀个由erlang开发的AMQP(Advanved Message Queue)的开源实现;在RabbitMQ官⽹上主要有这样的模块信息, Work queues消息队列,Publish/Subscribe发布订阅服务,Routing, Topics, RPC等主要应⽤的模块功能.⼏个概念说明:Broker:它提供⼀种传输服务,它的⾓⾊就是维护⼀条从⽣产者到消费者的路线，保证数据能按照指定的⽅式进⾏传输,Exchange：消息交换机,它指定消息按什么规则,路由到哪个队列。
Queue:消息的载体,每个消息都会被投到⼀个或多个队列。
Binding:绑定，它的作⽤就是把exchange和queue按照路由规则绑定起来.Routing Key:路由关键字,exchange根据这个关键字进⾏消息投递。
vhost:虚拟主机,⼀个broker⾥可以有多个vhost，⽤作不同⽤户的权限分离。
Producer:消息⽣产者,就是投递消息的程序.Consumer:消息消费者,就是接受消息的程序.Channel:消息通道,在客户端的每个连接⾥,可建⽴多个channel.RabbitMQ的流程图AMQP(⾼级消息队列协议 Advanced Message Queue Protocol)Rabbitmq系统最核⼼的组件是Exchange和Queue，上图是系统简单的⽰意图。
Exchange和Queue是在rabbitmq server（⼜叫做broker）端，producer和consumer在应⽤端。
流程思路左边的Client向右边的Client发送消息，流程：1，获取Conection2，获取Channel3，定义Exchange，Queue4，使⽤⼀个RoutingKey将Queue Binding到⼀个Exchange上5，通过指定⼀个Exchange和⼀个RoutingKey来将消息发送到对应的Queue上，6，接收⽅在接收时也是获取connection，接着获取channel，然后指定⼀个Queue直接到它关⼼的Queue上取消息，它对Exchange，RoutingKey及如何binding都不关⼼，到对应的Queue上去取消息就OK了;。
RabbitMQ的应用场景
RabbitMQ的应⽤场景直接进⼊正题。
⼀.异步处理场景：发送⼿机验证码，邮件传统古⽼处理⽅式如下图这个流程，全部在主线程完成，注册-》⼊库-》发送邮件-》发送短信，由于都在主线程，所以要等待每⼀步完成才能继续执⾏。
由于每⼀步的操作时间响应时间不固定，所以主线程的请求耗时可能会⾮常长，如果请求过多，会导致IIS站点巨慢，排队请求，甚⾄宕机，严重影响⽤户体验。
现在⼤多数的处理⽅式如下图这个做法是主线程只做耗时⾮常短的⼊库操作，发送邮件和发送短信，会开启2个异步线程，扔进去并⾏执⾏，主线程不管，继续执⾏后续的操作，这种处理⽅式要远远好过第⼀种处理⽅式，极⼤的增强了请求响应速度，⽤户体验良好。
缺点是，由于异步线程⾥的操作都是很耗时间的操作，⼀个请求要开启2个线程，⽽⼀台标准配置的ECS服务器⽀撑的并发线程数⼤概在800左右，假设⼀个线程在10秒做完，这个单个服务器最多能⽀持400个请求的并发，后⾯的就要排队。
出现这种情况，就要考虑增加服务器做负载，尴尬的增加成本。
消息队列RabbitMq的处理⽅式这个流程是，主线程依旧处理耗时低的⼊库操作，然后把需要处理的消息写进消息队列中，这个写⼊耗时可以忽略不计，⾮常快，然后，独⽴的发邮件⼦系统，和独⽴的发短信⼦系统，同时订阅消息队列，进⾏单独处理。
处理好之后，向队列发送ACK确认，消息队列整条数据删除。
这个流程也是现在各⼤公司都在⽤的⽅式，以SOA服务化各个系统，把耗时操作，单独交给独⽴的业务系统，通过消息队列作为中间件，达到应⽤解耦的⽬的，并且消耗的资源很低，单台服务器能承受更⼤的并发请求。
⼆.应⽤解耦以电商的下订单为例⼦，假设中间的流程为下单=》减库存=》发货第⼀种⽅式，通过连续操作表，在单⼀系统中，通过主线程，连续操作。
呵呵哒，这种做法，相信很多⼈刚⼊门，甚⾄⼏年经验了，由于项⽬⼩，也在继续使⽤吧。
⽤户量少，或者都是内部⼈使⽤，必然没问题，因为不会在意出的问题，这种做法，只要⼀个环节出问题，请求直接报错，导致⽤户懵逼，假设在执⾏到减库存操作报错了，整个流程没有⽤事务回滚的话，还会造成数据不⼀致。
rabbitmq 底层原理
rabbitmq 底层原理RabbitMQ是一种开源的消息队列中间件，最初由LShift公司开发，并于2010年成为Pivotal Software的一部分。
它是使用Erlang语言编写的，基于AMQP（高级消息队列协议）实现的。
RabbitMQ 的底层原理涉及到消息的生产、传输和消费等多个方面。
RabbitMQ的消息生产过程是由生产者完成的。
生产者将消息发送到交换机（Exchange）中，交换机根据预定的路由规则将消息发送到一个或多个队列（Queue）。
在RabbitMQ中，生产者和交换机之间的连接是通过AMQP协议进行的。
RabbitMQ的消息传输过程是通过通道（Channel）完成的。
通道是生产者与消费者之间的虚拟连接，可以看作是一个轻量级的连接，可以承载多个消息的传输。
通道的使用可以提高消息传输的效率和性能。
RabbitMQ的消息传输过程主要依赖于以下几个组件：交换机、队列和绑定。
交换机负责接收生产者发送的消息，并根据预定的路由规则将消息发送到一个或多个队列中。
队列是存储消息的地方，消费者可以从队列中获取消息进行消费。
绑定是交换机和队列之间的关联关系，通过绑定，交换机可以将消息发送到指定的队列中。
RabbitMQ的消息消费过程是由消费者完成的。
消费者通过订阅队列来获取消息，当队列中有消息时，消费者会从队列中获取消息进行消费。
消费者可以使用基于轮询或订阅的方式来获取消息。
在RabbitMQ中，消息的传输是可靠的。
当消息发送到队列后，RabbitMQ会确保消息被正确地发送到消费者，并且可以设置消息的持久化，即使在RabbitMQ重启后，消息也不会丢失。
RabbitMQ还支持消息的确认和拒绝机制。
当消费者成功地处理了一条消息后，可以发送确认消息给RabbitMQ，告知RabbitMQ该消息已经被处理。
如果消费者无法处理一条消息，可以发送拒绝消息给RabbitMQ，告知RabbitMQ该消息无法被处理。
rabbitmq消息队列原理
rabbitmq消息队列原理
RabbitMQ是一种流行的消息队列中间件，广泛应用于分布式系统中。
它的核心原理是基于AMQP（高级消息队列协议）标准的消息传递模式。
消息传递模式是指，消息生产者将消息发送到消息队列中，消息消费者从消息队列中获取消息并进行处理。
RabbitMQ的架构包括生产者、消费者、交换机和队列。
生产者将消息发送到交换机，交换机将消息路由到一个或多个队列中，消费者从队列中获取消息并进行处理。
这种模式使得系统更加灵活和可扩展，可以根据需求对系统进行配置和优化。
RabbitMQ的消息队列模型支持多种消息模式，包括点对点模式、发布/订阅模式和工作队列模式。
在点对点模式中，消息生产者将消息发送到队列，只有一个消费者从队列中获取并处理消息；在发布/订阅模式中，消息生产者将消息发送到交换机，多个消费者从队列中获取并处理消息；在工作队列模式中，多个消费者从同一个队列中获取并处理消息，每个消息只有一个消费者可以处理。
RabbitMQ还支持高级特性，如消息确认、持久化、事务和集群等。
消息确认功能可确保消息在传递过程中不会丢失；消息持久化功能可确保消息在系统故障时不会丢失；事务功能可以确保消息的原子性处理；集群功能可以将多个RabbitMQ节点组成一个集群，提高系统的可靠性和可用性。
总之，RabbitMQ作为一种流行的消息队列中间件，其核心原理是基于AMQP标准的消息传递模式。
通过支持多种消息模式和高级特
性，RabbitMQ可以满足各种场景下的需求，提高系统的可靠性和可扩展性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
RabbitMQ的应用场景以及基本原理介绍1.背景RabbitMQ是一个由erlang开发的AMQP(Advanved Message Queue)的开源实现。
2.应用场景2.1异步处理场景说明：用户注册后，需要发注册邮件和注册短信,传统的做法有两种1.串行的方式;2.并行的方式(1)串行方式:将注册信息写入数据库后,发送注册邮件,再发送注册短信,以上三个任务全部完成后才返回给客户端。
这有一个问题是,邮件,短信并不是必须的,它只是一个通知,而这种做法让客户端等待没有必要等待的东西.(2)并行方式:将注册信息写入数据库后,发送邮件的同时,发送短信,以上三个任务完成后,返回给客户端,并行的方式能提高处理的时间。
假设三个业务节点分别使用50ms,串行方式使用时间150ms,并行使用时间100ms。
虽然并性已经提高的处理时间,但是,前面说过,邮件和短信对我正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功,英爱是写入数据库后就返回.(3)消息队列引入消息队列后，把发送邮件,短信不是必须的业务逻辑异步处理由此可以看出,引入消息队列后，用户的响应时间就等于写入数据库的时间+写入消息队列的时间(可以忽略不计),引入消息队列后处理后,响应时间是串行的3倍,是并行的2倍。
2.2 应用解耦场景：双11是购物狂节,用户下单后,订单系统需要通知库存系统,传统的做法就是订单系统调用库存系统的接口.这种做法有一个缺点:当库存系统出现故障时,订单就会失败。
(这样马云将少赚好多好多钱^ ^)订单系统和库存系统高耦合.引入消息队列订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。
库存系统:订阅下单的消息,获取下单消息,进行库操作。
就算库存系统出现故障,消息队列也能保证消息的可靠投递,不会导致消息丢失(马云这下高兴了).流量削峰流量削峰一般在秒杀活动中应用广泛场景:秒杀活动，一般会因为流量过大，导致应用挂掉,为了解决这个问题，一般在应用前端加入消息队列。
作用:1.可以控制活动人数，超过此一定阀值的订单直接丢弃(我为什么秒杀一次都没有成功过呢^^)2.可以缓解短时间的高流量压垮应用(应用程序按自己的最大处理能力获取订单)1.用户的请求,服务器收到之后,首先写入消息队列,加入消息队列长度超过最大值,则直接抛弃用户请求或跳转到错误页面.2.秒杀业务根据消息队列中的请求信息，再做后续处理.3.系统架构几个概念说明:Broker:它提供一种传输服务,它的角色就是维护一条从生产者到消费者的路线，保证数据能按照指定的方式进行传输,Exchange：消息交换机,它指定消息按什么规则,路由到哪个队列。
Queue:消息的载体,每个消息都会被投到一个或多个队列。
Binding:绑定，它的作用就是把exchange和queue按照路由规则绑定起来.Routing Key:路由关键字,exchange根据这个关键字进行消息投递。
vhost:虚拟主机,一个broker里可以有多个vhost，用作不同用户的权限分离。
Producer:消息生产者,就是投递消息的程序.Consumer:消息消费者,就是接受消息的程序.Channel:消息通道,在客户端的每个连接里,可建立多个channel.4.任务分发机制4.1Round-robin dispathching循环分发RabbbitMQ的分发机制非常适合扩展,而且它是专门为并发程序设计的,如果现在load加重,那么只需要创建更多的Consumer来进行任务处理。
4.2Message acknowledgment消息确认为了保证数据不被丢失,RabbitMQ支持消息确认机制,为了保证数据能被正确处理而不仅仅是被Consumer收到,那么我们不能采用no-ack，而应该是在处理完数据之后发送ack.在处理完数据之后发送ack,就是告诉RabbitMQ数据已经被接收,处理完成,RabbitMQ可以安全的删除它了.如果Consumer退出了但是没有发送ack,那么RabbitMQ就会把这个Message发送到下一个Consumer，这样就保证在Consumer异常退出情况下数据也不会丢失.RabbitMQ它没有用到超时机制.RabbitMQ仅仅通过Consumer的连接中断来确认该Message并没有正确处理，也就是说RabbitMQ给了Consumer足够长的时间做数据处理。
如果忘记ack,那么当Consumer退出时,Mesage会重新分发,然后RabbitMQ会占用越来越多的内存.5.Message durability消息持久化要持久化队列queue的持久化需要在声明时指定durable=True;这里要注意,队列的名字一定要是Broker中不存在的,不然不能改变此队列的任何属性.队列和交换机有一个创建时候指定的标志durable,durable的唯一含义就是具有这个标志的队列和交换机会在重启之后重新建立,它不表示说在队列中的消息会在重启后恢复消息持久化包括3部分1. exchange持久化,在声明时指定durable => true hannel.ExchangeDeclare(ExchangeName, "direct", durable: true, autoDelete: false, arguments: null);//声明消息队列，且为可持久化的12.queue持久化,在声明时指定durable => truechannel.QueueDeclare(QueueName, durable: true, exclusive: false, autoDelete: false, arguments: null);//声明消息队列，且为可持久化的13.消息持久化,在投递时指定delivery_mode => 2(1是非持久化).channel.basicPublish("", queueName, MessageProperties.PERSISTENT_TEXT_PLAIN,msg.getBytes()); 1如果exchange和queue都是持久化的,那么它们之间的binding也是持久化的,如果exchange和queue两者之间有一个持久化，一个非持久化,则不允许建立绑定.注意：一旦创建了队列和交换机,就不能修改其标志了,例如,创建了一个non-durable的队列,然后想把它改变成durable 的,唯一的办法就是删除这个队列然后重现创建。
6.Fair dispath 公平分发你可能也注意到了,分发机制不是那么优雅,默认状态下,RabbitMQ将第n个Message分发给第n个Consumer。
n是取余后的,它不管Consumer是否还有unacked Message，只是按照这个默认的机制进行分发.那么如果有个Consumer工作比较重,那么就会导致有的Consumer基本没事可做,有的Consumer却毫无休息的机会,那么,Rabbit是如何处理这种问题呢?通过basic.qos方法设置prefetch_count=1，这样RabbitMQ 就会使得每个Consumer在同一个时间点最多处理一个Message，换句话说,在接收到该Consumer的ack前,它不会将新的Message分发给它channel.basic_qos(prefetch_count=1) 1注意，这种方法可能会导致queue满。
当然，这种情况下你可能需要添加更多的Consumer，或者创建更多的virtualHost来细化你的设计。
7.分发到多个Consumer7.1Exchange先来温习以下交换机路由的几种类型:Direct Exchange:直接匹配,通过Exchange名称+RountingKey来发送与接收消息.Fanout Exchange:广播订阅,向所有的消费者发布消息,但是只有消费者将队列绑定到该路由器才能收到消息,忽略Routing Key.Topic Exchange：主题匹配订阅,这里的主题指的是RoutingKey,RoutingKey可以采用通配符,如:*或#，RoutingKey命名采用.来分隔多个词,只有消息这将队列绑定到该路由器且指定RoutingKey符合匹配规则时才能收到消息;Headers Exchange:消息头订阅,消息发布前,为消息定义一个或多个键值对的消息头,然后消费者接收消息同时需要定义类似的键值对请求头:(如:x-mactch=all或者x_match=any)，只有请求头与消息头匹配,才能接收消息,忽略RoutingKey.默认的exchange:如果用空字符串去声明一个exchange，那么系统就会使用”amq.direct”这个exchange，我们创建一个queue时,默认的都会有一个和新建queue同名的routingKey绑定到这个默认的exchange上去channel.BasicPublish("", "TaskQueue", properties, bytes);1 因为在第一个参数选择了默认的exchange，而我们申明的队列叫TaskQueue，所以默认的，它在新建一个也叫TaskQueue的routingKey，并绑定在默认的exchange上，导致了我们可以在第二个参数routingKey中写TaskQueue，这样它就会找到定义的同名的queue，并把消息放进去。
如果有两个接收程序都是用了同一个的queue和相同的routingKey去绑定direct exchange的话，分发的行为是负载均衡的，也就是说第一个是程序1收到，第二个是程序2收到，以此类推。
如果有两个接收程序用了各自的queue，但使用相同的routingKey去绑定direct exchange的话，分发的行为是复制的，也就是说每个程序都会收到这个消息的副本。
行为相当于fanout类型的exchange。
下面详细来说:7.2 Bindings 绑定绑定其实就是关联了exchange和queue，或者这么说:queue对exchange的内容感兴趣,exchange要把它的Message deliver到queue。
7.3Direct exchangeDriect exchange的路由算法非常简单:通过bindingkey的完全匹配，可以用下图来说明.Exchange和两个队列绑定在一起,Q1的bindingkey是orange，Q2的binding key是black和green.当Producer publish key是orange时,exchange会把它放到Q1上,如果是black或green就会到Q2上,其余的Message 被丢弃.7.4 Multiple bindings多个queue绑定同一个key也是可以的,对于下图的例子,Q1和Q2都绑定了black,对于routing key是black的Message，会被deliver到Q1和Q2，其余的Message都会被丢弃. 7.5 Topic exchange对于Message的routing_key是有限制的，不能使任意的。