前言
MySQL在过去由于性能高、成本低、可靠性好,已经成为最流行的开源数据库,因此被广泛地应用在Internet上的中小型网站中。随着MySQL的不断成熟,它也逐渐用于更多大规模网站和应用。非常流行的开源软件组合LAMP中的“M”指的就是MySQL。这份PDF真的是很全面了,几乎包括了MySQL中所有操作。
@Component
public class ExchangeConsumer {
/**
- 监听绑定了direct交换机的的消息队列
*/
@RabbitHandler
@RabbitListener(queues = “LONGLY_WOLF_ORDER_QUEUE”)
public void directConsumer(String msg){
System.out.println(“direct交换机收到消息:” + msg);
}
/**
- 监听绑定了topic交换机的的消息队列
*/
@RabbitHandler
@RabbitListener(queues = “LONGLY_WOLF_USER_QUEUE”)
public void topicConsumer(String msg){
System.out.println(“topic交换机收到消息:” + msg);
}
/**
- 监听绑定了fanout交换机的的消息队列
*/
@RabbitHandler
@RabbitListener(queues = “LONGLY_WOLF_PRODUCT_QUEUE”)
public void fanoutConsumer(String msg){
System.out.println(“fanout交换机收到消息:” + msg);
}
}
- 4、新增一个
RabbitExchangeController
类来作为生产者,进行消息发送:
@RestController
@RequestMapping(“/exchange”)
public class RabbitExchangeController {
@Autowired
private RabbitTemplate rabbitTemplate;
@GetMapping(value=“/send/direct”)
public String sendDirect(String routingKey,@RequestParam(value = “msg”,defaultValue = “no direct message”) String msg){
rabbitTemplate.convertAndSend(“LONGLY_WOLF_DIRECT_EXCHANGE”,routingKey,msg);
return “succ”;
}
@GetMapping(value=“/send/topic”)
public String sendTopic(String routingKey,@RequestParam(value = “msg”,defaultValue = “no topic message”) String msg){
rabbitTemplate.convertAndSend(“LONGLY_WOLF_TOPIC_EXCHANGE”,routingKey,msg);
return “succ”;
}
@GetMapping(value=“/send/fanout”)
public String sendFaout(String routingKey,@RequestParam(value = “msg”,defaultValue = “no faout message”) String msg){
rabbitTemplate.convertAndSend(“LONGLY_WOLF_FANOUT_EXCHANGE”,routingKey,msg);
return “succ”;
}
}
- 5、启动服务,当我们调用第一个接口时候,路由键和绑定键
order.detail
精确匹配时,directConsumer
就会收到消息,同样的,调用第二接口时,路由键满足user.#
时,topicConsumer
就会收到消息,而只要调用第三个接口,不论是否指定路由键,fanoutConsumer
都会收到消息。
[](()消息过期了怎么办
=====================================================================
简单的发送消息我们学会了,难道这就能让我们就此止步了吗?显然是不能的,要玩就要玩高级点,所以接下来让我们给消息加点佐料。
[](()TTL(Time-To-Live)
TTL
即 一条消息在队列中的最大存活时间。在一条在队列中超过配置的 TTL
的消息称为已死消息。但是需要注意的是,已死消息并不能保证会立即从队列中删除,但是能保证已死的消息不会被投递出去。
设置 TTL
的方式有两种:
- 1、给队列设置
x-message-ttl
,此时所有被投递到队列中的消息,都会在到达TTL
时成为已死消息。
这种情况就会出现当一条消息同时路由到 N
个带有 TTL
时间的队列,而由于每个队列的 TTL
不一定相同,所以同一条消息在不同的队列中可能会在不同时间死亡或者不会死亡(未设置 TTL
),所以一个队列中的消息死亡不会影响到其他队列中的消息。
- 2、单独给某一条消息设置过期时间。
此时需要注意的时,当消息达到 TTL
时,可能不会马上被丢弃,因为只有处于队列头部消息过期后才会被丢弃,假如队列头部的消息没有设置 TTL
,而第 2
条消息设置了 TTL
,那么即使第 2
条消息成为了已死消息,也必须要等到队列头部的消息被消费之后才会被丢弃,而已死消息在被丢弃之前也会被计入统计数据(比如队列中的消息总数)。所以为了更好的利用 TTL
特性,建议让消费者在线消费消息,这样才能确保消息更快的被丢弃,防止消息堆积。
PS:消息过期和消费者传递之间可能存在自然的竞争条件。例如,消息可能在发送途中(未到达消费者)过期。
[](()队列的生存
和 TTL
针对消息不同的是,我们可以通过设置过期时间属性 `x-expires`` 来处理队列,当在指定过期时间内内未使用队列时,服务器保证将删除队列(但是无法保证在过期时间过后队列将以多快的速度被删除)。
[](()TTL 和过期时间实战
- 1、在上面定义的
RabbitConfig
类中,再新增一个TTL
队列并将其绑定到direct
交换机上:
@Bean(“ttlQueue”)
public Queue ttlQueue(){
Map<String, Object> map = new HashMap<String, Object>();
map.put(“x-message-ttl”, 5000);//队列中所有消息5秒后过期
map.put(“x-expires”, 100000);//队列闲置10秒后被删除
//参数1-name:队列名称
//参数2-durable:是否持久化
//参数3-exclusive:是否排他。设置为true时,则该队列只对声明当前队列的连接(Connection)可用,一旦连接断开,队列自动被删除
//参数4-autoDelete:是否自动删除。前提是必须要至少有一个消费者先连上当前队列,然后当所有消费者都断开连接之后,队列自动被删除
return new Queue(“LONGLY_WOLF_TTL_QUEUE”,false,false,false,map);
}
//ttl队列绑定到direct交换机(交换机和队列可以多对多)
@Bean
public Binding ttlBindFanoutExchange(@Qualifier(“ttlQueue”) Queue queue, @Qualifier(“directExchange”) DirectExchange directExchange){
return BindingBuilder.bind(queue).to(directExchange).with(“test.ttl”);
}
- 2、在
ExchangeConsumer
消费者类上监听TTL
队列(和其他消费者不同的时候,这里为了打印出队列属性,改成了通过Message
对象来接收消息 ):
/**
- 监听ttl消息队列
*/
@RabbitHandler
@RabbitListener(queues = “LONGLY_WOLF_TTL_QUEUE”)
public void ttlConsumer(Message message){
System.out.println(“ttl队列收到消息:” + new String(message.getBody()));
System.out.println(“ttl队列收到消息:” + JSONObject.toJSONString(message.getMessageProperties()));
}
- 3、在生产者类
RabbitExchangeController
上新增一个接口用来测试发送过期消息,这里通过MessageProperties
设置的expiration
属性就相当于是给单条消息设置了一个TTL
:
@GetMapping(value=“/send/ttl”)
public String sendTtl(String routingKey,@RequestParam(value = “msg”,defaultValue = “no ttl message”) String msg){
MessageProperties messageProperties = new MessageProperties();
messageProperties.setExpiration(“5000”);//5秒后被删除,即TTL属性(针对单条消息)
Message message = new Message(msg.getBytes(), messageProperties);
rabbitTemplate.convertAndSend(“LONGLY_WOLF_DIRECT_EXCHANGE”,routingKey,message);
return “succ”;
}
- 4、此时如果我们把消费者的监听去掉之后再发送消息,在管理后台就可以看到
5
秒之后消息会被删除,10
秒之后队列会被删除。
PS:如果同时给队列和单条消息都设置了 TTL
,则会以时间短的为主。
[](()其他属性
队列中还有其他一些属性可以设置,在这里我们就不一一举例了:
-
x-message-ttl:队列中消息的存活时间(毫秒),达到TTL的消息可能会被删除。
-
x-expires:队列在多长时间(毫秒)没有被访问以后会被删除。
-
x-max-length:队列中的最大消息数。
-
x-max-length-bytes:队列的最大容量(bytes)。
-
overflow:队列溢出之后的策略。主要可以配置如下参数:
reject-publish
- 直接丢弃最近发布的消息,如若启用了publisher confirm
(发布者确认),发布者将通过发送basic.nack
消息通知拒绝,如果当前队列绑定有多个消费者,则消息在收到basic.nack
拒绝通知后,仍然会被发布到其他队列;drop-head
- 丢弃队列头部消息(集群模式下只支持这种策略)reject-publish-dlx
- 最近发布的消息会进入死信队列。 -
x-dead-letter-exchange:队列的死信交换机。
-
x-dead-letter-routing-key:死信交换机的路由键。
-
x-single-active-consumer:true/false。表示是否最多只允许一个消费者消费,如果有多个消费者同时绑定,则只会激活第一个,除非第一个消费者被取消或者死亡,才会自动转到下一个消费者。
-
x-max-priority:队列中消息的最大优先级, 消息的优先级不能超过它。
-
x-queue-mode:
3.6.0
版本引入的,主要是为了实现惰性加载。队列将收到的消息尽可能快的进行持久化操作到磁盘上,然后只有在用户请求的时候才会加载到RAM
内存。这个参数支持两个值:default
和lazy
。当不进行设置的时候,就是默认为default
,不做任何改变;当设置为lazy
就会进行懒加载。 -
x-queue-master-locator:为了保证消息的
FIFO
,所以在高可用集群模式下需要选择一个节点作为主节点。这个参数主要有三种模式:min-masters
- 托管最小数量的绑定主机的节点;client-local
- 选择声明的队列已经连接到客户端的节点;random
- 随机选择一个节点。
[](()神奇的死信队列(Dead Letter)
=================================================================================
上面的参数介绍中,提到了死信队列,这又是什么新鲜的东西呢?其实从名字上来看很好理解,就是指的已死的消息,或者说无家可归的消息。一个消息进入死信队列,主要有以下三种条件:
-
1、消息被消费者拒绝并且未设置重回队列。
-
2、消息过期(即设置了
TTL
)。 -
3、队列达到最大长度,超过了
Max length
或Max length bytes
,则队列头部的消息会被发送到死信队列。
[](()死信队列实战
- 1、在上面定义的
RabbitConfig
类中,定义一个死信交换机,并将之前的ttl
队列新增一个属性x-dead-letter-exchange
,最后再将死信队列和死信交换机进行绑定:
//直连死信交换机(也可以用topic或者fanout类型交换机)
@Bean(“deatLetterExchange”)
public DirectExchange deatLetterExchange(){
return new DirectExchange(“LONGLY_WOLF_DEAD_LETTER_DIRECT_EXCHANGE”);
}
@Bean(“ttlQueue”)
public Queue ttlQueue(){
Map<String, Object> map = new HashMap<String, Object>();
map.put(“x-message-ttl”, 5000);//队列中所有消息5秒后过期
map.put(“x-dead-letter-exchange”, “LONGLY_WOLF_DEAD_LETTER_DIRECT_EXCHANGE”);//已死消息会进入死信交换机
return new Queue(“LONGLY_WOLF_TTL_QUEUE”,false,false,false,map);
}
//死信队列
@Bean(“deadLetterQueue”)
public Queue deadLetterQueue(){
return new Queue(“LONGLY_WOLF_DEAD_LETTER_QUEUE”);
}
- 2、在
ExchangeConsumer
消费者类上将监听TTL
队列的监听取消,注释掉监听:
/**
- 监听ttl消息队列
*/
@RabbitHandler
// @RabbitListener(queues = “LONGLY_WOLF_TTL_QUEUE”)
public void ttlConsumer(Message message){
System.out.println(“ttl队列收到消息:” + new String(message.getBody()));
System.out.println(“ttl队列收到消息:” + JSONObject.toJSONString(message.getMessageProperties()));
}
-
3、此时
TTL
队列无消费者,并且设置了消息的TTL
为5
秒,所以5
秒之后就会进入死信队列。 -
5、访问接口:
http://localhost:8080/exchange/send/ttl?routingKey=test&msg=测试死信队列
,发送消息之后,等待5
秒就查看消息,进入死信队列:
[](()消息真的发送成功了吗
=======================================================================
了解了消息的基本发送功能之后,就可以高枕无忧了吗?消息发出去之后,消费者真的收到消息了吗?消息发送之后如何知道消息发送成功了?假如发送消息路由错了导致无法路由到队列怎么办?大家是不是都有这些疑问呢?别着急,接下来就让我们来一一来分析一下。
一条消息从生产者开始发送消息到消费者消费完消息主要可以分为以下 4
个阶段:
-
1、生产者将消息发送到
Broker
(即:RabbitMQ
的交换机)。 -
2、交换机将消息路由到队列。
-
3、队列收到消息后存储消息。
-
4、消费者从队列获取消息进行消费。
接下来我们就从这 4
个步骤上来逐步分析 RabbitMQ
如何保证消息发送的可靠性。
[](()消息真的到达交换机了吗
当我们发送一条消息之后,如何知道对方收到消息了?这就和我们写信一样,写一封信出去,如何知道对方收到我们寄出去的信?最简单的方式就是对方也给我们回一封信,我们收到对方的回信之后就可以知道自己的信已经成功寄达。
在 RabbitMQ
中服务端也提供了 2
种方式来告诉客户端(生产者)是否收到消息:Transaction
(事务)模式和 Confirm
(确认)模式。
[](()Transaction(事务) 模式
在 Java API
编程中开启事务只需要增加以下代码即可:
try {
channel.txSelect();//开启事务
channel.basicPublish(“”, QUEUE_NAME, null, msg.getBytes());
channel.txCommit();//提交事务
}catch (Exception e){
channel.txRollback();//消息回滚
}
在 Spring Boot
中需要对 RabbitTemplate
进行事务设置:
@Bean
public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory){
RabbitTemplate rabbitTemplate = new RabbitTemplate();
rabbitTemplate.setConnectionFactory(connectionFactory);
rabbitTemplate.setChannelTransacted(true);//开启事务
return rabbitTemplate;
}
为了了解 RabbitMQ
当中事务机制的原理,我们在 Wireshark
中输入 ip.addr==192.168.1.1
对本地 ip
进行抓包,发送一条消息之后,抓到如下数据包:
通过数据包,可以得出开启事务之后,除了原本的发送消息之外,多出了开启事务和事务提交的通信:
开启事务之后,有一个致命的缺点就是发送消息流程会被阻塞。也就是说必须一条消息发送成功之后,才会允许发送另一条消息。正因为事务模式有这个缺点,所以一般情况下并不建议在生产环境开启事务,那么有没有更好的方式来实现消息的送达确认呢?那么就让我们再看看Confirm
(确认)模式。
[](()Confirm(确认)模式
消息确认模式又可以分为三种(事务模式和确认模式无法同时开启):
-
单条确认模式:发送一条消息,确认一条消息。此种确认模式的效率也不高。
-
批量确认模式:发送一批消息,然后同时确认。批量发送有一个缺点就是同一批消息一旦有一条消息发送失败,就会收到失败的通知,需要将这一批消息全部重发。
-
异步确认模式:一边发送一边确认,消息可能被单条确认也可能会被批量确认。
[](()Java API 实现确认模式
- 单条消息确认模式
channel.confirmSelect();//开启确认模式
channel.basicPublish(“”,QUEUE_NAME,null,msg.getBytes());
if (channel.waitForConfirms()){//wait.ForConfirms(long time)方法可以指定等待时间
System.out.println(“消息确认发送成功”);
}
- 批量确认模式
channel.confirmSelect();//开启确认模式
//批量发送
for (int i=0;i<10;i++){
channel.basicPublish(“”,QUEUE_NAME,null,msg.getBytes());
}
try{
channel.waitForConfirmsOrDie();
}catch (IOException e){//只要有1条消息未被确认,就会抛出异常
System.out.println(“有消息发送失败了”);
}
- 异步确认模式
channel.addConfirmListener(new ConfirmListener() {
/**
-
已确认消息,即发送成功后回调
-
@param deliveryTag -唯一标识id(即发送消息时获取到的nextPublishSeqNo)
-
@param multiple - 是否批量确认,当multiple=true,表示<=deliveryTag的消息被批量确认,multiple=false,表示只确认了单条
*/
@Override
public void handleAck(long deliveryTag, boolean multiple) throws IOException {//成功回调
System.out.println(“收到确认消息了”);
//TODO 可以做一些想做的事
}
/**
-
发送失败消息后回调
-
@param deliveryTag -唯一标识id(即发送消息时获取到的nextPublishSeqNo)
-
@param multiple - 是否批量确认,当multiple=true,表示<=deliveryTag的消息被批量确认,multiple=false,表示只确认了单条
*/
@Override
public void handleNack(long deliveryTag, boolean multiple) throws IOException {//失败回调
if (multiple) {//批量确认,<deliveryTag的消息都发送失败
//TODO 消息重发?
} else {//非批量,=deliveryTag的消息发送失败
//TODO 消息重发?
}
}
});
channel.confirmSelect();//开启确认模式
for (int i=0;i<10;i++){//批量发送
long nextSeqNo = channel.getNextPublishSeqNo();//获取发送消息的唯一标识(从1开始递增)
//TODO 可以考虑把消息id存起来
channel.basicPublish(“”,QUEUE_NAME,null,msg.getBytes());
}
[](()SpringBoot 实现确认模式
通过配置文件 spring.rabbitmq.publisher-confirm-type
参数进行配置确认(旧版本是 spring.rabbitmq.publisher-confirms
参数)。
- 1、新增配置文件属性配置
spring:
rabbitmq:
publisher-confirm-type: correlated # none-表示禁用回调(默认) simple- 参考RabbitExchangeController#sendWithSimpleConfirm()方法
- 2、
RabbitConfig
配置文件中修改如下:
@Bean
public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory){
RabbitTemplate rabbitTemplate = new RabbitTemplate();
rabbitTemplate.setConnectionFactory(connectionFactory);
// rabbitTemplate.setChannelTransacted(true);//开启事务
//消息是否成功发送到Exchange
rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {
@Override
public void confirm(CorrelationData correlationData, boolean ack, String cause) {
if (!ack){//消息发送失败
System.out.println(“消息发送失败,原因为:” + cause);
return;
}
//消息发送成功
System.out.println(“消息发送成功”);
}
});
return rabbitTemplate;
}
这样当我们发送消息成功之后,就会收到回调。
- 3、当上面的参数配置修改为
simple
,则需要在发送消息的时候使用invoke
调用waitForConfirms
或者waitForConfirmsOrDie
方法来确认是否发送成功:
@GetMapping(value=“/send/confirm”)
public String sendWithSimpleConfirm(String routingKey,@RequestParam(value = “msg”,defaultValue = “no direct message”) String msg){
//使用waitForConfirms方法确认
boolean sendFlag = rabbitTemplate.invoke(operations -> {
rabbitTemplate.convertAndSend(
“LONGLY_WOLF_DIRECT_EXCHANGE”,
“routingKey”,
msg
);
return rabbitTemplate.waitForConfirms(5000);
});
//也可以使用waitForConfirmsOrDie方法确认
boolean sendFlag2 = rabbitTemplate.invoke(operations -> {
rabbitTemplate.convertAndSend(
“LONGLY_WOLF_DIRECT_EXCHANGE”,
“routingKey”,
msg
);
try {
rabbitTemplate.waitForConfirmsOrDie(5000);
}catch (Exception e){
return false;
}
return true;
});
System.out.println(sendFlag);
System.out.println(sendFlag2);
return “succ”;
}
[](()消息无法从交换机路由到正确的队列怎么办
上面通过事务或者确认机制确保了消息成功发送到交换机,那么接下来交换机会负责将消息路由到队列,这时候假如队列不存在或者路由错误就会导致消息路由失败,这又该如何保证呢?
同样的,RabbitMQ
中也提供了 2
种方式来确保消息可以正确路由到队列:开启监听模式或者通过新增备份交换机模式来备份数据。
[](()监听回调
上面介绍的是消息是否发送到交换机的回调,而从交换机路由到队列,同样可以开启确认模式。
[](()Java API 方式开启监听模式
下面就是开启监听主要代码,为了节省篇幅,省略了其余不相干代码(完成代码已上传至 GitHub
)
channel.addReturnListener(new ReturnListener() {
@Override
public void handleReturn(int replyCode, String replyText, String exchange, String routingKey, AMQP.BasicProperties properties, byte[] body) throws IOException {
System.out.println(“收到未路由到队列的回调消息:” + new String(body));
}
});
//注意这里的第三个参数,mandatory需要设置为true(发送一个错误的路由,即可收到回调)
channel.basicPublish(EXCHANGE_NAME,“ERROR_ROUTING_KEY”,true,null,msg.getBytes());
[](()Spring Boot 开启监听模式
在 RabitConfig
类中添加如下配置:
@Bean
public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory){
RabbitTemplate rabbitTemplate = new RabbitTemplate();
rabbitTemplate.setConnectionFactory(connectionFactory);
rabbitTemplate.setMandatory(true);//开启监听回调
//消息是否成功被路由到队列,没有路由到队列时会收到回调(原setReturnCallback在2.0版本已过期)
rabbitTemplate.setReturnsCallback(new RabbitTemplate.ReturnsCallback() {
@Override
public void returnedMessage(ReturnedMessage returnedMessage) {
System.out.println(“收到未路由到队列的回调消息:” + new String(returnedMessage.getMessage().getBody()));
}
});
return rabbitTemplate;
}
[](()备份交换机
除了开启监听的方式,还可以通过定义备份交换机的方式来实现,当原交换机无法正确路由到队列时,则会进入备份交换机,再由备份交换机路由到正确队列(要注意区分备份交换机和死信交换机的区别)。
《一线大厂Java面试真题解析+Java核心总结学习笔记+最新全套讲解视频+实战项目源码》开源
Java优秀开源项目:
- ali1024.coding.net/public/P7/Java/git
独家面经总结,超级精彩
本人面试腾讯,阿里,百度等企业总结下来的面试经历,都是真实的,分享给大家!
Java面试准备
准确的说这里又分为两部分:
- Java刷题
- 算法刷题
Java刷题:此份文档详细记录了千道面试题与详解;
/消息是否成功被路由到队列,没有路由到队列时会收到回调(原setReturnCallback在2.0版本已过期)
rabbitTemplate.setReturnsCallback(new RabbitTemplate.ReturnsCallback() {
@Override
public void returnedMessage(ReturnedMessage returnedMessage) {
System.out.println(“收到未路由到队列的回调消息:” + new String(returnedMessage.getMessage().getBody()));
}
});
return rabbitTemplate;
}
[](()备份交换机
除了开启监听的方式,还可以通过定义备份交换机的方式来实现,当原交换机无法正确路由到队列时,则会进入备份交换机,再由备份交换机路由到正确队列(要注意区分备份交换机和死信交换机的区别)。
《一线大厂Java面试真题解析+Java核心总结学习笔记+最新全套讲解视频+实战项目源码》开源
Java优秀开源项目:
- ali1024.coding.net/public/P7/Java/git
独家面经总结,超级精彩
本人面试腾讯,阿里,百度等企业总结下来的面试经历,都是真实的,分享给大家!
[外链图片转存中…(img-auBd9TiR-1649666498751)]
[外链图片转存中…(img-YkmWxdat-1649666498752)]
[外链图片转存中…(img-sbMA2fSn-1649666498752)]
[外链图片转存中…(img-7m6j3Wap-1649666498752)]
Java面试准备
准确的说这里又分为两部分:
- Java刷题
- 算法刷题
Java刷题:此份文档详细记录了千道面试题与详解;
[外链图片转存中…(img-mmQkch7D-1649666498753)]
[外链图片转存中…(img-dZ37Uyj3-1649666498753)]