任务分发

有了基本的定时器实现方案，如果我们开发的是单机系统，就可以开始干活了，但如果是分布式，还需要把“定时”或“延时”的任务分发出去。

示例图：

每个实例每隔一个小时，会从数据库里获取下一个小时需要处理的定时任务，获取的时候只取符合task_id % shard_count = shard_id的任务。

当这些定时任务被触发之后需要通知用户侧，有两种思路实现：

1. 将任务被触发的信息封装成一条消息，发往消息队列，由用户侧对消息队列进行监听
2. 对用户预先配置的回调函数进行调用

两种方案各有优缺点，如果采用1，那么如果消息队列出现故障会导致整个系统不可用，当然，现在的队列消息一般都是高可用，大多数时候不用担心这个问题。其次，一般业务流程中间走消息队列的话会导致延时增加，定时任务若必须在触发后的几十毫秒到几百毫秒内完成的话，采取消息队列就有一定的风险。

如果采用2，会加重定时任务系统的负担。单机的定时器执行时最害怕的就是回调函数执行时间过长，这样会阻塞后续的任务执行。在分布式场景下，这种忧虑依然存在——一个不严谨的业务回调可能会直接拖垮整个定时任务系统。所以我们还要考虑在回调的基础上增加经过测试的超时时间设置，并且对由用户填入的超时时间做慎重的审核。