消息中间件使用场景

消息中间件

谈谈开发中应用消息中间件的场景&＃xff1f;或适用的场景&＃xff1f;

适合场景&＃xff1a;不需要实时性的

可以达到什么效果&＃xff1a;

• 1&＃xff0c;解耦
• 2&＃xff0c;异步化
• 3&＃xff0c;限流消峰

案例

1&＃xff0c;商品管理&＃xff08;静态页面&＃43;搜索页面&＃xff09;

以上是同步的方式

消耗的时间&＃xff1a; T1&＃43;T2&＃43;T3

处于耦合状态&＃xff1a;某个系统有问题&＃xff0c;会有影响&＃xff0c;或者新增一个系统&＃xff0c;也会影响到我们的代码

并不符合我们说的设计原则&＃xff1a;OCP原则&＃xff0c;开闭原则

解耦&＃xff1a;
时间&＃xff1a;T1&＃43;t1

处于解耦的状态

2&＃xff0c;基础服务&＃xff0c;都已经采用异步的方式来为其他系统提供服务&＃xff08;短信&＃xff0c;邮件&＃xff0c;积分等等&＃xff09;

3&＃xff0c;限流削峰

就是前后两个交互的系统处理的速度不匹配&＃xff0c;为了保护处理慢的系统&＃xff0c;从而引入消息中间件&＃xff0c;来实现削峰限流处理
方案一&＃xff1a;异步写的方案&＃xff0c;保护数据库&＃xff0c;缓解瞬间写的压力

方案二&＃xff1a;再比如秒杀系统&＃xff0c;会产生很多的订单信息&＃xff0c;此时也可以通过MQ来保护订单系统。

限流好处&＃xff1a;节省服务器成本

如何保证消息的可达或不丢失&＃xff1f;

1&＃xff0c;背景&＃xff1a;

网络是不可靠的

像我们上面所描述的各种场景&＃xff0c;一旦消息出现丢失&＃xff0c;将会造成各种问题。比如邮件没有发送&＃xff0c;短信没有收到等等。

2&＃xff0c;解决方案&＃xff1a;

确认机制&＃43;补偿发送

这个问题需要分为多个节点来考虑

这里面的每个环节出问题都有可能造成消息的不可达&＃xff0c;所以&＃xff0c;我们需要保证针对每个环节设计解决方案

1&＃xff0c;消息要发送到MQ服务器

解决的方式有两种&＃xff1a;

方式一&＃xff1a;事物的方式&＃xff08;了解即可&＃xff0c;性能不佳&＃xff09;

方式二&＃xff1a;异步confirm模式&＃xff0c;推荐&＃xff0c;客户端通过设置cnfirm监听器&＃xff0c;获取MQ服务器的异步响应。

如果消息成功传递到MQ服务器&＃xff0c;则服务器会传递回ACK&＃61;true,否则ACK&＃61;false

2, return机制&＃xff0c;保证消息到了MQ服务器之后&＃xff0c;是否能正确路由到交换机或者队列&＃xff0c;这个是在正常情况下是不会发生的&＃xff0c;所以一般在开发中我们会忽略掉这个设置

3&＃xff0c;消息队列做持久化

消息成功传递到MQ服务器之后&＃xff0c;还需要对消息队列做持久化&＃xff0c;否则一旦消息服务器宕机&＃xff0c;那么未处理的消息将会丢失

4&＃xff0c;消费端的手工确认模式开启&＃xff0c;只有消费端手工确认之后&＃xff0c;才表示这个消息已经被正确处理了

这个环节是确保消息真的被消费端正确处理了&＃xff0c;如果没有被正确处理&＃xff0c;那么消息还是需要重新处理的。

1&＃xff0c;有可能MQ服务器没有收到消费端发送的确认消息&＃xff0c;会重复处理&＃xff0c;所以要保证接口的幂等性,

2&＃xff0c;为了避免重复处理不成功&＃xff0c;造成阻塞&＃xff0c;所以&＃xff0c;我们引入有固定次数的重试机制 &＃xff08;失败的情况&＃xff09;

当然为了避免消息重复处理依然失败的情况&＃xff0c;我们一般设置为重复处理三次&＃xff0c;如果三次还是有问题&＃xff0c;

则应该讲错误信息记录到日志中&＃xff0c;然后人工介入处理。避免堵塞到后面的消息处理。

什么是延迟队列&＃xff1f;

作用&＃xff1a;

需要延迟处理的消息&＃xff0c;我们将使用延迟队列来达到这个效果

背景&＃xff1a;

比如订单超时未支付&＃xff0c;我们需要取消订单&＃xff0c;解锁库存。

实现方案&＃xff1a;

方案一&＃xff1a;采用定时任务

通过定时任务扫描订单表&＃xff0c;判断订单的下单时间跟当前时间的时间差&＃xff0c;如果超过指定时间&＃xff0c;比如30分钟&＃xff0c;则取消订单。但是这个方案存在问题&＃xff0c;就是频繁扫描订单表&＃xff0c;会给数据库带来较大的压力

一秒一次 30*60&＃61;1800次

方案二&＃xff1a;采用消息队列提供的延迟队列&＃xff0c;跟数据库的交互只需要一次
消息超过了有效期&＃xff0c;没有人处理&＃xff0c;就称为死信