关闭

最佳实践----状态机对多步骤异步操作建模

标签: 状态机 异步
514人阅读 评论(1) 收藏 举报
分类:

在工作中,我们往往会遇到这样的问题,一个任务分为多个步骤,这几个步骤可能是连续的,也可能是可以跳转的,每个步骤都可能是异步的,

对于这样的问题,有没有一个通用的解决方案,或者是一个最佳实践呢,经过一些实践和推论我得出了一个最佳实践方案---》状态机。

推理如下,等待大家拍砖指点。

问题

首先将我们要讨论的问题进行简单建模,以四个子流程的异步任务为例, 核心处理流程如上图所示,4个需求:

1. 四个子流程,顺序执行。

2. 其中的每个步骤都可能是异步的。

3. 每个步骤都可能出错,出错之后跳到错误处理子流程

4. 执行的过程中如果出错,能够保存序列处理状态,下次启动之后从自动从该状态恢复。

以下就从这四个方面讨论不同实现的优劣。

问题建模

我们首先将抽离问题模型:一个任务T(task)S1S2S3S4(step)组成,如何对问题建模?


以下分步骤提出问题并以代码呈现的方式解决问题。

 

第一步满足需求1: 多个步骤顺序执行,如果是同步代码,我们往往会写成如下形式。


 


第二步满足需求2,3: 每个步骤都是异步的,且可能跳转到其他步骤。

 

在这里我们定义S1S2S3S4都是异步的,且若S1S2S3有任何一步失败,都会跳转到S4.

为了便于表达, 这里我把每个步骤增加一个返回值,作为是否跳转依据, 修改后的模型代码如下(Callback<Boolean>即返回Boolean类型的异步回调):


 

 

第三步满足需求4: 保存序列处理状态,并从中恢复。

我们再提出第三个需求,S1-S4的过程中可能进行到任何一个步骤系统退出,需要下一次重启之后继续从上一次的任务执行状态中恢复。

 

原来的异步代码依赖语言级闭包运行,无法从中间状态开始(比如越过S1,从S2->S4),但如果我们转换思想,将语言级的闭包变成自定义的局部上下文(状态机),一切迎刃而解,实现方案如下:

 

如上所述,当再遇到此类问题时,可首先套用该方案实施。

1
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:2739次
    • 积分:123
    • 等级:
    • 排名:千里之外
    • 原创:10篇
    • 转载:0篇
    • 译文:0篇
    • 评论:1条
    文章存档
    最新评论