MQ优势:

1.应用解耦

提高系统容错率和可维护率.  实现方式:将消息生产者与消费者之间,引入MQ,服务之间不直接调用,而是生产者将消息发送给MQ,由MQ分发给一个或多个消费者,即使一个服务出问题,也不会影响其他服务获取消息.

2.异步提速

原来同步调用方式的消耗时间是,消息生产者和每个消息消费者处理消息的时间总和,但是MQ利用异步调用方式,消耗时间仅是自己的处理时间和将消息转发给MQ消耗的时间,大大缩短了处理消息的时间.

3.削峰填谷

当在一定时间时并发量突然增加的时候,有可能就会导致超过系统的最大处理量,造成系统宕机,此时引入MQ,就可以将消息先接收到MQ中,然后消息排队,系统分批次处理,虽然时间慢,但是增加了系统的稳定性,这就是削峰.当高并发时间过后,MQ中肯定还会有堆积数据,还会交给系统处理,这个就是填谷.

思考-MQ存在的问题:

如何保证MQ的高可用?  通过构建高可用的MQ集群方式.

如何保证消息没有被重复消费? 幂等性处理

如何处理消息丢失情况?

1.rabbitMQ里的交换机,队列,消息中的数据是可以进行持久化的.

如何保证消息传递的顺序性?

如何保证消息数据处理的一致性?

RabbitMQ

MQ产品介绍:

RabbitMQ: 开发语言:Erlang  协议支持:AMQP  单级吞吐量:万级

RocketMQ:单级吞吐量最好 但是客户端支持语言少,技术不太成熟

Kafka:只要支持大数据领域

5种工作模式:

1.简单模式

发送方式: 一个生产者 - queue - 一个消费者

2.work模式:

发送方式: 一个生产者 - queue - 多个消费者按能力处理消息

使用场景:抢红包

3.广播模式:性能最高,因为不需要寻找queue

发送方式: 一个生产者 - exchange - 所有与交换机绑定的queue - 多个消费者 全部发送

使用场景:网站的推送消息,群聊,弹窗广告

4.路由模式

发送方式: 一个生产者 - exchange -所有与交换机绑定并符合条件的queue - 多个消费者

使用场景:app注册后根据不同的用户的信息选择发短信或邮件等

5.通配符(主题)模式

发送方式: 是路由模式的升级,引入通配符 *代表一个单词 #代表0或多个单词  注意是单词

生产者确认模式(confirm):

消息从product 到 exchange是否成功.成功和失败都可以监控

步骤:

1.在配置文件中开启生产者确认模式 spring.rabbit.publisher-confirm-type: correlated

2.新建一个配置类,实现RabbitTemplate.ConfirmCallback

1.重写confirm()确认方法 参数:ack表示消息到路由是否成功  cause表示失败原因

2.添加一个initRabbitTemplate()方法,添加@postConstruct(spring中的早期初始化注解)注解,写入代码:rabbitTemplate.setConfirmCallback(this::confirm); 代表在rabbitTemplate初始化完成后,立即执行这个方法,设置生产者确认机制和return机制.

生产者退回模式(return):

消息从exchange到 queue是否成功.只能检测到失败,成功不能监控

步骤:

1.在配置文件中开启生产者退回模式 spring.rabbit.publisher-returns: true

2.在上面的配置类中在实现一个接口:RabbitTemplate.ReturnsCallback

1.重写returnedMessage(returnedMessage returned) 消息从exchange到 routeKey是否失败

2.在initRabbitTemplate()方法中,添加rabbitTemplate.setReturnsCallback(this::returnedMessage)

消费者确认(ACK):

1.三种确认方式:

1.不确认:消息队列中的消息一旦被消费者接收就会删除.不建议使用.

2.自动确认:消费者自动应答,处理成功发出ack,处理失败发出nack,只有消息队列收到ack才会删除,但是容易出出现死循环,一直失败,一直重新消费消息,这种情况的解决方案是:设置失败重试次数或改为手动确认.

(1)开启失败重试的限制(默认是无限制重试):消费指定次数后,消息就删除了

3.手动确认:

需要认为调用channel.basiAck手动签收,或者channel.basicNack(),让其重发消息.

消费端限流:

设置限流的原因:当rabbitMQ中堆积了很多消息后,消费端启动时,默认全部拉取过来,就有可能造成数据量大,但处理能力不够,造成系统宕机.

设置方式:300-500较合适

TTL(存活时间/过期时间):

RabbitMQ可以对消息或队列设置过期时间,如果超过这个时间,消息没有被消费,那么就会自动删除.

控制台设置队列过期时间:常用,因为队列是先进先出,在最前面的普通消息没有被消费时,即使设置了过期时间的消息过期时间到了也不会删除.所以不推荐使用设置消息过期时间.设置队列过期时间,可以保证消息在同一时间同步删除.如果同时设置消息和队列的过期时间,则以时间短的为准删除消息.

控制台设置消息过期时间:

代码方式设置队列的过期时间:

代码方式设置消息的过期时间:

死信队列:当消息成为死信消息时,可以被重新发送到另一个死信交换机,然后再由死信交换机发送给对应队列.

消息成为死信的情况:

1.队列消息长度达到限制: 长度包括1.队列可存放消息的个数 2.队列可存放消息的大小

2.消费者拒接消费消息: 1.设置消息不重回队列 2.消费者拒绝接受消息

3.当消息到达过期时间后未被消费

设置死信队列绑定死信交换机: 死信交换机和队列就是普通交换机和队列,只不过需要和一个队列绑定.

代码实现:

1.创建死信交换机,死信队列,死信路由key.

2.把可能出现死信的队列设置死信交换机和死信路由key参数

延迟队列:消息进入队列后不会被立即消费,而是到达指定时间后才会被消费.(目前rabbitMQ没有提供这个功能)

使用场景:1.下单后,30分钟未支付,取消订单,回滚库存. 2.新用户注册成功7天后,发送短信问好.

实现方式:1.定时器 2.延迟队列

虽然RabbitMQ没有提供延迟队列,但是可以使用TTL+死信队列组合实现.

rabbitMQ应用问题:

1.消息幂等性处理:幂等性指一次和多次请求某一个资源时,对于资源本身应该具有同样的结果.在MQ中指,消费多条相同的消息,得到与消费一次相同的结果.

实现方式:1.乐观锁 在表中添加version字段 2.redis方式 分布式锁:如果出现重复消费,就利用redis的setnx设置分布式锁 一个key