应对场景
订单创建后--->开始锁库存
而如果之后的服务出现异常,在订单创建的簇点会自动设置逻辑来处理
但是之后解锁库存则需要延时队列来解决
采用定时任务检查的话
有以下问题:
- 时效性(存在较大的时间误差):即使订单支付倒计时30min但是可能你正好在定时任务检查之后的1min时创建,那么下次检查你也会避过,只有到下下次才会被发现
- 消耗系统内存
- 增加数据库的压力
所以使用了延时队列
名词
TTL:存活时间
死信:
1. 已经超过存活时间的信息
1. 被consumer拒绝且设置了不再放入队列中
延时队列实现有两个方式:
设置队列过期时间实现延时队列!
设置消息过期时间实现延时队列
更建议的是:设置延时队列的方式
因为通过消息延时队列的方式,例如我们先有一个5min过期的,然后有个1min过期的,还有个1s过期的,按理说应该是1min这些的会快于5min的成为死信,但是rabbitMQ的检查是否TTL结束,是惰性的,也就是查到个5min的没过期会之后等个5分钟,再过来检查,这就导致1min的绝对在5min后成为死信,与我们的逻辑就不相符了
第一种方式具有以下优势：
- 性能优化：使用第一种方式，RabbitMQ 可以在队列过期时进行惰性检查（lazy check），只有在需要时才会删除过期的队列。这样可以减少系统资源的占用，避免频繁的消息删除操作。
- 简化消息管理：给队列设置过期时间意味着消息的过期时间是固定的，而不需要为每个消息单独设置过期时间。这样可以简化消息的管理和维护。
- 避免消息堆积：如果给消息设置过期时间，那么即使消费者无法及时处理消息，消息仍然会堆积在队列中，占用系统资源。而给队列设置过期时间可以确保在一定时间内没有消费者时，队列及其相关的消息会自动删除，避免了消息的堆积问题。
Problem
1
如果配置Configuration后
在里面创建一些交换机和队列后打开rabbitMq发现没有作用
tips:弄一个
@RabbitListener(queues = "stock.release.stock.queue")
public void handle(Message message) {
}
即可,rabbitMQ会重新扫描
2
如果消息有一个获取不到记得看看queue的详情,
看看是不是多个consumer,尤其是我们在MyMQconfig里面有没有配置多个