mirror of
https://gitee.com/jd-platform-opensource/asyncTool.git
synced 2026-03-22 12:27:15 +08:00
update README.md.
This commit is contained in:
14
README.md
14
README.md
@@ -17,7 +17,7 @@
|
||||
`如用户可以通过邮箱、手机号、用户名登录,登录接口只有一个,那么当用户发起登录请求后,我们需要并行根据邮箱、手机号、用户名来同时查数据库,只要有一个成功了,都算成功,就可以继续执行下一步。而不是先试邮箱能否成功、再试手机号……`
|
||||
|
||||
|
||||
`再如某个接口,有5个前置任务需要处理。其中有3个是必须要执行完毕才能执行后续的,另外2个是无所谓的,只要这3个执行完就可以进行下一步,到时另外2个如果成功了就有值,如果还没执行完,就是默认值。`
|
||||
`再如某个接口,有5个前置任务需要处理。其中有3个是必须要执行完毕才能执行后续的,另外2个是非强制的,只要这3个执行完就可以进行下一步,到时另外2个如果成功了就有值,如果还没执行完,就是默认值。`
|
||||
|
||||
3 需要进行线程隔离的多批次任务
|
||||
|
||||
@@ -25,7 +25,7 @@
|
||||
|
||||
4 单机工作流任务编排
|
||||
|
||||
5 爬虫相关,有前后依赖关系
|
||||
5 其他有顺序编排的需求
|
||||
|
||||
#### 并行场景之核心——任意编排
|
||||
1 多个执行单元的串行请求
|
||||
@@ -55,9 +55,9 @@
|
||||
#### 并行场景可能存在的需求之——每个执行结果的回调
|
||||
传统的Future、CompleteableFuture一定程度上可以完成任务编排,并可以把结果传递到下一个任务。如CompletableFuture有then方法,但是却无法做到对每一个执行单元的回调。譬如A执行完毕成功了,后面是B,我希望A在执行完后就有个回调结果,方便我监控当前的执行状况,或者打个日志什么的。失败了,我也可以记录个异常信息什么的。
|
||||
|
||||
此时,传统的就无能为力了。
|
||||
此时,CompleteableFuture就无能为力了。
|
||||
|
||||
我的框架提供了这样的回调功能。并且,如果执行失败、超时,可以在定义这个执行单元时就设定默认值。
|
||||
我的框架提供了这样的回调功能。并且,如果执行异常、超时,可以在定义这个执行单元时就设定默认值。
|
||||
|
||||
#### 并行场景可能存在的需求之——执行顺序的强依赖和弱依赖
|
||||
如上图的3,A和B并发执行,最后是C。
|
||||
@@ -70,6 +70,12 @@
|
||||
|
||||
如果依赖的都不是must,那么就可以任意一个依赖项执行完毕,就可以执行自己了。
|
||||
|
||||
注意:这个依赖关系是有必须和非必须之分的,还有一个重要的东西是执行单元不能重复执行。譬如图4,如果B执行完毕,然后执行了A,此时C终于执行完了,然后也到了A,此时就会发现A已经在执行,或者已经完毕(失败),那么就不应该再重复执行A。
|
||||
|
||||
还有一种场景,如下图,A和D并行开始,D先执行完了,开始执行Result任务,此时B和C都还没开始,然后Result执行完了,虽然B和C都还没执行,但是已经没必要执行了。B和C这些任务是可以被跳过的,跳过的原则是他们的NextWrapper已经有结果了或者已经在执行了。我提供了checkNextWrapperResult方法来控制,当后面的任务已经执行了,自己还要不要执行的逻辑控制。当然,这个控制仅限于nextWrapper只有一个时才有成立。
|
||||
|
||||

|
||||
|
||||
#### 并发场景可能存在的需求之——依赖上游的执行结果作为入参
|
||||
譬如A-B-C三个执行单元,A的入参是String,出参是int,B呢它需要用A的结果作为自己的入参。也就是说A、B并不是独立的,而是有结果依赖关系的。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user