SpringAMQP 1.6.1.RELEASE 更新概览与新特性

spring-amqp

需积分: 1 149 浏览量更新于2024-07-20 收藏 729KB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

SpringAMQP 1.6.1.RELEASE 是一个强大的、基于Spring框架的AMQP（Advanced Message Queuing Protocol）实现，它提供了一整套用于构建企业级消息驱动架构的工具和组件。该版本由多位开发者共同贡献，包括Mark Pollack、Mark Fisher、Oleg Zhurakousky等人，版权归属Pivotal Software Inc.。本参考文档旨在帮助用户深入了解Spring AMQP 1.6.1.RELEASE的功能更新、配置方式和使用技巧。以下是一些关键知识点： 1. **兼容性**：文档强调了1.6版本与1.5.4版本之间的兼容性，确保在升级过程中可以平稳过渡，同时可能包含针对新特性的兼容策略。 2. **配置方式**： - **XML配置**：早期版本的Spring AMQP支持XML配置，用户可以根据项目需求选择传统的XML方式来定义消息队列的连接、交换器、绑定等。 - **Java配置**：随着Java配置的兴起，Spring AMQP 1.6引入了更现代的Java配置选项，允许开发人员利用Java表达式和注解来编写更加简洁的配置代码。 3. **新特性概览**： - **测试支持**：版本更新可能增强了对单元测试和集成测试的支持，使得测试更加全面和方便。 - **Builder模式**：Builder类的引入，可能简化了构建复杂消息消费者和生产者的过程。 - **命名空间变化**：可能对XML配置中的某些元素进行了调整或添加新的命名空间，以适应新版本的需求。 4. **核心组件**： - **ListenerContainer**：Listener容器的变化可能涉及到性能优化或功能增强，有助于更好地管理消息消费者的生命周期和并发处理。 - **AmqpTemplate**：新增了`receivewithtimeout`方法，提供了设置接收超时的功能，有助于控制消息处理的响应时间。 - **AsyncRabbitTemplate**：异步版本的模板，可能提升了并发处理能力和性能。 - **RabbitTemplate**：在模板类中可能有更灵活的选项和改进，如处理消息属性的便利性。 - **RabbitAdmin**：RabbitAdmin工具类得到了扩展，便于动态声明和管理交换器、队列等资源。 5. **注解和监听器**：`@RabbitListener`注解的改变反映了对消费者方法签名和回调逻辑的改进，可能是为了更好地支持函数式编程风格。 6. **高级功能**： - **延迟消息交换器**：支持发送延迟执行的消息，扩展了消息的生命周期管理。 - **内部标志**：可能涉及交换器的内部行为调整，比如访问控制和路由规则的优化。 - **连接工厂**：CachingConnectionFactory和RabbitConnectionFactoryBean类可能包含了性能优化或者新特性，以提高连接池管理和效率。 7. **Java API**：文档详细描述了Java API的用法，帮助开发人员更好地理解和使用Spring AMQP的各种组件。通过阅读Spring AMQP 1.6.1.RELEASE的参考文档，开发者可以了解到如何有效地在项目中集成和管理消息队列，以及如何利用新特性提升系统的可扩展性和性能。同时，文档还提供了关于如何处理版本升级和配置调整的指导，确保了平稳的迁移和维护过程。

资源详情

资源推荐

Spring AMQP

1.6.1.RELEASE Spring AMQP 9

3. Reference

This part of the reference documentation details the various components that comprise Spring AMQP.

The main chapter covers the core classes to develop an AMQP application. This part also includes a

chapter about the sample applications.

3.1 Using Spring AMQP

In this chapter, we will explore the interfaces and classes that are the essential components for

developing applications with Spring AMQP.

AMQP Abstractions

Introduction

Spring AMQP consists of a handful of modules, each represented by a JAR in the distribution.

These modules are: spring-amqp, and spring-rabbit. The spring-amqp module contains the

org.springframework.amqp.core package. Within that package, you will find the classes that

represent the core AMQP "model". Our intention is to provide generic abstractions that do not rely on

any particular AMQP broker implementation or client library. End user code will be more portable across

vendor implementations as it can be developed against the abstraction layer only. These abstractions

are then used implemented by broker-specific modules, such as spring-rabbit. There is currently only a

RabbitMQ implementation; however the abstractions have been validated in .NET using Apache Qpid

in addition to RabbitMQ. Since AMQP operates at the protocol level in principle, the RabbitMQ client

can be used with any broker that supports the same protocol version, but we do not test any other

brokers at present.

The overview here assumes that you are already familiar with the basics of the AMQP specification. If

you are not, then have a look at the resources listed in Chapter 5, Other Resources

Message

The 0-8 and 0-9-1 AMQP specifications do not define a Message class or interface. Instead, when

performing an operation such as basicPublish(), the content is passed as a byte-array argument

and additional properties are passed in as separate arguments. Spring AMQP defines a Message class

as part of a more general AMQP domain model representation. The purpose of the Message class is

to simply encapsulate the body and properties within a single instance so that the API can in turn be

simpler. The Message class definition is quite straightforward.

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() {

return this.body;

}

public MessageProperties getMessageProperties() {

return this.messageProperties;

}

Spring AMQP

1.6.1.RELEASE Spring AMQP 10

The MessageProperties interface defines several common properties such as messageId,

timestamp, contentType, and several more. Those properties can also be extended with user-defined

headers by calling the setHeader(String key, Object value) method.

Exchange

The Exchange interface represents an AMQP Exchange, which is what a Message Producer sends to.

Each Exchange within a virtual host of a broker will have a unique name as well as a few other properties:

public interface Exchange {

String getName();

String getExchangeType();

boolean isDurable();

boolean isAutoDelete();

Map<String, Object> getArguments();

}

As you can see, an Exchange also has a type represented by constants defined in ExchangeTypes.

The basic types are: Direct, Topic, Fanout, and Headers. In the core package you will find

implementations of the Exchange interface for each of those types. The behavior varies across these

Exchange types in terms of how they handle bindings to Queues. For example, a Direct exchange

allows for a Queue to be bound by a fixed routing key (often the Queue’s name). A Topic exchange

supports bindings with routing patterns that may include the * and # wildcards for exactly-one and zero-

or-more, respectively. The Fanout exchange publishes to all Queues that are bound to it without taking

any routing key into consideration. For much more information about these and the other Exchange

types, check out Chapter 5, Other Resources.

Note

The AMQP specification also requires that any broker provide a "default" Direct Exchange that has

no name. All Queues that are declared will be bound to that default Exchange with their names

as routing keys. You will learn more about the default Exchange’s usage within Spring AMQP in

the section called “AmqpTemplate”.

Queue

The Queue class represents the component from which a Message Consumer receives Messages. Like

the various Exchange classes, our implementation is intended to be an abstract representation of this

core AMQP type.

Spring AMQP

1.6.1.RELEASE Spring AMQP 12

Note

The BindingBuilder class is shown above for clarity, but this style works well when using a static

import for the bind() method.

By itself, an instance of the Binding class is just holding the data about a connection. In other words, it is

not an "active" component. However, as you will see later in the section called “Configuring the broker”,

Binding instances can be used by the AmqpAdmin class to actually trigger the binding actions on the

broker. Also, as you will see in that same section, the Binding instances can be defined using Spring’s

@Bean-style within @Configuration classes. There is also a convenient base class which further

simplifies that approach for generating AMQP-related bean definitions and recognizes the Queues,

Exchanges, and Bindings so that they will all be declared on the AMQP broker upon application startup.

The AmqpTemplate is also defined within the core package. As one of the main components

involved in actual AMQP messaging, it is discussed in detail in its own section (see the section called

“AmqpTemplate”).

Connection and Resource Management

Introduction

Whereas the AMQP model we described in the previous section is generic and applicable to all

implementations, when we get into the management of resources, the details are specific to the broker

implementation. Therefore, in this section, we will be focusing on code that exists only within our "spring-

rabbit" module since at this point, RabbitMQ is the only supported implementation.

The central component for managing a connection to the RabbitMQ broker is the ConnectionFactory

interface. The responsibility of a ConnectionFactory implementation is to provide an

instance of org.springframework.amqp.rabbit.connection.Connection which is a wrapper

for com.rabbitmq.client.Connection. The only concrete implementation we provide is

CachingConnectionFactory which, by default, establishes a single connection proxy that can be

shared by the application. Sharing of the connection is possible since the "unit of work" for messaging

with AMQP is actually a "channel" (in some ways, this is similar to the relationship between a Connection

and a Session in JMS). As you can imagine, the connection instance provides a createChannel

method. The CachingConnectionFactory implementation supports caching of those channels, and

it maintains separate caches for channels based on whether they are transactional or not. When creating

an instance of CachingConnectionFactory, the hostname can be provided via the constructor. The

username and password properties should be provided as well. If you would like to configure the size

of the channel cache (the default is 25), you could call the setChannelCacheSize() method here

as well.

Starting with version 1.3, the CachingConnectionFactory can be configured to cache connections

as well as just channels. In this case, each call to createConnection() creates a new connection

(or retrieves an idle one from the cache). Closing a connection returns it to the cache (if the cache

size has not been reached). Channels created on such connections are cached too. The use of

separate connections might be useful in some environments, such as consuming from an HA cluster,

in conjunction with a load balancer, to connect to different cluster members. Set the cacheMode to

CacheMode.CONNECTION.

Note

This does not limit the number of connections, it specifies how many idle open connections are

allowed.

Spring AMQP

1.6.1.RELEASE Spring AMQP 13

Starting with version 1.5.5, a new property connectionLimit is provided. When this is

set, it limits the total number of connections allowed. When set, if the limit is reached, the

channelCheckoutTimeLimit is used to wait for a connection to become idle. If the time is exceeded,

an AmqpTimeoutException is thrown.

Important

When the cache mode is CONNECTION, automatic declaration of queues etc. (See the section

called “Automatic Declaration of Exchanges, Queues and Bindings”) is NOT supported.

Also, at the time of writing, the rabbitmq-client library creates a fixed thread pool for each

connection (5 threads) by default. When using a large number of connections, you should consider

setting a custom executor on the CachingConnectionFactory. Then, the same executor

will be used by all connections and its threads can be shared. The executor’s thread pool should

be unbounded, or set appropriately for the expected utilization (usually, at least one thread per

connection). If multiple channels are created on each connection then the pool size will affect the

concurrency, so a variable (or simple cached) thread pool executor would be most suitable.

It is important to understand that the cache size is (by default) not a limit, but merely the number of

channels that can be cached. With a cache size of, say, 10, any number of channels can actually be in

use. If more than 10 channels are being used and they are all returned to the cache, 10 will go in the

cache; the remainder will be physically closed.

Starting with version 1.6, the default channel cache size has been increased from 1 to 25. In high volume,

multi-threaded, environments, a small cache means that channels are created and closed at a high rate.

Increasing the default cache size will avoid this overhead. You should monitor the channels in use via

the RabbitMQ Admin UI and consider increasing the cache size further if you see many channels being

created and closed. The cache will only grow on-demand (to suit the concurrency requirements of the

application) so this change will not impact existing low-volume applications.

Starting with version 1.4.2, the CachingConnectionFactory has a property

channelCheckoutTimeout. When this property is greater than zero, the channelCacheSize

becomes a limit on the number of channels that can be created on a connection. If the limit is reached,

calling threads will block until a channel is available or this timeout is reached, in which case a

AmqpTimeoutException is thrown.

Warning

Channels used within the framework (e.g. RabbitTemplate) will be reliably returned to the

cache. If you create channels outside of the framework, (e.g. by accessing the connection(s)

directly and invoking createChannel()), you must return them (by closing) reliably, perhaps in

a finally block, to avoid running out of channels.

CachingConnectionFactory connectionFactory = new CachingConnectionFactory("somehost");

connectionFactory.setUsername("guest");

connectionFactory.setPassword("guest");

Connection connection = connectionFactory.createConnection();

When using XML, the configuration might look like this:

剩余112页未读，继续阅读

qinxike

粉丝: 37
资源: 62

SpringAMQP 1.6.1.RELEASE 更新概览与新特性

Spring AMQP 2 中文 参考手册 中文文档

spring-amqp-1.4.0.RELEASE.jar

rabbitmq+spring需要的jar包

spring-amqp对应springboot版本

spring-boot-starter-parent 2.7.16-SNAPSHOT 对应 spring-boot-starter-amqp 版本选择

spring-boot-starter-amqp

spring-boot-starter-amqp 版本选择

spring-cloud-starter-bus-amqp

spring-boot-starter-amqp+application.yml的代码案例

spring-boot-starter-amqp依赖是干嘛的

spring-boot-starter-amqp 延时消息

spring-amqp:2.2.19.re lease.jar 升级到 2.3.2

spring-boot-starter-amqp 使用例子

spring-boot-starter-amqp的代码案例

spring-boot-starter-amqp outofmemoryerror

spring-boot-starter-amqp+application.yml+controller的代码案例

Could not transfer artifact org.springframework.boot:spring-boot-starter-amqp:pom:3.1.3 from/to central

Consider defining a bean of type 'org.springframework.amqp.rabbit.connection.ConnectionFactory' in your configuration.

什么是spring-amqp

最新资源

Spring AMQP 2 中文参考手册中文文档