RabbitMQ实战

1.1、作用

• 解耦：在项目启动之初来预测将来会碰到什么需求是极其困难的。消息中间件在处理过程

  中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，这允许你独

  立地扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束即可

• 冗余〈存储) 有些情况下，处理数据的过程会失败。消息中间件可以把数据进行持久化直

  到它们已经被完全处理，通过这一方式规避了数据丢失风险。在把 个消息从消息中间件中删

  除之前，需要你的处理系统明确地指出该消息己经被处理完成，从而确保你的数据被安全地保

  存直到你使用完毕。

• 扩展性: 因为消息中间件解耦了应用的处理过程，所以提高消息入队和处理的效率是很容

  易的，只要另外增加处理过程即可，不需要改变代码，也不需要调节参数。

• 削峰: 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常

  见。如果以能处理这类峰值为标准而投入资源，无疑是巨大的浪费，使用消息中间件能够使关

  键组件支撑突发访问压力，不会因为突发的超负荷请求而完全崩惯

• 可恢复性: 当系统一部分组件失效时，不会影响到整个系统 消息中间件降低了进程间的

  稿合度，所以即使 个处理消息的进程挂掉，加入消息中间件中的消息仍然可以在系统恢复后

  进行处理

• 顺序保证: 在大多数使用场景下，数据处理的顺序很重要，大部分消息中间件支持一定程

  度上的顺序性。

• 缓冲: 在任何重要的系统中，都会存在需要不同处理时间的元素。消息中间件通过 个缓

  冲层来帮助任务最高效率地执行，写入消息中间件的处理会尽可能快速 该缓冲层有助于控制

  和优化数据流经过系统的速度。

• 异步通信: 在很多时候应用不想也不需要立即处理消息 消息中间件提供了异步处理机制，

  允许应用把 些消息放入消息中间件中，但并不立即处理它，在之后需要的时候再慢慢处理

1.2、消息组成

消息一般可以包含两个部分：消息体（payload）和标签（Label)

• 消息体：消息体一般是一个带有业务逻辑结构的数据，比如一个 JSON 字符串
• 标签：用来表述这条消息，比如一个交换器的名称和一个路由键

消费者连接到 RabbitMQ 服务器，并订阅到队列上。当消费者消费一条消息时，只是消费消息的消息体。在消息路由的过程中，消息的标签会丢弃，存入到队列中的消息只有消息体，消费者也只会消费到消息体，也就不知道消息的生产者是谁，当然消费者也不需要知道

1.3、队列

RabbitMQ中的消息都只能存储在队列中，这一点和Katka相反，Katka 将消息存储在topic (主题)这个逻辑层面，而相对应的队列逻辑只是 topic 实际存储文件中的位移标识。 RabbitMQ 的生产者生产消息并最终投递到队列中，消费者可以从队列中获取消息并消费。

多个消费者可以订阅同一个队列，这时队列中的消息会被平均分摊 CRound-Robin ，即轮询)给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理。

RabbitMQ 不支持队列层面的广播消费，如果需要广播消费，需要在其上进行二次开发，处理逻辑会变得异常复杂，同时也不建议这么做。

1.4、交换机

交换器将消息路由到一个或者多个队列中，如果路由不到，或许会返回给生产者，或许直接丢弃。

生产者将消息发送给交换器时， 需要一个RoutingKey。交换器和队列绑定时需要一个BindingKey。当BindingKey和RoutingKey相匹时， 消息会被路由到对应的队列中。在绑定多个队列到同一个交换器的时候，这些绑定允许使用相同的BindingKey。

BindingKey并不是在所有的情况下都能生效，它依赖于交换器类型。如fanout 类型的交换器就会无视BindingKey，而是将消息路由到所有绑定到该交换器的队列中。

1.5、AMQP协议

RabbitMQ就是AMQP协议的 Erlang 的实现。 AMQP模型架构和RabbitMQ 的模型架构是一样的，生产者将消息发送给交换器，交换器和队列绑定。。当生产者发送消息时所携带的 RoutingKey 与绑定时 BindingKey 匹配时，消息即被存入相应的队列之中，消费者可以订阅相应的队列来获取消息。

AMQP 协议本身包括三层。

• Module Layer: 位于协议最高层，主要定义了一些供客户端调用的命令，客户端可以利用这些命令实现自己的业务逻辑。例如，客户端可以使用 Queue Declare 命令声明一个队列或者使用 Basic.Consume 订阅消费一个队列中的消息。
• Session Layer: 位于中间层，主要负责将客户端的命令发送给服务器，再将服务端的应答返回给客户端，主要为客户端与服务器之间的通信提供可靠性同步机制和错误处理。
• Transport Layer: 位于最底层，主要传输二进制数据流，提供帧的处理、信道复用、错误检测和数据表示等。

2.1、交换器

2.1.1、声明交换器

exchangeDeclare，交换器声明有多个重载方法，这些重载方法都是由下面这个方法中缺省的某些参数构成的。

public Exchange.DeclareOk exchangeDeclare(String exchange , String type , boolean durable , boolean autoDelete , boolean internal, Map arguments) throws IOException ;

• 返回值Exchange.DeclareOk是用来标识成功声明了一个交换器

• exchange：交换器的名称

• type：交换器的类型，常见的如 fanout、direct、topic、headers

• durable: 设置是否持久化，设置为 true 表示持久化， 反之是非持久 。持久化可以将交换器存盘，在服务器重启的时候不会丢失相关信息

• autoDelete：设置是否自动删除， true表示自动删除。自动删除的前提是至少有一个队列或者交换器与这个交换器绑定过，绑定之后所有与这个交换器绑定的队列或者交换器都与此解绑。全部解绑后该交换器自动删除。

  • 解绑后，即使交换器是持久化的，也会自动删除

  • 当有未解绑的队列或交换器时，重启rabbitmq服务、或者与此交换器连接的客户端都断开时，RabbitMQ都不会删除该交换器

• internal：设置是否是内置的。如果设置为 true，则表示是内置的交换器，客户端程序无法直接发送消息到这个交换器中，只能通过交换器路由到交换器这种方式。

• argument 其他一些结构化参数。

2.1.2、删除交换器

public Exchange.DeleteOk exchangeDelete(String exchange, boo1ean ifUnused) throws IOException;

• exchange：表示交换器的名称
• ifUnused： 设置是否在交换器没有被使用的情况下删除，如果 isUnused设置为 true，则只有在此交换器没有被使用的情况下才会被删除。如果设置 false，则无论如何这个交换器都要被删除。

2.1.2、检测交换器是否存在

public Exchange.DeclareOk exchangeDeclarePassive(String name) throws IOException;

• 如果存在则正常返回DeclareOk对象
• 如果不存在则抛出异常：404 channel exception ，同时 Channel 也会被关闭。

2.2、队列

2.2.1、声明队列

Queue.DeclareOk queueDeclare() throws IOException;

• 默认创建一个由RabbitMQ命名的(类似amq.gen-LhQzlgv3GhDOv8PIDabOXA的名称，这种队列也称之为匿名队列〉、排他的、自动删除的、非持久化的队列

Queue.DeclareOk queueDeclare(String queue, boolean durable, boolean exclusive, 
boolean autoDelete, Map arguments) throws IOException;

• queue：队列的名称

• durable: 设置是否持久化。为true则设置队列为持久化。持久化的队列会存盘，在服务器重启的时候可以保证不丢失相关信息

• exclusive：设置是否排他。为true则设置队列为排他的。如果一个队列被声明为排他队列，该队列仅对首次声明它的连接可见，并在连接断开时自动删除

  • 排他队列是基于连接( Connection) 可见的，同一个连接的不同信道 (Channel)是可以同时访问同一连接创建的排他队列
  • "首次"是指如果一个连接己经声明了一个排他队列，其他连接是不允许建立同名的排他队列的，这个与普通队列不同（非排他队列可重复声明，但只创建一个）
  • 即使排他队列是持久化的，一旦声明该队列的连接关闭或者客户端退出，该排他队列都会被自动删除，这种队列适用于一个客户端同时发送和读取消息的应用场景

• autoDelete: 设置是否自动删除。为true则设置队列为自动删除（必须有至少一个消费者连接再断开后才能自动删除）

  • 自动删除的前提是：至少有一个消费者连接到这个队列，之后所有与这个队列连接的 消费者 都断开时，才会自动删除。即使该队列是持久化的也会删除
  • 重启服务不会自动删除

• argurnents: 设置队列的其他一些参数

2.2.2、清空队列消息

public Queue.PurgeOk queuePurge(String queue) throws IOException;

• queue：表示队列名称

2.2.2、删除队列

public Queue.De1eteOk queueDe1ete(String queue ,boo1ean ifUnused, boolean ifEmpty) 
throws IOExcept on;

• queue：表示队列名称
• ifUnused： 设置是否在队列没有被使用的情况下删除，如果 isUnused设置为 true，则只有在此队列没有被使用的情况下才会被删除。如果设置 false，则无论如何这个队列都要被删除
• ifEmpty：设置为true表示在队列为空(队列里面没有任何消息堆积)的情况下才能够删除

2.1.2、检测队列是否存在

public Queue.Dec1areOk queueDec1arePassive(String queue) throws IOException;

• 如果存在则正常返回DeclareOk对象
• 如果不存在则抛出异常：404 channel exception ，同时 Channel 也会被关闭

2.3、队列绑定交换器

2.3.1、绑定

public Queue.BindOk queueBind(String queue , String exchange , String routingKey, 
Map arguments) throws IOExcept on;

• queue: 队列名称

• exchange: 交换器的名称

• routingKey: 用来绑定队列和交换器的路由键

• argument: 定义绑定的一些参数

2.3.2、解绑

public Queue.UnbindOk queueUnbind (String queue , String exchange , String routingKey, 
Map arguments) throws IOException;

2.4、交换器绑定交换器

public Exchange.BindOk exchangeBind(String destination, String source , String 
routingKey, Map arguments) throws IOException ;

• destination：目标路由器名称（接收转发）

• source：资源路由器（转发消息）

• routingKey：用来绑定交换器和交换器的路由键

• argument: 定义绑定的一些参数

示例代码

// 声明资源交换器（类型可不同）
channel.exchangeDeclare( "source" , "direct" , false , true , null) ;
// 声明目标路由器（类型可不同）
channel.exchangeDeclare( "destination" , "fanout" , false , true , null);
// 交换器绑定交换器
channel.exchangeBind( "destination" , "source" , "exKey");
// 声明队列
channel.queueDeclare( "queue" , false , false , true , null);
// 队列绑定交换器
channel.queueBind("queue" , "destination"); 
// 发送消息
channel.basicPublish("source" , "exKey" , null , "exToExDemo".getBytes ());

2.5、何时创建队列

• RabbitMQ的消息存储在队列中，交换器并不真正耗费服务器的性能，而队列会

• 如果发送消息的交换器没有绑定任何队列，那么消息将会丢失

• 交换器绑定了某个队列，但是发送消息时的路由键无法与现存的队列匹配，那么消息也会丢失

• 使用预先分配创建队列资源的静态方式还是