1 简介
任务是需要资源(CPU 时间、内存、存储、网络带宽等)在指定时间内完成的一段计算工作。
通过智能地将资源分配给任务以满足任务级和系统级目标的系统称为任务调度程序。
任务调度程序：
及时决定和分配资源给任务的过程称为任务调度。
当我们在 Facebook 发表评论时。我们不会让评论发布者等待直到那条评论被交付给所有关注者。交付被委托给一个异步任务调度程序离线完成。
在分布式系统中，许多任务是在用户的单个请求的背景下运行。考虑Facebook、WhatsApp 或 Instagram 这样的热门系统有数亿用户。这些系统需要一个任务调度程序来处理数十亿个任务。Facebook 使用 Async 根据其用户的数十亿个并行异步请求来调度其所有任务。
Async 是 Facebook 自己的分布式任务调度程序，调度其所有任务。一些任务时间敏感，如应该运行的通知用户某项活动开始直播的任务。如果用户在直播结束后才收到通知就没意义了。某些任务可延迟，如向用户提出好友建议的任务。Async 根据适当的优先级调度任务。
2 需求
- 可用性：系统应高可用以调度和执行任务
- 持久性：系统收到的任务应持久化，不应丢失
- 可扩展性：系统应能每天调度和执行越来越多的任务
- 有限的等待时间：这是任务在开始执行之前需要等待的时间。我们不能在预期时间之后执行任务。用户不应该无限期地等待。如果用户的等待时间超过一定阈值，他们应该收到通知
3 组件设计
3.1 任务调度程序架构设计
① Task Submitter（任务提交者）
接受任务。没有单一的任务提交者。相反，我们有一组接收越来越多任务的节点。
② Database（数据库）
任务提交者接收的所有任务都存储在分布式数据库。使用关系数据库来存储：
- task IDs
- user IDs
- 所需资源
- 执行上限
- 客户端尝试总次数
- 延迟容忍度
- ...
使用有向无环图（DAG）存储依赖任务的数据的图数据结构的非关系数据库。
③ Batching and prioritization（批处理和优先级）
将任务存储在 RDB 后，将任务分批。优先级基于任务的属性，如：
- 延迟容忍度
- 或执行时间短的任务等。
将最高 K 优先级的任务推送到分布式队列，K限制可以推送到队列的元素数量。K值取决许多因素，如：
- 当前可用资源
- 客户端
- 或任务优先级
- 订阅级别
④ Queue manager（队列管理器）
队列管理器在队列中添加、更新或删除任务。它跟踪我们使用的队列的类型。它还负责保持任务在队列中直到成功执行。如果任务执行失败，该任务将再次出现在队列。队列管理器知道在高峰时段、非高峰时段应该运行什么队列。
⑤ Resource manager（资源管理器）
知道哪些资源空闲。它从分布式队列中拉取任务并分配给它们资源。资源管理器：
- 跟踪每个任务的执行情况
- 并将其状态发送回队列管理器
若任务超出其能力或所需的资源使用，则终止该任务，并将状态发送回任务提交者，后者将通过错误消息通知客户端有关任务终止的情况。
4 执行上限
4.1 任务分类
- 不能延迟的任务 - 紧急任务
- 可延迟的任务
- 需定期执行的任务 - 周期性任务
基于任务类别的多个队列：
系统需确保非紧急队列中的任务不会被饿死。一旦某些任务的延迟限制即将达到，它就会被移动到紧急任务队列以获得优先服务。
4.2 优先级
一些任务执行时间很长并占用资源，阻塞其他任务。在调度任务时，执行上限（execution cap）是个重要参数。
若我们完全分配资源给单个任务并等待该任务完成，则由于任务脚本错误，某些任务可能不会停止，无法完成执行。我们允许用户为其任务设置执行上限。指定时间后停止任务执行，释放资源并分配给队列中的下一任务。若由于执行上限而停止任务执行，系统会通知所属用户的这些实例。他们需针对这种情况采取人工兜底。
5 任务紧急执行
有些任务需紧急执行。如Facebook社交应用中，用户可在紧急情况下标记自己是安全的，如地震。执行此活动的任务应及时执行，否则此功能对 Facebook 用户毫无用处。向客户发送电子邮件通知，告知其账户扣除一定金额的资金，是另一个需要紧急执行的任务示例。
为优先处理任务，任务调度程序为每个任务维护一个delay tolerance（延迟容忍度）参数，并在接近其延迟容忍度时执行该任务。
延迟容忍度是任务执行可延迟的最大时间量。首先执行延迟容忍时间最短的任务。通过使用延迟容忍参数，可在高峰时段推迟延迟容忍值更长的任务，为紧急任务留出空间。
6 资源容量优化
有时资源接近过载阈值(如超过 80% 利用率)，这就是高峰期。同一资源在非高峰时段可能闲置。所以，须考虑如何在非高峰时段更好利用资源及如何在高峰时段保持资源可用。
有些任务无需紧急执行。如Facebook社交应用，建议好友不是紧急任务。可以为这样的任务创建一个单独的队列，并在非高峰时段执行它们。如果我们一直有比可用资源更多的工作要做，我们可能会遇到容量问题，就该配置更多资源。
7 任务幂等性
如果任务成功执行，但由于某些原因机器无法发送确认，则调度程序将再次调度该任务。再次执行该任务。
我们不希望再次执行任务时最终结果发生更改。这在转账时对金融应用程序至关重要。我们要求任务是幂等的。幂等任务无论执行多少次都会产生相同的结果。
此属性是由开发人员在实现中添加的，通过某些内容(例如名称)来标识该属性并覆盖旧的。
8 评估
8.1 可用性
任务提交是由多个节点完成的。若提交任务的节点失败，其他节点将接替其位置。推送任务的队列在本质上也是分布式，确保可用性。由于持续监控是否需要添加或删除资源，可尽力保证始终有可用资源。设计中的每个组件都是分布式的，使得整个系统可用性大大增强。
8.2 持久性
我们将任务存储在持久化分布式数据库中,并在接近执行时间时将任务推送到队列中。一旦提交任务,它就会在数据库中直到执行完成。
8.3 可扩展性
任务调度程序提供可扩展性，因为设计中任务提交者是分布式的。可向集群添加更多节点以提交大规模数量的任务。
然后将这些任务保存到也是可扩展的分布式关系数据库中。
再从 RDB 将任务推送到分布式队列，它可随任务数量增加而扩展。可为不同类型的任务添加更多队列。还可根据资源与需求比添加更多资源。
8.4 容错性
任务在首次发送执行时不会从队列中删除。如果执行失败，将尝试最大允许次数的重试。若任务包含死循环，会在指定时间后终止任务并通知用户。
参考：