延迟任务
什么是延迟任务
需要延迟一段时间才需要处理的任务. 比如订单关闭, 电商平台一般会给用户30分钟左右交钱时间, 当超时未交钱就需要关闭订单. 订单的延时关闭就是一种延迟任务.
怎么实现延迟任务
定时任务
最普遍的做法应该就是定时任务了, 比如订单关闭例子, 我们会将订单存储在表中, 通过定时任务定时扫表, 比如10分钟一次, 对扫描结果进行时间处理, 如果是超时订单则执行关闭操作.
定时任务实现简单, 缺点是时间延迟时间不准确, 在订单例子中, 如果第一次扫描发现订单为29分钟未支付, 那么该订单只能在第二次扫描时执行关闭, 此时订单已经是39分钟未支付了.
为了提供时间准确性, 我们可以减少定时任务时间, 比如一分钟一次. 时间越短准确性越高, 但是资源消耗的也越多.
RabbitMQ延迟队列
RabbitMQ本身没有延迟队列的概念, 但是它在处理死信时使用了类似的功能. 当队列中出现死信, 我们可以让它路由到指定的队列中, 然后再消费该队列消息, 达到延迟功能.
那么什么是死信 dead-lettered message?
官网解释在以下三种情况下message可以成为dead-lettered message
1 The message is negatively acknowledged by a consumer using basic.reject or basic.nack with requeue parameter set to false.
2 The message expires due to per-message TTL; or
3 The message is dropped because its queue exceeded a length limit
准确译文
1 被女神(消费者)拒绝的, 并且没有女朋友(requeue = false)就不让回家(重入队列)的你
2 岁数太大(达到ttl time to live)被公司辞退的你
3 站在车门口, 怎么也挤不上公交车(队列已满)的你
满足任意一个条件的话那你就可以称为~死信了
擦干眼泪我们继续看你的归处~
如果队列在声明的时候设置了dlx(dead letter exchange 就是一个Exchange), 当你满足条件的时候, queue会自动将你路由到该队列, 如果好巧不巧的这时候dlx还没有声明, 或者queue在声明的时候没有设置dlx, 那么你会像屁一样消失在这个世界, 还不能是响屁, 官网说的if it is missing then, the messages will be silently dropped.
合上下巴, 回头想想如何自救
对于第一种情况, 只能告诉你, 认清自己, 和父母搞好关系(.)
对于第三种情况, 早起5分钟能死么?
重点是第二种, 超时正好对应我们的延迟功能. 时间一天天过, 虽然你面相18, 实际已经过了三次本命年. 时间面前任何人任何事都是渣渣, 你能做的就是努力提升自己, 让你的实力 >= 年龄, 一直进步, ttl过期就是你走到更高level(英语已过CET-20)的时候.
努力要有目标, 在进入公司时就要有. 开始创建你的职业生涯~
声明职业生涯
名词解释
x-message-ttl 队列中消息存活时间, 单位ms, 超时则认为是死信
x-dead-letter-exchange 出现死信时路由到该参数指定的Exchange(dlx)
x-dead-letter-routing-key dlx路由到其他队列使用的routingKey
x-message-ttl属性就是我们可以利用的延迟时间, 设置好上面三个属性, 然后最后消费死信最终路由到的队列, 就完成了一个延迟任务的功能.
创建e.opportunity并通过r.raise绑定q.senior.engineer
延迟队列相关的设置好了, 还缺一个入口, 声明e.send, 用来发送消息到q.intermediate.engineer .
在控制台发送消息
成为一个中级工程师
30岁了! 恭喜你更进一步~
在这里可以看到一些参数, 比如成为死信的原因, 死信从哪个队列来的等.
policy
上面的步骤基本就可以实现RabbitMQ的延迟队列功能, 但是有个小问题, 如果我们想改变延迟时间怎么办? 在RabbitMQ中, 一旦声明了队列或者Exchange, 那么设置的属性是无法修改的, 像上面设置的ttl我们是没有办法在运行时修改的, 这种情况下, 我们只好重新创建一个队列, 设置指定的ttl. 那么有没有可以运行时修改延迟时间的办法呢? 有的~
RabbitMQ中运行时修改的参数叫做parameter, parameter不仅可以运行时修改, 还可以给集群中多个节点设置统一属性. 而policy就是某些特殊parameter, 其中就包括我们上线提到的ttl, dlx等.
设置policy很简单
这里的演示就有你来完成吧~ 需要注意的是运行时修改的message-ttl对于已经入队列的消息是无效, 这个也很合理, 否则也无法计算失效时间. dead-letter-exchange运行时修改对于入队列的消息是有效的. 猜想下这里的逻辑, 消息入队列, 根据队列message-ttl设置消息ttl, 当消息超时, 根据此时队列的dead-letter-exchange进行路由.
RocketMQ
内置18种消息延迟队列, 看起来理念和RabbitMQ差不多, 这个后面补一篇文章学习下
redis
设置key失效时间, 失效通知. 同上
kafka
时间轮~同上
总结
学习了RabbitMQ如何实现延迟任务, 并提供了其他几种实现(虽然作者还没有看...). 后面继续补充其他实现(really?)
