系统设计经验谈（二）

在以后的系统设计经验谈中，我将对各条“经验”进行具体的解释。

 

 

1。 在任务调度模型中，管理者到执行者的指令级的调度未必可靠，（调度链路可能挂了，而执行者没挂）所以在调度模型中管理者的设计尤其复杂。

 

典型过程模拟：

1。 管理者A调度执行者B执行一段指令。

2。 执行者B正在执行，但是和管理者A的通信链路挂掉了。

3。 管理者A没有收到执行者B的反馈，认为它可能任务超时了。

4。 管理者A需要调度另一个执行者C来重新执行这个指令。

 

这时会出现两个执行者同时执行一段指令，若指令中有对临界资源的并发访问，则很可能会出问题。

所以在此调度模型中，有两个设计的基本原则尤其重要：

1。 任务可重入性

必须允许多个执行者可以同时/并发执行任务而互不干扰。

 

2。 任务结果的可丢弃性

在刚才的典型过程中，若执行者B和管理者A的通信链路又修复了，B和C一起向A汇报任务完成，则必须丢弃一个。

 

所以在这种调度模型中，执行者的设计、实现必须符合以上原则。

 

2。复杂任务的崩溃恢复可以记录运行历史来恢复；也可以从头模拟运行，将中间实际的计算任务结果全部都cache住，立即返回。

 

对于复杂任务（比如基于一个任务批处理脚本），如果我们需要对齐进行崩溃恢复，则需要记录任务的各种中间态。比如各种变量的值，各种逻辑分支的选择结果。那么会使得我们的任务批处理脚本的解析器还需要记录各种任务运行中的状态，会很复杂。

 

其实可以在批处理脚本运行过程中，就将耗时的计算结果（比如某函数）全部缓存起来，在崩溃之后，恢复时我们只需要查缓存表，就可以迅速的恢复到之前运行的状态。