FastAPI-template中Taskiq调度器重复执行任务问题解析

问题现象

在使用FastAPI-template项目集成Taskiq任务队列时，开发者遇到了一个典型问题：定时任务被重复调度执行。从日志中可以看到，同一个任务在极短时间内被多次触发，导致系统资源浪费和潜在的数据一致性问题。

问题根源分析

经过深入分析，这个问题主要由两个关键因素导致：

1. 多源调度冲突：在配置中同时使用了LabelScheduleSource和RedisScheduleSource两个调度源，但没有正确处理它们的协作关系。

2. 启动逻辑不当：在lifetime.py中直接调用schedule_by_cron方法进行任务注册，同时又在任务装饰器中定义了调度规则，导致双重注册。

解决方案

方案一：统一使用标签调度

推荐使用LabelScheduleSource作为单一调度源，这是最简洁的解决方案：

# tkq.py配置示例
label_source = LabelScheduleSource(broker)
scheduler = TaskiqScheduler(broker=broker, sources=[label_source])

任务定义时只需在装饰器中声明调度规则：

@broker.task(
    task_name="heavy_task",
    schedule=[
        {
            "cron": "*/1 * * * *",
            "args": [10],
        },
    ],
)
async def heavy_task(a: int):
    # 任务实现

方案二：正确使用Redis调度源

如果确实需要使用Redis作为调度存储，应当：

1. 移除lifetime.py中的手动调度代码
2. 确保不重复注册相同的调度规则

# tkq.py配置示例
redis_source = RedisScheduleSource(str(settings.redis_url.with_path("/0")))
scheduler = TaskiqScheduler(broker=broker, sources=[redis_source])

最佳实践建议

1. 单一调度源原则：避免混合使用多个调度源，除非有明确的分布式调度需求。

2. 环境隔离：在不同环境(开发/测试/生产)中使用不同的Redis数据库或前缀，防止调度规则冲突。

3. 任务幂等性：即使出现重复执行，也应确保任务逻辑的幂等性。

4. 监控告警：对任务执行频率进行监控，异常时及时告警。

部署注意事项

在Docker Compose中启动调度器时，确保配置正确：

taskiq-scheduler:
    command:
    - taskiq
    - scheduler
    - -fsd
    - --skip-first-run
    - example_app.tkq:scheduler

关键参数说明：

• -fsd：启用快速关闭模式
• --skip-first-run：跳过首次立即执行
• 最后参数指向调度器配置模块

总结

Taskiq作为FastAPI生态中的任务队列解决方案，其调度功能强大但需要正确配置。通过本文的分析和建议，开发者可以避免常见的调度重复问题，构建稳定可靠的异步任务系统。对于复杂的调度需求，建议参考Taskiq官方文档深入了解高级调度策略。