asyncTool解决任意的多线程并行、串行、阻塞、依赖、回调的框架

该框架目前正在 京东 App 后台 接受苛刻、高并发、海量用户等复杂场景业务的检验测试,随时会根据实际情况发布更新和 bugFix。

有对区块链感兴趣的,可以参考项目作者另一个 GVP 项目,java 区块链底层入门。

如果只是需要用这个框架,请往下看即可。如果需要深入了解这个框架是如何一步一步实现的,从接到需求,到每一步的思考,每个类为什么这么设计,为什么有这些方法,也就是如何从 0 到 1 开发出这个框架,作者在 csdn 开了专栏专门讲中间件如何从 0 开发,包括并不限于这个小框架。京东内部同事可在 cf 上搜索 erp 也能看到。

并行常见的场景

1 客户端请求服务端接口,该接口需要调用其他 N 个微服务的接口

譬如 请求我的订单,那么就需要去调用用户的 rpc、商品详情的 rpc、库存 rpc、优惠券等等好多个服务。同时,这些服务还有相互依赖关系,譬如必须先拿到用户的某个字段后,再去某 rpc 服务请求数据。最终全部获取完毕后,或超时了,就汇总结果,返回给客户端。

2 并行执行 N 个任务,后续根据这 1-N 个任务的执行结果来决定是否继续执行下一个任务

如用户可以通过邮箱、手机号、用户名登录,登录接口只有一个,那么当用户发起登录请求后,我们需要并行根据邮箱、手机号、用户名来同时查数据库,只要有一个成功了,都算成功,就可以继续执行下一步。而不是先试邮箱能否成功、再试手机号……

再如某接口限制了每个批次的传参数量,每次最多查询 10 个商品的信息,我有 45 个商品需要查询,就可以分 5 堆并行去查询,后续就是统计这 5 堆的查询结果。就看你是否强制要求全部查成功,还是不管有几堆查成功都给客户做返回

再如某个接口,有 5 个前置任务需要处理。其中有 3 个是必须要执行完毕才能执行后续的,另外 2 个是非强制的,只要这 3 个执行完就可以进行下一步,到时另外 2 个如果成功了就有值,如果还没执行完,就是默认值。

3 需要进行线程隔离的多批次任务

如多组任务, 各组任务之间彼此不相关,每组都需要一个独立的线程池,每组都是独立的一套执行单元的组合。有点类似于 hystrix 的线程池隔离策略。

4 单机工作流任务编排

5 其他有顺序编排的需求

并行场景之核心任意编排

1 多个执行单元的串行请求

 

2 多个执行单元的并行请求

 

3 阻塞等待,串行的后面跟多个并行

 

4 阻塞等待,多个并行的执行完毕后才执行某个

 

5 串并行相互依赖

 

6 复杂场景

并行场景之每个执行结果的回调

传统的 Future、CompleteableFuture 一定程度上可以完成任务编排,并可以把结果传递到下一个任务。如 CompletableFuture 有 then 方法,但是却无法做到对每一个执行单元的回调。譬如 A 执行完毕成功了,后面是 B,我希望 A 在执行完后就有个回调结果,方便我监控当前的执行状况,或者打个日志什么的。失败了,我也可以记录个异常信息什么的。

此时,CompleteableFuture 就无能为力了。

我的框架提供了这样的回调功能。并且,如果执行异常、超时,可以在定义这个执行单元时就设定默认值。

并行场景之执行顺序的强依赖和弱依赖

如上图的 3,A 和 B 并发执行,最后是 C。

有些场景下,我们希望 A 和 B 都执行完毕后,才能执行 C,CompletableFuture 里有个 allOf(futures...).then()方法可以做到。

有些场景下,我们希望 A 或者 B 任何一个执行完毕,就执行 C,CompletableFuture 里有个 anyOf(futures...).then()方法可以做到。

我的框架同样提供了类似的功能,通过设定 wrapper 里的 addDepend 依赖时,可以指定依赖的任务是否 must 执行完毕。如果依赖的是 must 要执行的,那么就一定会等待所有的 must 依赖项全执行完毕,才执行自己。

如果依赖的都不是 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 并不是独立的,而是有结果依赖关系的。

在 A 执行完毕之前,B 是取不到结果的,只是知道 A 的结果类型。

那么,我的框架也支持这样的场景。可以在编排时,就取 A 的结果包装类,作为 B 的入参。虽然此时尚未执行,必然是空,但可以保证 A 执行完毕后,B 的入参会被赋值。

并发场景之全组任务的超时

一组任务,虽然内部的各个执行单元的时间不可控,但是我可以控制全组的执行时间不超过某个值。通过设置 timeOut,来控制全组的执行阈值。

并发场景之高性能、低线程数

该框架全程无锁,没有一个加锁的地方。

创建线程量少。

asyncTool 解决任意的多线程并行、串行、阻塞、依赖、回调的框架 如这样的,A 会运行在 B、C 执行更慢的那个单元的线程上,而不会额外创建线程。

asyncTool 特点

解决任意的多线程并行、串行、阻塞、依赖、回调的并发框架,可以任意组合各线程的执行顺序,带全链路回调和超时控制。

其中的 A、B、C 分别是一个最小执行单元(worker),可以是一段耗时代码、一次 Rpc 调用等,不局限于你做什么。

该框架可以将这些 worker,按照你想要的各种执行顺序,加以组合编排。最终得到结果。

并且,该框架 为每一个 worker 都提供了执行结果的回调和执行失败后自定义默认值 。譬如 A 执行完毕后,A 的监听器会收到回调,带着 A 的执行结果(成功、超时、异常)。

根据你的需求,将各个执行单元组合完毕后,开始在主线程执行并阻塞,直到最后一个执行完毕。并且 可以设置全组的超时时间 。

该框架支持后面的执行单元以前面的执行单元的结果为自己的入参 。譬如你的执行单元 B 的入参是 ResultA,ResultA 就是 A 的执行结果,那也可以支持。在编排时,就可以预先设定 B 或 C 的入参为 A 的 result,即便此时 A 尚未开始执行。当 A 执行完毕后,自然会把结果传递到 B 的入参去。

文章来自:猿天地

发布了313 篇原创文章 · 获赞 68 · 访问量 39万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览