在我们的架构设计里面：架构图

存储 API 处于一种核心地位。

总体上来说，调度核心就是不断从存储 API 里面获取“近期”要调度的任务，而后尝试分派给不同的调度节点。

在设计存储 API 的时候至少要考虑以下因素：

每次获取的任务，是多长时间内要被调度执行的任务。例如说，是每次获取下一秒要执行的任务，还是获取下一分钟要执行的任务，还是就是单纯获取下一个任务，有存储的实现来决定怎么快速筛查下一个任务；
在存储的数据量非常庞大的情况下，API 层面是否会收到影响。例如说在 API 层面上是否要考虑分库分表，或者非结构化存储等方面的影响；
存储 API 要不要考虑缓存之类的问题

设计

暂时来说，如果不考虑增删改查任务的管理接口，那么调度核心和存储 API 的交互，一个方法就能解决问题：

type Storage interface {
     RunnableTasks(ctx context.Context) (<- chan Task, error)
}

那么对于调度核心来说，它的逻辑基本上就是：

tasks, err := s.RunnableTasks(ctx)
if err != nil {
    return err
}
for task := range tasks {
    schedule(task)
}

对于调度核心来说：

它可以通过 ctx 来中断存储实现，例如说当它调用 ctx 的 cancel 方法后，那么存储实现将不会再返回任何可执行的任务，并且 channel 会被关闭。这个作为一个信号了控制存储实现
它只需要不断循环从 tasks 里面获取任务。但是要注意，调度核心的速度必须快于存储实现的速度，才能及时将任务取走调度，否则就会出现积压，或者任务得不到调度的情况

总体思路类似于此。调度核心将不会关心任何存储、查找任务相关的事情，它只需要保证一件事：能够及时取走到时间的任务，并且执行调度。

所以隐患很明显，即 channel 本身不管设置多大的容量，都有可能阻塞生产者或者消费者。事实上，阻塞消费者并没有问题，阻塞生产者则会导致任务不能及时调度。但是这本身不是 API 设计的缺陷，而应该认为是实现的缺陷。

ecodeclub / ecron