跳转到内容
use-cases / byo-cron-per-tenant / hero
BYO cron / 每租户调度

让客户自带自己的 cron 调度。

客户输入 cron 表达式。你 POST 到他们容器的 crontab。不需要做共享队列的公平调度,不需要强制最小间隔,不需要处理「为什么我的任务在周一高峰没跑」的工单。

阅读 Cron API 文档
use-cases / byo-cron-per-tenant / mechanism

客户在你的 UI 里输入。你 POST 到他们的容器。

你的设置页渲染一个输入框。他们的租户容器暴露一个 Cron API。表单提交转发一次 POST。没有全局调度器、没有按租户过滤的逻辑、没有「全体客户最多 100 条任务」的硬上限。

your-backend → tenant-container
POST /users/root/entries
// 表单提交把客户的表达式原样转发
POST https://acme-cron.hoody.com/users/root/entries
Content-Type: application/json

{
  "schedule": "0 9 * * 1-5",
  "command": "/jobs/sync_crm.sh",
  "comment": "Sync Salesforce contacts",
  "enabled": true
}
tenant-container → your-backend
201 Created
HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": "sch_8a3f1c",
  "schedule": "0 9 * * 1-5",
  "next_run": "2026-05-04T09:00:00Z",
  "enabled": true
}

// 调度现在只在这个租户的 crontab 里,别处都没有

Hoody Cron 服务跑在每个租户容器内部,提供托管条目和按用户隔离。调度活在它要执行的位置。

use-cases / byo-cron-per-tenant / powers

BYO cron 给你共享调度器给不了的东西。

调度紧挨着工作时,多租户调度的规则改变了。约束是本地的。影响半径是本地的。功能也是本地的。

无共享队列

没有公平排队的开销

没有要争抢的全局线程池。最难缠的租户每分钟跑一次也饿不到安静的租户——他们根本不在同一份 crontab 上。

自助

客户自助,你不做校验

你不再是「*/1 * * * * 在你这个档位允许吗」的看门人。他们的容器、他们的 cron、他们的 CPU 账单。你的工单收件箱清空了。

随容器走

调度跟着租户一起发货

对租户容器做快照,crontab 也被快照。回滚、恢复、fork——调度一起带走。不需要外部调度器状态去同步。

use-cases / byo-cron-per-tenant / compare

共享多租户调度器 vs 容器绑定 cron。

差别体现在三个地方:客户体验、你的工单负担、工程面积。

维度共享调度器BYO 容器 cron
客户能选什么
最少 5 分钟、仅工作日、不能并发按档位限流、公平规则、高峰延后
他们容器扛得住的任何 5 字段 cron 表达式想 */1 * * * * 就 */1 * * * *;他们的 CPU 自己付账
校验在哪里发生
你的代码,在持久化前对全局队列模型校验正则 + 容量检查 + 档位检查 + 重叠检查
容器里的 cron 守护进程解析表达式只校验语法;容量是单个容器的,不是整支舰队的
故障影响半径
一个租户的慢任务把队列堵给所有人嘈杂邻居事故,按队列深度告警
一个容器的 cron 只拖累一个租户内核级隔离;舰队的其他部分毫无察觉

共享调度器版的这个功能是一片注意事项的海洋。BYO 版只是一个 5 字段输入框。

use-cases / byo-cron-per-tenant / support

cron 变成每租户后消失的东西。

停止运营全局队列那天起会变化的三个数字。每一个都对应一类你不再需要写或运维的功能。

  1. 需要维护的校验规则0

    不再有按档位的最小间隔、按租户的最大任务数、公平调度旋钮。容器就是上限。

  2. 每次创建一个调度只 POST 一次

    客户输入,你转发,容器解析。设置页提交是单次 REST 调用,不是编排。

  3. 客户拥有的字段5

    分钟 · 小时 · 日 · 月 · 周几。再加宏(@hourly、@daily)。标准 POSIX,不是你的 DSL。

数字反映 BYO 容器绑定模型——实际 cron 条目随每个容器的 CPU 与客户套餐扩展。

use-cases / byo-cron-per-tenant / punchline

客户的 cron 表达式归客户,不需要你对照全局队列去校验。

共享调度器BYO 每租户 cron
之前if (tier !== 'enterprise' && interval < 5min) reject()校验税:每个客户都为最差的客户买单
之后POST /users/root/entries → 201 Created调度活在他们的容器里;他们的 CPU、他们的规则
查看 Cron API
use-cases / byo-cron-per-tenant / replaces

它替代了什么。

BYO 容器绑定 cron 悄悄淘汰的基础设施。

  • 共享多租户调度器没有可公平调度的全局队列
  • 带租户过滤的 Quartz每行任务上不再有 tenant_id 列
  • 自建的 cron-as-config UI客户输入,容器解析
  • 厂商托管的 Airflow为一个 5 字段表达式不用上 DAG 服务
  • 带限流的共享 Sidekiq不再有跨租户的全局速率限制
  • 带租户队列的 BullMQ不必为每位客户照看一份 Redis
use-cases / byo-cron-per-tenant / cta

别再当别人调度的看门人。把 cron 字段交给他们,把工作交给他们的容器。

阅读文档
use-cases / byo-cron-per-tenant / related

阅读其他内容