Spring AMQP 1.6完整参考指南

-第一部分

原文：http://docs.spring.io/spring-amqp/docs/1.6.0.RELEASE/reference/html/

1. 前言

 

Spring AMQP项目将其核心Spring概念应用于基于AMQP消息解决方案的开发中．我们提供了一个发送和接收消息的高级抽象模板．同时，我们也提供了消息驱动POJO的支持.这些包有助于AMQP资源的管理，从而提升依赖注入和声明式配置的使用. 在所有这些情况中，你会发现与Spring Framework对JMS支持是相似的. 对于其它项目相关的信息，可访问Spring AMQP项目主页

2. 介绍

本参考文档的第一部分是对Spring AMQP的高层次以及底层的概念的讲述，还有一些可使你尽快上手运行的代码片断.

2.1 快速浏览

2.1.1 介绍

5分钟开启Spring AMQP的旅行.

前提:

安装和运行RabbitMQ broker (http://www.rabbitmq.com/download.html). 然后获取spring-rabbit JAR 以及其依赖包 - 最简单的方式是在你的构建工具中声明依赖，如. 对于Maven来说:

org.springframework.amqp

spring-rabbit

1.6.0.RELEASE

对于gradle:

compile 'org.springframework.amqp:spring-rabbit:1.6.0.RELEASE'

 

兼容性

由于默认的Spring Framework 版本依赖是4.2.x, Spring AMQP 一般来说可兼容早期版本的Spring Framework.但基于注解的监听器和RabbitMessagingTemplate 需要Spring Framework 4.1＋.

类似地,默认的amqp-client 版本是3.6.x，但framework 兼容3.4.0＋.但依赖于新客户端版本的功能将无法使用．注意，这里指的是java client library; 一般来说，对于老版本的broker也可以工作.

非常非常快速

 

使用纯java来发送和接收消息：

ConnectionFactory connectionFactory = new CachingConnectionFactory(); 
AmqpAdmin admin = new RabbitAdmin(connectionFactory); 
admin.declareQueue(new Queue("myqueue")); 
AmqpTemplate template = new RabbitTemplate(connectionFactory); 
template.convertAndSend("myqueue", "foo"); 
String foo = (String) template.receiveAndConvert("myqueue");

注意，在原生的Java Rabbit client中也有一个ConnectionFactory. 在上面的代码中，我们使用的是Spring 抽象. 我们依赖的是broker中的默认交换器 (因为在发送操作中没有指定交换器）,以及默认绑定(通过其名称作为路由键将所有队列绑定到默认交换器中）.那些行为是由AMQP规范来定义的．

使用 XML配置

 

同上面的例子一样，只不过将外部资源配置到了XML:

ApplicationContext context =new GenericXmlApplicationContext("classpath:/rabbit-context.xml"); 
AmqpTemplate template = context.getBean(AmqpTemplate.class); 
template.convertAndSend("myqueue", "foo"); 
String foo = (String) template.receiveAndConvert("myqueue");

 
   
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 
   
xmlns:rabbit="http://www.springframework.org/schema/rabbit"
 
   
xsi:schemaLocation="http://www.springframework.org/schema/rabbit            
http://www.springframework.org/schema/rabbit/spring-rabbit.xsd            
http://www.springframework.org/schema/beans            
http://www.springframework.org/schema/beans/spring-beans.xsd">
 
   
 
   
 
   
 
   
 
   
 
   
 声明会默认自动查找类型为Queue, Exchange 和Binding的bean, 并宣称他们代表的broker的用户, 因此在简单的Java driver中没有必要明确的使用那个bean. 
 有大量的选项来配置XML schema 中的组件属性- 你可以使用xml编辑的自动完成功能来探索它们并查看它们的相关文档.
 
    
   
使用 Java 配置
 
   

  
 
   
同样的例子可使用java来外部配置：
 
   
ApplicationContext context = new AnnotationConfigApplicationContext(RabbitConfiguration.class);
AmqpTemplate template = context.getBean(AmqpTemplate.class);
template.convertAndSend("myqueue", "foo");
String foo = (String) template.receiveAndConvert("myqueue");

........

@Configuration
 
   
public　class RabbitConfiguration {

    @Bean
 
   
　public ConnectionFactory connectionFactory() {
        returnnew CachingConnectionFactory("localhost");
    }

    @Bean
 
   
　public AmqpAdmin amqpAdmin() {
 
   
returnnew RabbitAdmin(connectionFactory());
　}

    @Bean
 
   
　public RabbitTemplate rabbitTemplate() {
        returnnew RabbitTemplate(connectionFactory());
    }

    @Bean
 
   
　public Queue myQueue() {
       returnnew Queue("myqueue");
    }
}
 
    
   
2.2 新特性
 
    
   
2.2.1从１.５到1.6的变化
 
    
   
测试支持
 
    
   
 
 
   
 
 
   
提供了一个新的测试支持包. 参考Section 3.4, “Testing Support” 来了解更多信息．
 
    
   
Builder
 
    
   
 
 
   
 
 
   
现在Builders提供了更方便的API来配置Queue 和 Exchange 对象. 参考the section called “Builder API for Queues and Exchanges” 来了解更多信息.
 
    
   
命名空间变化
 
   
连接工厂
 
    
   
 
 
   
 
 
   
为连接工厂bean声明增加了thread-factory, 例如，以amqp-client包创建的线程命名．参考Section 3.1.2, “Connection and Resource Management” 来了解更多信息.
 
   
当使用CacheMode.CONNECTION时，现在你可以限制允许连接的总数了. 参考Section 3.1.2, “Connection and Resource Management” 来了解更多信息.
 
   
Queue 定义
 
    
   
 
 
   
 
 
   
现在为匿名队列提供了命名策略; 参考 the section called “AnonymousQueue” 来了解更多信息.
 
    
   
监听器容器变化
 
   
空闲消息监听器检测
 
    
   
 
 
   
 
 
   
当空闲时，现在可以配置监听器容器来发布ApplicationEvent 事件了. 参考the section called “Detecting Idle Asynchronous Consumers”来了解更多信息.
  
 
   
不匹配的队列检测
 
    
   
 
 
   
 
 
   
默认情况下，当监听器容器启动时，如果探测到了队列的mismatched属性或参数,容器会记录异常但会继续监听.现在容器有了一个mismatchedQueuesFatal 属性，当启动时存在问题的话，这可以阻止容器(以及上下文)启动．如果随后检测到问题，它也会停止容器,如从连接故障中恢复. 参考Section 3.1.15, “Message Listener Container Configuration” 来了解更多信息.
 
   
监听器容器日志
 
    
   
 
 
   
 
 
   
现在监听器容器提供了它的beanName 给内部 SimpleAsyncTaskExecutor 作为threadNamePrefix.对于日志分析非常有用.
 
   
默认错误处理器
 
    
   
 
 
   
 
 
   
默认错误处理器(ConditionalRejectingErrorHandler) 现在认为无可挽救的@RabbitListener 异常是致命的. 参考Section 3.1.13, “Exception Handling” 来了解更多信息.
 
    
   
AutoDeclare 与 RabbitAdmins
 
    
   
 
 
   
 
 
   
参考 Section 3.1.15, “Message Listener Container Configuration” (autoDeclare) 来查看在应用程序上下文使用RabbitAdmin s的语法变化.
 
    
   
AmqpTemplate: receive 与 timeout
 
    
   
 
 
   
 
 
   
AmqpTemplate 和它的RabbitTemplate实现引入了许多新的带有timeout的receive() 方法. 参考the section called “Polling Consumer”  来了解更多信息.
 
    
   
AsyncRabbitTemplate
 
    
   
 
 
   
 
 
   
引入了新的AsyncRabbitTemplate. 此模块提供了许多发送和接收的方法,其返回值为ListenableFuture,此后可通过它来同步或异步地获取结果. 参考 the section called “AsyncRabbitTemplate” 来了解更多信息
 
    
   
RabbitTemplate 变化
 
    
   
 
 
   
 
 
   
1.4.1 在broker支持时，引入了Direct reply-to 的能力;它比使用临时队列来回应更高效. 这个版本允许你覆盖这种默认行为，通常设置useTemporaryReplyQueues属性为true来使用临时队列. 参考 the section called “RabbitMQ Direct reply-to” 来了解更多信息.
 
   
RabbitTemplate 现在支持user-id-expression (userIdExpression 当使用Java配置时). 参考See Validated User-ID RabbitMQ documentationand the section called “Validated User Id” 来了解更多信息.
 
    
   
消息属性
 
   
CorrelationId
 
    
   
 
 
   
 
 
   
correlationId 消息属性现在可以是字符串了．参考the section called “Message Properties Converters” 来了解更多信息.
 
   
长字符串头
 
    
   
 
 
   
 
 
   
以前,DefaultMessagePropertiesConverter 会将头转换成(其头长度不超过长字符串限制(默认为1024) ）成一个DataInputStream (实际上它只是引用LongString的 DataInputStream). 
 在输出时，这个头不会进行转换(除了字符串, 例如. 在java.io.DataInputStream@1d057a39 上调用toString()方法).
 
   
在这个版本中, Long LongString 默认作为 LongString s ;你可以通过其getBytes[], toString(), 或 getStream()方法来访问它的内容. 更大的输入LongString 现在也会在输出上正确转换了．
 
   
参考 the section called “Message Properties Converters” 来了解更多信息.
 
   
Inbound Delivery Mode
 
    
   
 
 
   
 
 
   
deliveryMode 属性不再映射MessageProperties.deliveryMode;这是为了避免意外传播，如果同一个MessageProperties 对象用来发送出站消息. 
 相反, 入站deliveryMode 头映射为MessageProperties.receivedDeliveryMode.
 
   
参考 the section called “Message Properties Converters” 来了解更多信息.
 
   
当使用注解endpoints时,头将在名为AmqpHeaders.RECEIVED_DELIVERY_MODE的头中提供.
 
   
参考the section called “Annotated Endpoint Method Signature” 来了解更多信息.
 
   
Inbound User ID
 
    
   
 
 
   
 
 
   
user_id 属性不再映射MessageProperties.userId; 这是为了避免意外传播，如果同一个MessageProperties 对象用来发送出站消息.相反, 入站userId 头会映射到MessageProperties.receivedUserId.
 
   
参考 the section called “Message Properties Converters” 来了解更多信息.
 
   
当使用注解endpoints时,头将在名为AmqpHeaders.RECEIVED_USER_ID的头中提供.
 
   
参考 the section called “Annotated Endpoint Method Signature”  来了解更多信息.
 
    
   
RabbitAdmin 变化
 
   
Declaration Failures
 
    
   
 
 
   
 
 
   
之间,ignoreDeclarationFailures 标志只在channel上发生IOException 才会生效(如未匹配参数). 现在它对于任何异常都可以生效(如：TimeoutException). 
 此外,无论何时声明失败，都会发布DeclarationExceptionEvent.RabbitAdmin 最后声明事件将作为属性lastDeclarationExceptionEvent也是可用的. 
 
   
参考 Section 3.1.10, “Configuring the broker” 来了解更多信息.
 
    
   
@RabbitListener Changes
 
   
Multiple Containers per Bean
 
    
   
 
 
   
 
 
   
当使用Java 8＋,可以添加多个@RabbitListener 注解到 @Bean 类或它们的方法上.当使用Java 7-,你可以使用 @RabbitListeners 容器注解来提供同样的功能. 
 参考the section called “@Repeatable @RabbitListener” 来了解更多信息.
 
   
@SendTo SpEL Expressions
 
    
   
 
 
   
 
 
   
@SendTo for routing replies with no replyTo property can now be SpEL expressions evaluated against the request/reply. 
 
   
参考 the section called “Reply Management”来了解更多信息.
 
   
@QueueBinding Improvements
 
    
   
 
 
   
 
 
   
现在你可以在@QueueBinding 注解中为queues, exchanges 和bindings 指定参数. 
 
   
Header交换器可通过@QueueBinding来支持. 
 
   
参考the section called “Annotation-driven Listener Endpoints” 来了解更多信息.
 
    
   
延迟消息交换器(Delayed Message Exchange)
 
    
   
 
 
   
 
 
   
Spring AMQP 现在有了第一个支持RabbitMQ Delayed Message Exchange 插件. 参考Section 3.1.11, “Delayed Message Exchange” 来了解更多信息.
 
    
   
交换器内部标志(Exchange internal flag)
 
    
   
 
 
   
 
 
   
任何Exchange 定义现在都可标记为internal ，当声明交换器时，RabbitAdmin 会将值传递给broker. 
 
   
参考 Section 3.1.10, “Configuring the broker”来了解更多信息.
 
    
   
CachingConnectionFactory 变化
 
   
CachingConnectionFactory Cache Statistics
 
    
   
 
 
   
 
 
   
 CachingConnectionFactory 现在通过运行时和JMX提供了cache属性.参考the section called “Runtime Cache Properties”  来了解更多信息．
 
   
访问底层RabbitMQ连接工厂
 
    
   
 
 
   
 
 
   
添加了一个新的getter方法来获取底层factory.这是很有用的，例如，可以添加自定义属性. 参考 Section 3.1.3, “Adding Custom Client Connection Properties” 来了解更多信息．
 
   
Channel Cache
 
    
   
 
 
   
 
 
   
默认的channel 缓存大小已从１增加到了25. 参考Section 3.1.2, “Connection and Resource Management”来了解更多信息．
 
   
此外, SimpleMessageListenerContainer 不再设置缓存大小至少要与concurrentConsumers的数目一样大 - 这是多余的,因为容器消费者channels是不会缓存的.
 
    
   
RabbitConnectionFactoryBean
 
    
   
 
 
   
 
 
   
factory bean现在暴露了一个属性来将client连接属性添加到由工厂产生的连接中．
 
    
   
Java 反序列化(Deserialization）
 
    
   
 
 
   
 
 
   
当使用Java反序列化时，现在允许配置类的白名单. 如果你从不可信来源接收消息，考虑创建白名单是很重要的. 参考 the section called “Java Deserialization” 来了解更多信息．
 
    
   
JSON MessageConverter
 
    
   
 
 
   
 
 
   
改善了JSON消息转换器，现在允许消费消息在消息头中可以没有类型(type)信息. 参考the section called “Message Conversion for Annotated Methods” 和 the section called “Jackson2JsonMessageConverter”来了解更多信息．
 
    
   
Logging Appenders
 
   
Log4j2
 
    
   
 
 
   
 
 
   
加入了log4j2 appender,此appenders现在可配置addresses 属性来连接broker集群.
 
   
Client 连接属性
 
    
   
 
 
   
 
 
   
现在你可以向RabbitMQ连接中加入自定义连接属性了．
 
   
参考Section 3.2, “Logging Subsystem AMQP Appenders” 来了解更多信息．
 
    
   
2.2.2 早期版本
 
    
   
 
 
   
 
 
   
参考Section A.2, “Previous Releases” 来了解早期版本的变化.
 
   
 
 
    
   
-第二部分
 
    
   
3. 参考
 
   
这部分参考文档详细描述了组成Sring AMQP的各种组件. main chapter 涵盖了开发AMQP应用程序的核心类. 这部分也包含了有关示例程序的章节．
 
    
   
3.1 使用 Spring AMQP
 
   
在本章中,我们将探索接口和类，它们是使用Spring AMQP来开发应用程序的必要组件 ．
 
    
   
3.1.1 AMQP 抽象
 
    
   
介绍
 
   
 
 
   
Spring AMQP 由少数几个模块组成, 每个都以JAR的形式来表现.这些模块是: spring-amqp和spring-rabbit. spring-amqp模块包含org.springframework.amqp.core 包. 
 在那个包中,你会找到表示AMQP核心模块的类. 我们的目的是提供通用的抽象，不依赖于任何特定中间件的实现或AMQP客户端库。
 最终用户代码将更具有移植性，以便跨供应商实现，因为它们可以对抽象层开发。这些抽象是使用broker的特定模块实现的，如spring-rabbit。
 目前只有一个RabbitMQ实现；而对于抽象的验证，除了RabbitMQ外,也已经在.Net平台上使用Apache Qpid得到了验证。
 由于AMQP原则上工作于协议层次，RabbitMQ客户端可以在任何支持相同的协议版本的broker中使用，但目前我们没有测试其它任何broker。
 
   
这里的概述假设你已经熟悉了AMQP规范.如果你还没有，那么你可以查看第5章,其它资源中列举的资源．
  
 
    
   
Message
 
    
   
 
 
   
 
 
   
AMQP　0-8 和0-9-1 规范没有定义一个消息类或接口.相反，当执行basicPublish()这样的操作的时候, 内容是以字节数组参数进行传递的，其它额外属性也是以单独参数进行传递的. Spring AMQP定义了一个 Message 类来作为AMQP领域模型表示的一部分.Message类的目的是在单个实例中简化封装消息体(body)和属性(header),这样API就可以变得更简单. Message类的定义相当简单．
  
 
   
public　class Message {

    private　final MessageProperties messageProperties;

    private　final　byte[] body;

    public Message(byte[] body, MessageProperties messageProperties) {
        this.body = body;
        this.messageProperties = messageProperties;
    }

    public　byte[] getBody() {
        returnthis.body;
    }

    public MessageProperties getMessageProperties() {
        returnthis.messageProperties;
    }
}
 
   
MessageProperties 接口定义了多个共同属性，如messageId, timestamp, contentType 等等. 那些属性可以通过调用setHeader(String key, Object value) 方法使用用户定义头(user-defined headers)来扩展.

  
 
    
   
Exchange
 
    
   
 
 
   
Exchange 接口代表的是AMQP Exchange,它是生产者发送消息的地方.broker虚拟主机中的交换器名称都是唯一的，同时还有少量的其它属性:
 
   
public　interface Exchange {

    String getName();

    String getExchangeType();

    boolean isDurable();

    boolean isAutoDelete();

    Map getArguments();

}
 
   
正如你所看到的, Exchange还有一个type (它是在ExchangeTypes中定义的常量). 基本类型是: Direct, Topic, Fanout,和Headers.
 在核心包中，你可以找到每种类型的Exchange 接口实现.这些交换器类型会在处理队列绑定时，行为有所不同．
 例如,Direct交换器允许队列以固定路由键进行绑定(通常是队列的名称）.
 Topic交换器支持使用路由正则表达式(*通配符明确匹配一个，而#通配符可匹配０个或多个）. 
 
   
Fanout交换器会把消息发布到所有绑定到它上面的队列而不考虑任何路由键.
 
   
关于交换器类型的更多信息，查看Chapter 5, Other Resources.

 AMQP规范还要求任何broker必须提供一个默认的无名字的(空字符串)Direct交换器.所有声明的队列都可以用它们的名字作为路由键绑定到默认交换器中. 在Section 3.1.4, “AmqpTemplate”你会了解到更多关于在Sring AMQP中使用默认交换器的使用情况.
  
 
    
   
Queue
 
    
   
 
 
   
Queue 代表的是消费者接收消息的组件. 像各种各样的 Exchange 类，我们的实现目标是作为核心AMQP类型的抽象表示.
 
   
public　class Queue  {

    private　final String name;

    private　volatile　boolean durable;

    private　volatile　boolean exclusive;

    private　volatile　boolean autoDelete;

    private　volatile Map arguments;

    /**
     * The queue is durable, non-exclusive and non auto-delete.
     *
     * @param name the name of the queue.
     */
 
   
　public Queue(String name) {
        this(name, true, false, false);
    }

    // Getters and Setters omitted for brevity

}
 
   
注意，构造器需要接受队列名称作为参数．根据实现, admin template可能会提供生成独特队列名称的方法.这些队列作为回复地址或用于临时情景是非常有用的.
 基于这种原因,自动生成队列的exclusive和 autoDelete 属性都应该设置为true.
 
   
参考 Section 3.1.10, “Configuring the broker” 来了解关于使用命名空间来声明队列，包括队列参数的详细情况.
 
    
   
Binding
 
    
   
 
 
   
生产者发送消息到Exchange，而消费者将从Queue中获取消息,连接Queues与Exchanges之间的绑定对于通过消息来连接生产者和消费者是非常关键的.
 在Spring AMQP中,我们定义了一个 Binding 类来表示这些连接. 让我们重新回顾一下绑定队列和交换器的操作.
 
   
你可以使用固定的路由键来绑定 Queue 到 DirectExchange上.
 
   
new Binding(someQueue, someDirectExchange, "foo.bar")
 
   
你可以使用路由正则表达式来绑定Queue到TopicExchange上.
 
   
new Binding(someQueue, someTopicExchange, "foo.*")
 
   
你可以不使用路由键来绑定Queue到FanoutExchange上.
 
   
new Binding(someQueue, someFanoutExchange)
 
   
我们还提供了BindingBuilder来方便操作.
 
   
Binding b = BindingBuilder.bind(someQueue).to(someTopicExchange).with("foo.*");
 
   
上面展示的BindingBuilder 类很清晰,但如果为bind()方法使用静态导入，这种形式将工作得更好.
 
   
本身来说,Binding类的实例只能一个connection中持有数据.换句话说,它不是一个活力(active)组件.
 但正如在后面Section 3.1.10, “Configuring the broker”看到的, Binding实例可由AmqpAdmin 类来触发broker上的绑定操作.
 同样，在同一个章节中，你还会看到Binding实例可在@Configuration类中使用Spring　@Bean风格来定义. 
 还有方便的基类来简化生成AMQP相关bean定义和识别队列，交换器，绑定的方法，这样当AMQP broker运行程序启动时，就可以得到声明.
 
   
AmqpTemplate 也在核心包中定义．作为涉及AMQP消息的主要组件, 会在它自己的章节中进行详细介绍(参考Section 3.1.4, “AmqpTemplate”).
 
    
   
3.1.2 连接和资源管理
 
    
   
介绍
 
    
   
 
 
   
虽然我们在前面章节中描述的AMQP模型是通用的，适用于所有实现,但当我们说到资源管理时，其细节是针对特定broker实现的.因此，在这个章节中,我们只关注我们的"spring-rabbit"模块，因为到现在为止，RabbitMQ是唯一支持的实现.
 
   
RabbitMQ broker中用于管理连接的中心组件是ConnectionFactory 接口. ConnectionFactory实现的责任是提供一个org.springframework.amqp.rabbit.connection.Connection 的实例，它包装了com.rabbitmq.client.Connection. 
 我们提供的唯一具体实现提CachingConnectionFactory,默认情况下，会建立应用程序可共享的单个连接代理.连接共享是可行的，因为在AMQP处理消息的工作单位实际是 "channel" (在某些方面，这类似于JMS中Connection 和 Sessionin的关系).
 你可以想象，连接实例提供了一个createChannel方法。CachingConnectionFactory 实现支持这些channels的缓存,它会基于它们是否是事务的来单独维护其缓存． 
 当创建CachingConnectionFactory的实例时, hostname 可通过构造器来提供，username 和password　属性也可以提供.如果你想配置channel缓存的大小(默认是25),你可以调用setChannelCacheSize()方法.
 
   
从1.3版本开始,CachingConnectionFactory 也可以同channel一样，配置缓存连接.在这种情况下每次调用createConnection() 都会创建一个新连接(或者从缓存中获取空闲的连接).
 关闭连接会将其返回到缓存中(如果还没有达到缓存大小的话).在这些连接上创建的Channels同样也会被缓存. 单独连接的使用在某些环境中是有用的，如从HA 集群中消费, 连接负载均衡器,连接不同的集群成员.设置cacheMode 为 CacheMode.CONNECTION.
 
   
这不会限制连接的数目，它用于指定允许空闲打开连接的数目.

 从１.5.5版本开始,提供了一个新属性connectionLimit.当设置了此属性时，它会限制连接的总数目，当达到限制值时，将channelCheckoutTimeLimit 来等待空闲连接.如果时间超时了，将抛出AmqpTimeoutException.

 重要
 
   
当缓存模式是CONNECTION时, 队列的自动声明等等 (参考 the section called “Automatic Declaration of Exchanges, Queues and Bindings”) 将不再支持.
 
   
 
 
   
此外，在写作的时候，rabbitmq-client 包默认为每个连接(５个线程)创建了一个固定的线程池. 当需要使用大量连接时，你应该考虑在CachingConnectionFactory定制一个executor. 然后，同一个executor会用于所有连接，其线程也是共享的．  
 executor的线程池是没有界限的或按预期使用率来设置(通常, 一个连接至少应该有一个线程）.如果在每个连接上创建了多个channels，那么池的大小会影响并发性,因此一个可变的线程池executor应该是最合适的.
 
   
 
 
   
理解缓存大小不是限制是很重要的, 它仅仅是可以缓存的通道数量.当说缓存大小是１０时，在实际使用中，其实可以是任何数目的通道． 如果超过10个通道被使用，他们都返回到高速缓存，10个将在高速缓存中，其余的将物理关闭。
 
   
从1.6版本开始,默认通道缓存大小从１增加到了25. 在高容量,多线程环境中，较小的缓存意味着通道的创建和关闭将以很高的速率运行.加大默认缓存大小可避免这种开销.
 你可以监控通道的使用情况(通过RabbitMQ Admin UI） ，如果看到有很多通道在创建和关闭，你可以增大缓存大小.缓存只会增长按需（以适应应用程序的并发性要求），所以这个更改不会影响现有的低容量应用程序。
 
   
从1.4.2版本开始,CachingConnectionFactory 有一个channelCheckoutTimeout属性. 当此属性的值大于０时，channelCacheSize 会变成连接上创建通道数目的限制.
 如果达到了限制,调用线程将会阻塞，直到某个通道可用或者超时, 在后者的情况中，将抛出AmqpTimeoutException 异常.
 
   
在框架(如．RabbitTemplate)中使用的通道将会可靠地返回到缓存中.如果在框架外创建了通道 (如.直接访问connection(s)并调用createChannel()),你必须可靠地返回它们(通过关闭),也许需要在 finally 块中以防止耗尽通道.
 
   
CachingConnectionFactory connectionFactory = new CachingConnectionFactory("somehost");
connectionFactory.setUsername("guest");
connectionFactory.setPassword("guest");

Connection connection = connectionFactory.createConnection();
 
   
当使用XML时,配置看起来像下面这样:
 
   
 
   
class="org.springframework.amqp.rabbit.connection.CachingConnectionFactory">
 
   
 
   
 
   
 
   
 
   
这里也有一个 SingleConnectionFactory 实现，它只能用于框架的单元测试代码中.它比CachingConnectionFactory 简单，因为它不会缓存通道,由于其缺乏性能和韧性，它不打算用于简单的测试以外的实际使用. 
 如果基于某些原因，你需要自己来实现ConnectionFactory ，AbstractConnectionFactory 基类提供了一个非常好的起点．
 
   
ConnectionFactory 可使用rabbit命名空间来快速方便的建立：
 
   
 
   
在多数情况下，这是很好的，因为框架会为你选择最好的默认值.创建的实例会是CachingConnectionFactory.要记住，默认的缓存大小是25.如果你想缓存更多的通道，你可以设置channelCacheSize 属性值.在XML中，它看起来像下面这样:
 
   
 
   
class="org.springframework.amqp.rabbit.connection.CachingConnectionFactory">
 
   
 
   
 
   
 
   
 
   
 
   
在命名空间中，你也可以添加channel-cache-size 属性:
 
   
 
   
默认的缓存模式是CHANNEL, 但你可以使用缓存连接来替换;在这种情况下，我们会使用connection-cache-size:
 
   
 
   
Host 和 port 属性也可以在命名空间中提供：
 
   
 
   
此外，如果运行集群环境中，使用addresses属性.
 
   
 
   
下面是一个自定义的线程工厂，其前辍线程名称为rabbitmq-.
 
   
 
   
 
   
 
   
 
    
   
配置底层客户端连接工厂
 
    
   
 
 
   
CachingConnectionFactory 使用的是 Rabbit client ConnectionFactory的实例; 当在CachingConnectionFactory设置等价属性时，许多属性(host, port, userName, password, requestedHeartBeat, connectionTimeout) 来传递. 
 要设置其它属性(例如clientProperties),可定义一个rabbit factory 的实例，并使用CachingConnectionFactory的适当构造器来提供引用. 
 当使用上面提到的命名空间时，要在connection-factory属性中提供一个工厂的引用来配置. 为方便起见，提供了一个工厂，以协助在一个Spring应用程序上下文中配置连接工厂，在下一节讨论。
 
   
 
    
   
RabbitConnectionFactoryBean 和配置SSL
 
    
   
 
 
   
从1.4版本开始, 提供了一个便利的RabbitConnectionFactoryBean 类通过依赖注入来配置底层客户端连接工厂的SSL属性.其它设置简单地委派给底层工厂．以前你必须以编程方式配置SSL选项。
 
   
 
   
 
   
 
   
 
   
 
   
参考 RabbitMQ Documentation 来了解关于配置SSL的更多信息. 省略的keyStore 和 trustStore 配置将在无证书验证的情况下，通过SSL来连接. Key和trust store 配置可以按如下提供：
 
   
sslPropertiesLocation 属性是一个Spring Resource ，它指向一个包含下面key的属性文件：
 
   
keyStore=file:/secret/keycert.p12
trustStore=file:/secret/trustStore
keyStore.passPhrase=secret
trustStore.passPhrase=secret
 
   
keyStore 的 truststore 是指向store的 Spring Resources .通常情况下，这个属性文件在操作系统之下安全的，应用程序只能读取访问.
 
   
从Spring AMQP １.５版本开始，这些属性可直接在工厂bean上设置.如果同时提供了discrete和 sslPropertiesLocation 属性, 后者属性值会覆盖discrete值.
 
    
   
路由连接工厂
 
    
   
 
 
   
从1.3版本开始,引入了AbstractRoutingConnectionFactory.这提供了一种机制来配置多个ConnectionFactories的映射，并通过在运行时使用lookupKey来决定目标ConnectionFactory. 
 
   
通常,实现会检查线程绑定上下文. 为了方便, Spring AMQP提供了SimpleRoutingConnectionFactory, 它会从SimpleResourceHolder中获取当前线程绑定的lookupKey:
 
   
 
   
 
   
 
   
　
 
   
 
   
 
   
 
   
 
   
 
   
public　class MyService {

	@Autowired
 
   
　　private RabbitTemplate rabbitTemplate;

	public  void service(String vHost, String payload) {
		SimpleResourceHolder.bind(rabbitTemplate.getConnectionFactory(), vHost);
		rabbitTemplate.convertAndSend(payload);
		SimpleResourceHolder.unbind(rabbitTemplate.getConnectionFactory());
	}

}
 
   
在使用资源后，对其进行解绑是很重要的.更多信息参考AbstractRoutingConnectionFactory的JavaDocs.
 
   
从1.4版本开始, RabbitTemplate 支持SpEL sendConnectionFactorySelectorExpression 和receiveConnectionFactorySelectorExpression 属性, 
 它会在每个AMQP 协议交互操作(send, sendAndReceive, receiveor receiveAndReply)进行评估, 为提供的AbstractRoutingConnectionFactory类解析lookupKey值. 
 Bean 引用,如"@vHostResolver.getVHost(#root)" 可用于表达式中.对于send 操作,  要发送的消息是根评估对象;对于receive操作, queueName 是根评估对象.
 
   
路由算法为:如果selector 表达式为null,或等价于null,或提供的ConnectionFactory 不是AbstractRoutingConnectionFactory的实例,根据提供的ConnectionFactory 实现，
 所有的工作都按之前的进行.同样的结果也会发生：如果评估结果不为null,但对于lookupKey 无目标ConnectionFactory，且 the AbstractRoutingConnectionFactory 使用lenientFallback = true进行了配置. 
 当然，在AbstractRoutingConnectionFactory 的情况下，它会基于determineCurrentLookupKey()的路由实现来进行回退. 但,如果lenientFallback = false, 将会抛出 IllegalStateException 异常.
 
   
Namespace 在组件中也支持send-connection-factory-selector-expression 和receive-connection-factory-selector-expression属性．
 
   
也是从1.4版本开始, 你可以在SimpleMessageListenerContainer配置路由连接工厂. 在那种情况下，队列名称的列表将作为lookup key.例如,如果你在容器中配置setQueueNames("foo", "bar"),lookup key将是"[foo,bar]" (无空格).
 
   
 
 
   
-第三部分
 
    
   
Queue Affinity 和 LocalizedQueueConnectionFactory
 
   
当在集群中使用HA队列时,为了获取最佳性能,可以希望连接到主队列所在的物理broker. 虽然CachingConnectionFactory 可以配置为使用多个broker 地址; 这会失败的，client会尝试按顺序来连接. LocalizedQueueConnectionFactory 使用管理插件提供的 REST API来确定包含master队列的节点.然后，它会创建(或从缓存中获取)一个只连接那个节点的CachingConnectionFactory .如果连接失败了,将会确定一个新的消费者可连接的master节点. LocalizedQueueConnectionFactory 使用默认的连接工厂进行配置,在队列物理位置不能确定的情况下，它会按照正常情况来连接集群．
 
   
LocalizedQueueConnectionFactory 是一个RoutingConnectionFactory ， SimpleMessageListenerContainer 会使用队列名称作为其lookup key ，这些已经在上面的 the section called “Routing Connection Factory” 讨论过了.
 
   
 
 
   
基于这个原因(使用队列名称来作查找键),LocalizedQueueConnectionFactory 只在容器配置为监听某个单一队列时才可使用．
 
   
RabbitMQ 管理插件应该在每个节点上开启.
 
   
警告
 
   
这种连接工厂用于长连接,如用在SimpleMessageListenerContainer的连接.它的目的不是用于短连接, 如在 RabbitTemplate中使用，这是因为在连接前，它要调用REST API. 此外，对于发布操作来说，队列是未知的,不管如何， 消息会发布到所有集群成员中，因此查找节点的逻辑几乎没有什么意义。
 
   
这里有一个样例配置,使用了Spring Boot的RabbitProperties来配置工厂:
 
   
@Autowired
private RabbitProperties props;

private final String[] adminUris = { "http://host1:15672", "http://host2:15672" };

private final String[] nodes = { "rabbit@host1", "rabbit@host2" };

@Bean
public ConnectionFactory defaultConnectionFactory() {
    CachingConnectionFactory cf = new CachingConnectionFactory();
    cf.setAddresses(this.props.getAddresses());
    cf.setUsername(this.props.getUsername());
    cf.setPassword(this.props.getPassword());
    cf.setVirtualHost(this.props.getVirtualHost());
    return cf;
}

@Bean
public ConnectionFactory queueAffinityCF(
        @Qualifier("defaultConnectionFactory") ConnectionFactory defaultCF) {
    　　 return new LocalizedQueueConnectionFactory(defaultCF,
            StringUtils.commaDelimitedListToStringArray(this.props.getAddresses()),
            this.adminUris, this.nodes,
            this.props.getVirtualHost(), this.props.getUsername(), this.props.getPassword(),
            false, null);
}
 
   
注意，三个参数是 addresses, adminUris 和 nodes的数组. 当一个容器试图连接一个队列时，它们是有位置性的，它决定了哪个节点上的队列是mastered，并以同样数组位置来连接其地址．
 
    
   
发布者确认和返回
 
   
确认和返回消息可通过分别设置CachingConnectionFactory的 publisherConfirms 和publisherReturns 属性为ture来完成.
 
   
当设置了这些选项时，由工厂创建的通道将包装在PublisherCallbackChannel中,这用来方便回调. 当获取到这样的通道时，client可在channel上注册一个 PublisherCallbackChannel.Listener. PublisherCallbackChannel 实现包含一些逻辑来路由确认／返回给适当的监听器. 这些特性将在下面的章节中进一步解释.
 
   
对于一些更多的背景信息, 可以参考下面的博客：Introducing Publisher Confirms.
 
    
   
记录通道关闭事件
 
   
１.５版本中引入了允许用户控制日志级别的机制．
 
   
CachingConnectionFactory 使用默认的策略来记录通道关闭事件：
 
   
 
    
不记录通道正常关闭事件 (200 OK).
 
    
如果通道是因为失败的被动的队列声明关闭的，将记录为debug级别.
 
    
如果通道关闭是因为basic.consume因专用消费者条件而拒绝引起的,将被记录为INFO级别.
 
    
所有其它的事件将记录为ERROR级别.
 
   
 
   
要修改此行为，需要在CachingConnectionFactory的closeExceptionLogger属性中注入一个自定义的ConditionalExceptionLogger．
 
   
也可参考the section called “Consumer Failure Events”.
 
    
   
运行时缓存属性
 
   
从１.6版本开始, CachingConnectionFactory 通过getCacheProperties()方法提供了缓存统计. 这些统计数据可用来在生产环境中优化缓存.例如, 最高水位标记可用来确定是否需要加大缓存.如果它等于缓存大小，你也许应该考虑进一步加大.
 
   
Table 3.1. CacheMode.CHANNEL的缓存属性
 
   
 
    
 
     
 
      
Property
 
      
Meaning
 
     
 
    
 
    
 
     
 
      
 
channelCacheSize
 
 
      
 
当前配置的允许空闲的最大通道数量.
 
 
     
 
     
 
      
 
localPort
 
 
      
 
连接的本地端口(如果可用的话). 在可以在RabbitMQ　管理界面中关联 connections/channels.
 
 
     
 
     
 
      
 
idleChannelsTx
 
 
      
 
当前空闲(缓存的)的事务通道的数目.
 
 
     
 
     
 
      
 
idleChannelsNotTx
 
 
      
 
当前空闲(缓存的)的非事务通道的数目.
 
 
     
 
     
 
      
 
idleChannelsTxHighWater
 
 
      
 
同时空闲(缓存的)的事务通道的最大数目
 
 
     
 
     
 
      
 
idleChannelsNotTxHighWater
 
 
      
 
同时空闲(缓存的)的非事务通道的最大数目．
 
 
     
 
    
 
   
 
   
Table 3.2. CacheMode.CONNECTION的缓存属性
 
   
 
    
 
     
 
      
Property
 
      
Meaning
 
     
 
    
 
    
 
     
 
      
 
openConnections
 
 
      
 
表示连接到brokers上连接对象的数目.
 
 
     
 
     
 
      
 
channelCacheSize
 
 
      
 
当前允许空闲的最大通道数目
 
 
     
 
     
 
      
 
connectionCacheSize
 
 
      
 
当前允许空闲的最大连接数目.
 
 
     
 
     
 
      
 
idleConnections
 
 
      
 
当前空闲的连接数目．
 
 
     
 
     
 
      
 
idleConnectionsHighWater
 
 
      
 
目前已经空闲的最大连接数目.
 
 
     
 
     
 
      
 
idleChannelsTx:
 
 
      
 
在当前连接上目前空闲的事务通道的数目. 属性名的localPort部分可用来在RabbitMQ 管理界面中关联connections/channels．
 
 
     
 
     
 
      
 
idleChannelsNotTx:
 
 
      
 
在当前连接上目前空闲和非事务通道的数目．属性名的localPort部分可用来在RabbitMQ管理界面中关联connections/channels 
 
 
     
 
     
 
      
 
idleChannelsTxHighWater:
 
 
      
 
已同时空闲的事务通道的最大数目. 属性名的 localPort部分可用来在RabbitMQ管理界面中关联connections/channels．
 
 
     
 
     
 
      
 
idleChannelsNotTxHighWater:
 
 
      
 
忆同时空闲的非事务通道的最大数目．属性名的localPort部分可用来RabbitMQ管理界面中关联connections/channels．
 
 
     
 
    
 
   
 
   
 
 
   
cacheMode 属性 (包含CHANNEL 或 CONNECTION ).
 
   
Figure 3.1. JVisualVM Example
 
   
 
   
 
    
   
3.1.3 添加自定义Client 连接属性
 
   
CachingConnectionFactory 现在允许你访问底层连接工厂,例如, 设置自定义client 属性:
 
   
connectionFactory.getRabbitConnectionFactory().getClientProperties().put("foo", "bar");
 
   
当在RabbitMQ管理界面中查看连接时，将会看到这些属性．
 
   
 
 
   
3.1.4 AmqpTemplate
 
    
   
介绍
 
   
像其它Spring Framework提供的高级抽象一样， Spring AMQP 提供了扮演核心角色的模板. 定义了主要操作的接口称为AmqpTemplate. 这些操作包含了发送和接收消息的一般行为.换句话说，它们不是针对某个特定实现的，从其名称"AMQP"就可看出.另一方面，接口的实现会尽量作为AMQP协议的实现.不像JMS,它只是接口级别的API实现, AMQP是一个线路级协议.协议的实现可提供它们自己的client libraries, 因此模板接口的实现都依赖特定的client library．目前，只有一个实现:RabbitTemplate. 在下面的例子中，你会经常看到"AmqpTemplate",但当你查看配置例子或者任何实例化或调用setter方法的代码时，你都会看到实现类型(如．"RabbitTemplate").
 
   
正如上面所提到的, AmqpTemplate 接口定义了所有发送和接收消息的基本操作. 我们将分别在以下两个部分探索消息发送和接收。
 
   
也可参考the section called “AsyncRabbitTemplate”.
 
    
   
 
 
   
添加重试功能
 
   
从１.3版本开始， 你可为RabbitTemplate 配置使用 RetryTemplate 来帮助处理broker连接的问题. 参考spring-retry 项目来了解全部信息;下面就是一个例子，它使用指数回退策略(exponential back off policy)和默认的 SimpleRetryPolicy (向调用者抛出异常前，会做三次尝试）.
 
   
使用XML命名空间:
 
   
 
   
 
   
 
   
 
   
 
   
 
   
 
   
 
   
 
   
 
   
使用 @Configuration:
 
   
@Bean
 
   
public AmqpTemplate rabbitTemplate();
		RabbitTemplate template = new RabbitTemplate(connectionFactory());
		RetryTemplate retryTemplate = new RetryTemplate();
		ExponentialBackOffPolicy backOffPolicy = new ExponentialBackOffPolicy();
		backOffPolicy.setInitialInterval(500);
		backOffPolicy.setMultiplier(10.0);
		backOffPolicy.setMaxInterval(10000);
		retryTemplate.setBackOffPolicy(backOffPolicy);
		template.setRetryTemplate(retryTemplate);
		return template;
}
 
   
从1.4版本开始,除了retryTemplate 属性外,RabbitTemplate 上也支持recoveryCallback 选项. 它可用作RetryTemplate.execute(RetryCallback retryCallback, RecoveryCallbackrecoveryCallback)第二个参数.
 
   
RecoveryCallback 会有一些限制，因为在retry context只包含lastThrowable 字段.在更复杂的情况下，你应该使用外部RetryTemplate,这样你就可以通过上下文属性传递更多信息给RecoveryCallback．
 
   
retryTemplate.execute(
    new RetryCallback() {

        @Override
 
   
　　public Object doWithRetry(RetryContext context) throws Exception {
            context.setAttribute("message", message);
            return rabbitTemplate.convertAndSend(exchange, routingKey, message);
        }
    }, new RecoveryCallback