如何为多台机器分配周期性任务并尽可能保持任务运行的机器一致性？

这是个很典型的分布式周期性任务调度+任务亲和性问题，结合你的技术栈，我整理了几个实用的方案，从轻量的算法优化到成熟的工具库都有：

一、基于现有表结构的轻量算法优化（无需新增字段） #

如果不想改动任务表结构，我们可以通过哈希分区+本地优先遍历的思路，让任务尽可能落在同一台机器上，同时支持动态增减机器：

核心思路 #

1. 机器动态标识与哈希分区

   • 每台机器启动时，生成一个唯一标识（比如主机名socket.gethostname()、进程ID，或者临时UUID）。
   • 所有机器通过心跳机制感知当前在线机器总数：在MySQL建一张machine_heartbeat表，每台机器10秒更新一次心跳记录，查询该表即可获取在线机器数（过滤掉30秒内无心跳的机器）。
   • 对每个任务的job_id做哈希计算，用hash(job_id) % 在线机器数得到该任务的“归属机器索引”，每台机器优先处理归属自己索引的任务。

2. 任务遍历优先级调整

   • 每台机器遍历任务时，先筛选出归属自己索引的任务，按last_run_time升序排序（优先处理最该运行的任务），检查是否满足last_run_time + interval <= 当前时间且running=False。
   • 当自己归属的任务没有待运行的，再遍历其他任务，避免任务饥饿。

3. 原子锁保障唯一性

   • 拿到待运行任务后，必须用MySQL的原子更新抢占锁：

     UPDATE jobs SET running = TRUE WHERE job_id = ? AND running = FALSE
     

   • 执行后检查影响行数，如果是1，说明成功抢占，开始执行任务；如果是0，说明已被其他机器抢占，直接跳过。

优势 #

• 完全不用修改现有任务表结构，操作成本低。
• 机器增减时，只有部分任务会切换机器（哈希结果变化的那些），大部分任务仍保持亲和性。
• 依赖MySQL原生特性，无需引入额外中间件。

二、用成熟工具库简化实现 #

如果不想自己写调度逻辑，推荐用Python生态里的分布式任务调度库，天然支持任务亲和性和动态机器扩容：

1. Celery（最常用） #

Celery是Python生态最成熟的任务队列，结合Redis/RabbitMQ做Broker，可以轻松实现任务亲和性：

• 队列路由策略：给每台机器创建一个专属队列（比如queue_machine_0、queue_machine_1），同时保留一个通用队列queue_common。
• 任务分配规则：将任务按hash(job_id) % 机器数路由到对应专属队列，只有当专属队列没有任务时，机器才去消费通用队列的溢出任务。
• 动态扩容：直接启动新的Celery Worker即可，Worker会自动加入集群，任务路由规则会根据机器数自动调整（需在Worker启动时动态获取机器数）。
• 任务执行完后，用Celery的on_success信号更新MySQL的last_run_time和running字段。

2. Dramatiq（轻量替代） #

如果觉得Celery太重，Dramatiq是个更轻量的选择，配置简单，同样支持队列路由：

• 类似Celery的思路，给每个机器分配专属队列，任务通过哈希路由到对应队列，实现亲和性。
• 支持Redis/RabbitMQ，甚至可以用MySQL做结果存储，完美适配你的技术栈。

3. APScheduler（分布式扩展） #

如果想继续用MySQL做任务存储，APScheduler支持MySQL作为JobStore，你可以自定义任务分配策略：

• 扩展APScheduler的Executor，让任务优先分配给哈希归属的机器（无需新增last_run_on_machine字段）。
• 结合APScheduler的分布式锁机制，避免任务重复执行。

三、关键细节优化 #

1. 索引优化：给任务表加联合索引CREATE INDEX idx_job_runnable ON jobs (running, last_run_time)，大幅提升待运行任务的查询速度。
2. 超时处理：如果任务执行超时（比如超过60秒），需要自动将running设为False，避免任务一直被锁定。可以用MySQL的事件调度器，或者在机器上定时检查超时任务。
3. 故障恢复：如果某台机器宕机，其专属任务会在其他机器的溢出遍历中被处理，不会出现任务丢失。

内容的提问来源于stack exchange，提问作者Arch1tect