mirror of
https://gitee.com/jd-platform-opensource/asyncTool.git
synced 2024-12-19 03:30:30 +08:00
update README.md.
This commit is contained in:
parent
47b0efe1a4
commit
d8dca15d2a
18
README.md
18
README.md
@ -7,7 +7,7 @@
|
||||
|
||||
如果只是需要用这个框架,请往下看即可。如果需要深入了解这个框架是如何一步一步实现的,从接到需求,到每一步的思考,每个类为什么这么设计,为什么有这些方法,也就是如何从0到1开发出这个框架,作者在[csdn开了专栏](https://blog.csdn.net/tianyaleixiaowu/category_9637010.html)专门讲中间件如何从0开发,包括并不限于这个小框架。京东内部同事可在cf上搜索erp也能看到。
|
||||
|
||||
#### 并行常见的场景
|
||||
## 并行常见的场景
|
||||
1 客户端请求服务端接口,该接口需要调用其他N个微服务的接口
|
||||
|
||||
`譬如 请求我的订单,那么就需要去调用用户的rpc、商品详情的rpc、库存rpc、优惠券等等好多个服务。同时,这些服务还有相互依赖关系,譬如必须先拿到用户的某个字段后,再去某rpc服务请求数据。 最终全部获取完毕后,或超时了,就汇总结果,返回给客户端。`
|
||||
@ -28,7 +28,7 @@
|
||||
|
||||
5 其他有顺序编排的需求
|
||||
|
||||
#### 并行场景之核心——任意编排
|
||||
## 并行场景之核心——任意编排
|
||||
1 多个执行单元的串行请求
|
||||
|
||||
![输入图片说明](https://images.gitee.com/uploads/images/2019/1226/092905_55771221_303698.png "屏幕截图.png")
|
||||
@ -53,14 +53,14 @@
|
||||
|
||||
![输入图片说明](https://images.gitee.com/uploads/images/2019/1226/093023_357a2912_303698.png "屏幕截图.png")
|
||||
|
||||
#### 并行场景可能存在的需求之——每个执行结果的回调
|
||||
## 并行场景可能存在的需求之——每个执行结果的回调
|
||||
传统的Future、CompleteableFuture一定程度上可以完成任务编排,并可以把结果传递到下一个任务。如CompletableFuture有then方法,但是却无法做到对每一个执行单元的回调。譬如A执行完毕成功了,后面是B,我希望A在执行完后就有个回调结果,方便我监控当前的执行状况,或者打个日志什么的。失败了,我也可以记录个异常信息什么的。
|
||||
|
||||
此时,CompleteableFuture就无能为力了。
|
||||
|
||||
我的框架提供了这样的回调功能。并且,如果执行异常、超时,可以在定义这个执行单元时就设定默认值。
|
||||
|
||||
#### 并行场景可能存在的需求之——执行顺序的强依赖和弱依赖
|
||||
## 并行场景可能存在的需求之——执行顺序的强依赖和弱依赖
|
||||
如上图的3,A和B并发执行,最后是C。
|
||||
|
||||
有些场景下,我们希望A和B都执行完毕后,才能执行C,CompletableFuture里有个allOf(futures...).then()方法可以做到。
|
||||
@ -77,22 +77,22 @@
|
||||
|
||||
![输入图片说明](https://images.gitee.com/uploads/images/2020/0217/183223_de7e3fa7_303698.png "屏幕截图.png")
|
||||
|
||||
#### 并发场景可能存在的需求之——依赖上游的执行结果作为入参
|
||||
## 并发场景可能存在的需求之——依赖上游的执行结果作为入参
|
||||
譬如A-B-C三个执行单元,A的入参是String,出参是int,B呢它需要用A的结果作为自己的入参。也就是说A、B并不是独立的,而是有结果依赖关系的。
|
||||
|
||||
在A执行完毕之前,B是取不到结果的,只是知道A的结果类型。
|
||||
|
||||
那么,我的框架也支持这样的场景。可以在编排时,就取A的结果包装类,作为B的入参。虽然此时尚未执行,必然是空,但可以保证A执行完毕后,B的入参会被赋值。
|
||||
|
||||
#### 并发场景可能存在的需求之——全组任务的超时
|
||||
## 并发场景可能存在的需求之——全组任务的超时
|
||||
一组任务,虽然内部的各个执行单元的时间不可控,但是我可以控制全组的执行时间不超过某个值。通过设置timeOut,来控制全组的执行阈值。
|
||||
|
||||
#### 并发场景可能存在的需求之——高性能、低线程数
|
||||
## 并发场景可能存在的需求之——高性能、低线程数
|
||||
该框架全程无锁,没有一个加锁的地方。
|
||||
|
||||
创建线程量少。![输入图片说明](https://images.gitee.com/uploads/images/2019/1226/093227_9633e2a8_303698.png "屏幕截图.png")
|
||||
如这样的,A会运行在B、C执行更慢的那个单元的线程上,而不会额外创建线程。
|
||||
#### asyncTool特点
|
||||
## asyncTool特点
|
||||
解决任意的多线程并行、串行、阻塞、依赖、回调的并发框架,可以任意组合各线程的执行顺序,带全链路回调和超时控制。
|
||||
|
||||
其中的A、B、C分别是一个最小执行单元(worker),可以是一段耗时代码、一次Rpc调用等,不局限于你做什么。
|
||||
@ -107,7 +107,7 @@
|
||||
|
||||
**该框架全程无锁。**
|
||||
|
||||
### 快速开始
|
||||
## 快速开始
|
||||
[点此开启实战](https://gitee.com/tianyalei/asyncTool/blob/master/QuickStart.md)
|
||||
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user