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: 异步调⽤，及时获得调⽤结果，具有强⼀致性结果，关⼼业务调⽤处理结果。
- 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是有限制的，不能使任意的。