文章目录
前言
一、RabbitMq简介
1、RabbitMq场景应用，RabbitMq特点
场景应用
- 以订单系统为例，用户下单之后的业务逻辑可能包括：生成订单、扣减库存、使用优惠券、增加积分、通知商家用户下单、发短信通知等等。在业务发展初期这些逻辑可能放在一起同步执行，随着业务的发展订单量增长，需要提升系统服务的性能，这时可以将一些不需要立即生效的操作拆分出来异步执行。这种场景下就可以用 MQ ，在下单的主流程（比如扣减库存、生成订单）完成之后发送一条消息到 MQ 让主流程快速完结，而由另外的单独消费线程拉取MQ的消息（或者由 MQ 推送消息。
特点
RabbitMQ 是一个由 Erlang 语言开发的 AMQP 的开源实现。
-
AMQP ：Advanced Message Queue，高级消息队列协议。它是应用层协议的一个开放标准，为面向消息的中间件设计，基于此协议的客户端与消息中间件可传递消息，并不受产品、开发语言等条件的限制。
-
可靠性（Reliability）
RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认。 -
灵活的路由（Flexible Routing）
在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个 Exchange 绑定在一起，也通过插件机制实现自己的 Exchange 。 -
消息集群（Clustering）
多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker 。 -
高可用（Highly Available Queues）
队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。 -
多种协议（Multi-protocol）
RabbitMQ 支持多种消息队列协议，比如 STOMP、MQTT 等多种消息中间件协议。 -
多语言客户端（Many Clients）
RabbitMQ 几乎支持所有常用语言，比如Java、Python 、Ruby 、PHP 、C# 、JavaScript 等。 -
管理界面（Management UI）
RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker 的许多方面。 -
跟踪机制（Tracing）
如果消息异常，RabbitMQ 提供了消息跟踪机制，使用者可以找出发生了什么。 -
插件机制（Plugin System）
RabbitMQ 提供了许多插件，来从多方面进行扩展，也可以编写自己的插件。
2、RabbitMq工作流程
- publisher连接到rabbitMQ Broker，创建connection，开启channel。声明交换机类型、名称、是否持久化等。
- 消息可靠投递(开启confirmCallback returnCallback)，并指定消息是否持久化等属性和routing key。
- exchange收到消息之后，根据routing key路由到跟当前交换机绑定的相匹配的(存)队列里面。
- consumer监听接收到消息之后开始业务处理，然后发送一个ack确认告知消息已经被消费。
rabbitMQ Broker收到ack之后将对应的消息从队列里面删除掉。
如下图:
- Message
消息，消息是不具名的，它由消息头和消息体组成。消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等。 - Publisher
消息的生产者，也是一个向交换器发布消息的客户端应用程序。
Exchange
交换器，用来接收生产者发送的消息并将这些消息路由给服务器中的队列。 - Binding
绑定，用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。 - Queue
消息队列，用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。 - Connection
网络连接，比如一个TCP连接。 - Channel
信道，多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内地虚拟连接，AMQP 命令都是通过信道发出去的，不管是发布消息、订阅队列还是接收消息，这些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都是非常昂贵的开销，所以引入了信道的概念，以复用一条 TCP 连接。 - Consumer
消息的消费者，表示一个从消息队列中取得消息的客户端应用程序。 - Virtual Host
虚拟主机，表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器，拥有自己的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础，必须在连接时指定，RabbitMQ 默认的 vhost 是 / 。 - Broker
表示消息队列服务器实体。
二、创建工程
1.创建工程，连接，配置
- 创建工程
- pom依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-amqp</artifactId>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</dependency>
-
只要引入了amqp场景，就会有相关的自动配置AutoConfiguration类
用idea搜索RabbitAutoConfiguration源码如下:
-
可以看到这个类会给容器中自动配置了RabbitTemplate ，AmqpAdmin，CachingConnectionFactory等等.
-
连接Rabbit，RabbitAutoConfiguration可以找到连接工厂可以看到从RabbitProperties类找到所有连接信息进入源码如下图:
-
可以看到很多都有默认值
-
yml配置
spring:
rabbitmq:
host: //填自己主机地址
port: 5672
virtual-host: /
- 测试是否能正常连接
1.amqpAdmin 创建 Exchange Queue Binding
- 创建交换机
可以看到成功创建交换器
- 创建队列
- 可以看到成功创建队列
- declareBinding
2.rabbitTemplate使用
- rabbitTemplate发送消息
发送消息,如果消息是个对象,会使用序列化机制,将对象写出去,对象必须实现Serializable
可以看到队列里面已经有这条消息了
- 发送的对象消息使用json序列化
查看RabbitTemplate类可以看到如果没有配置会使用默认的序列化
- 点MessageConverter进去可以看到是一个接口
- 使用idea查看实现继承图可以发现Jackson2JsonMessageConverter
把Jackson2JsonMessageConverter放出容器中就行了编写配置类 - 注意这个消息转换器是amqp包下
import org.springframework.amqp.support.converter.Jackson2JsonMessageConverter;
import org.springframework.amqp.support.converter.MessageConverter;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class RabbitConfig {
@Bean
public MessageConverter messageConverter() {
return new Jackson2JsonMessageConverter();
}
}
- 再次调用sendMessage方法发送消息使用web页面查看队列消息
可以看到配置的消息转换器已经生效
3.rabbitListener&rabbitHandler接收消息
- 新建消费者类
@Service
public class Consumer {
/**
* queues 需要监听的队列
* <p>
* message: 原生消息详细信息。头+体
* T<发送的消息类型></> Order order
* channel：当前传输数据的通道
*/
@RabbitListener(queues = {"java-Queue"})
public void recieveMessage(Object message,
Order order,
Channel channel) {
System.out.println(message);
System.out.println(order);
}
}
- 先让队列存放10条消息,启动容器
- rabbitHandler
- 场景二如果队列里面存放的是不同的json数据如何让转成对应的实体类呢?
- 这时候就使用rabbitHandler 重载
4.消息队列-可靠投递-发送端确认
- 保证消息不丢失，可靠抵达，可以使用事物消息，性能下降250倍( 文档)，为此引入确认机制
- publisher把消息发送给Broker只要服务器收到消息就会回调confirmCallback(确认模式)
- Broker收到消息后要要使用Exchange交换机最终投递Queue,Queue投递也有可能失败,投递失败就会调用 returnCallback(未投递到queue回退模式)
如下图所示:
可靠抵达(confirmCallback)
- 修改配置文件开启发送确认模式(spring.rabbitmq.publisher-returns=true，默认是false)
spring:
rabbitmq:
host:
port: 5672
virtual-host: /
#开启发送端确认
publisher-confirm-type: correlated
- 定制rabbitTemplate,实现ConfirmCallback接口
@PostConstruct
public void initRabbitTemplate() {
//设置一个确认回调
rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {
/**
*
* @param correlationData 当前消息唯一关联数据
* @param b 是否成功收到
* @param cause 失败的原因
*/
@Override
public void confirm(CorrelationData correlationData, boolean b, String cause) {
log.info("correlationData:{},ack:{},cause:{}", correlationData, b, cause);
}
});
}
- ack是true,说明消息被服务器确认收到了
回退模式(returnCallback)
- 修改配置文件开启发送消息抵达队列的确认( publisher-returns: true，默认是false)
- 修改配置文件只要抵达队列,以异步发送优先回调returnConfirm(spring.rabbitmq.template.mandatory=true，默认是false)
spring:
rabbitmq:
host:
port: 5672
virtual-host: /
#开启发送端确认
publisher-confirm-type: correlated
#开启发送消息抵达队列的确认
publisher-returns: true
#只要抵达队列,以异步发送优先回调returnConfirm
template:
mandatory: true
- 定制rabbitTemplate,实现ReturnsCallback接口
@PostConstruct
public void initRabbitTemplate() {
//设置一个确认回调
rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {
/**
* @param correlationData 当前消息唯一关联数据
* @param b 是否成功收到
* @param cause 失败的原因
*/
@Override
public void confirm(CorrelationData correlationData, boolean b, String cause) {
log.info("correlationData:{},ack:{},cause:{}", correlationData, b, cause);
}
});
//设置消息抵达队列的确认回调
rabbitTemplate.setReturnsCallback(new RabbitTemplate.ReturnsCallback() {
//只要消息没有投递到指定队列,就回触发这个失败回调
/**
*
* @param returnedMessage 该类有以下变量
* Message message; 投递失败的消息详细信息
* replyCode; 回复的状态吗
* replyText; 回复的文本内容
* exchange; 当时这个消息发给那个交换机
* routingKey; 当时这个消息用那个路由键
*/
@Override
public void returnedMessage(ReturnedMessage returnedMessage) {
log.info("message:{},replyCode:{},replyText:{},exchange:{},routingKey:{}",
returnedMessage.getMessage(),
returnedMessage.getReplyCode(),
returnedMessage.getReplyText(),
returnedMessage.getExchange(),
returnedMessage.getRoutingKey());
}
});
}
- returnCallback 只有失败才会回调该方法故意写错路由键测试效果如下:
可以看到消息发送成功,投递到交换机成功,因为故意写错路由键所有投递队列失败。错误信息如下
message:(Body:'{"id":1,"userId":1}' MessageProperties [headers={__TypeId__=com.mq.rabbit.entity.Order}, contentType=application/json, contentEncoding=UTF-8, contentLength=0, receivedDeliveryMode=PERSISTENT, priority=0, deliveryTag=0]),replyCode:312,replyText:NO_ROUTE,exchange:java-Exchange,routingKey:java-error
5.消息队列-可靠投递-消费端确认
- 消费端确认(保证每个消息被正确消费,此时才可以broker删除这个消息)
- 默认是自动确认,只要消息接收到.客户端会自动确认,服务端就会移除这个消息
开启消息手动确认(acknowledge:manual)
spring:
rabbitmq:
host:
port: 5672
virtual-host: /
#开启发送端确认
publisher-confirm-type: correlated
#开启发送消息抵达队列的确认
publisher-returns: true
#只要抵达队列,以异步发送优先回调returnConfirm
template:
mandatory: true
#默认客户端接收到消息自动ack, acknowledge修改为manual 开启手动确认
listener:
simple:
acknowledge-mode: manual
- 测试发送消息,未手动签收消息,broker是否会删除这个消息
- 可以看到有一条消息是未签收状态(Unacked)
- 消息手动确认模式。只要我们没有明确告诉mq消息被签收.消息
就一直是unacked状态。及时服务宕机。消息也不会丢失，会重新变为ready。下一次有新的消费者连接进来就会发给他.
- channel.basicAck
- channel.basicNack
/**
* queues 需要监听的队列
* <p>
* message: 原生消息详细信息。头+体
* T<发送的消息类型></> Order order
* channel：当前传输数据的通道
*/
@RabbitHandler
public void recieveMessage(Message message, Order order,
Channel channel) throws IOException {
//deliveryTag channel内按顺序自增
long deliveryTag = message.getMessageProperties().getDeliveryTag();
log.info("接收队列订单消息{}", order);
if (ThreadLocalRandom.current().nextInt(100) % 2 == 0) {
/**签收消息
* long deliveryTag, boolean multiple
* multiple 是否批量签收模式 false代表我只签收我当前这条消息
* 签收需要给broker回复ack,所以有可能网络中断 需要捕获异常或者抛出异常
*/
channel.basicAck(deliveryTag, false);
log.info("消息签收成功");
} else {
/**
* long deliveryTag, boolean multiple, boolean requeue
* multiple 是否批量拒绝签收
* requeue true 发回服务器,重新入队 false 丢弃
*/
channel.basicNack(deliveryTag, false, false);
log.info("消息签收失败丢弃消息");
}
}
- 结合我们消息发送端的确认机制和消息消费端的确认机制最终达到消息百分百不丢失
总结
完
感谢您的阅读
如果你发现了错误的地方，可以在留言区提出来，我对其加以修改
扫一扫
439
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
