千万级延时任务队列如何实现，看美图开源的-LMSTFY

最新推荐文章于 2024-08-20 09:59:49 发布

高可用架构

最新推荐文章于 2024-08-20 09:59:49 发布

阅读量1.5k

点赞数 1

本文链接：https://blog.csdn.net/weixin_45583158/article/details/103296277

版权

LMSTFY是美图基于Redis实现的延时任务队列服务，支持延时、优先级、自动重试和横向扩展等功能。本文介绍了其设计和实现，包括使用场景、整体设计、数据存储、任务写入和消费等，并探讨了如何实现服务的高可用和可扩展性。

摘要由CSDN通过智能技术生成

导读：Task是web开发中一个经典场景，我们时常需要延时任务，或者定时任务，通常都需要任务队列。常见的任务队列如celery，lmstfy是美图开源的任务队列。本文作者详细剖析了lmstfy的架构实现，干货满满，适合技术人员阅读。

lmstfy(Let Me Schedule Task For You) 是美图架构基础服务团队在 2018 年初基于 Redis 实现的简单任务队列(Task Queue)服务，目前在美图多个线上产品使用接近两年的时间。主要提供以下特性:

任务具备延时、自动重试、优先级以及过期等功能
通过 HTTP restful API 提供服务
具备横向扩展能力
丰富的业务和性能指标

Github 项目地址: https://github.com/meitu/lmstfy

使用场景

任务队列跟消息队列在使用场景上最大的区别是：任务之间是没有顺序约束而消息要求顺序(FIFO)，且可能会对任务的状态更新而消息一般只会消费不会更新。类似 Kafka 利用消息 FIFO 和不需要更新(不需要对消息做索引)的特性来设计消息存储，将消息读写变成磁盘的顺序读写来实现比较好的性能。而任务队列需要能够任务状态进行更新则需要对每个消息进行索引，如果把两者放到一起实现则很难实现在功能和性能上兼得。在美图内部选型上，如果是异步消息模型一般会选择消息队列，比如类似日志上报，抢购等。而对于需要延时/定时下发或者修改状态任务则是使用任务队列。

比如在以下几种场景会使用任务队列:

定时任务，如每天早上 8 点开始推送消息，定期删除过期数据等
任务流，如自动创建 Redis 流程由资源创建，资源配置，DNS 修改等部分组成，使用任务队列可以简化整体的设计和重试流程
重试任务，典型场景如离线图片处理

目标与调研

在自研任务队列之前，我们基于以下几个要求作为约束调研了现有一些开源方案:

任务支持延时/优先级任务和自动重试
高可用，服务不能有单点以及保证数据不丢失
可扩展，主要是容量和性能需要可扩展

第一种方案是 Redis 作者开源的分布式内存队列 disque(https://github.com/antirez/disque)。disque 采用和 Redis Cluster 类似无中心设计，所有节点都可以写入并复制到其他节点。不管是从功能上、设计还是可靠性都是比较好的选择。我们在 2017 年也引入 disque 在部分业务使用过一段时间，后面遇到 bug 在内部修复后想反馈到社区，发现 Redis 作者决定不再维护这个项目(要把 disque 功能作为 redis module 来维护，应该是会伴随 Redis 6 发布)。最终我们也放弃了 disque 方案，将数据迁移到我们自研任务队列服务。

第二种方案是 2007 年就开源的 beanstalkd(https://github.com/beanstalkd/beanstalkd)，现在仍然还是在维护状态。beanstalkd 是类 memcached 协议全内存任务队列，断电或者重启时通过 WAL 文件来恢复数据。但 benstalkd 不支持复制功能，服务存在单点问题且数据可靠性也无法满足。当时也