|
锁定老帖子 主题：(业务层)异步并行加载技术分析和设计
精华帖 (9) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (2)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-02-23
royaki 写道 比如有10个线程请求数据，原本情况是10个线程分别进行处理，分担压力。
使用LZ这种方式以后10个线程的压力会变小，但是executor就要处理大量的请求数据，这样来看总体的耗时反而有可能增加。 而且，并没有看到比ajax明显改善的地方。 不知道是不是我理解的不对..... 理解有点偏差，原本的一个work线程，起了n个线程并行加载后，因为由线程调度，所有线程的总的耗时是会有增加的。 但这总的耗时是n个线程的时间之和，一个请求总的处理时间确是这max(单个Thread的响应时间)，一个页面请求的响应时间就会减小，客户体验就好。 就是以cpu的运算的代价，提升系统的单次请求的响应时间 |
| 返回顶楼 | |
|
发表时间：2011-02-23
yashironan 写道 如果没理解错的话，可切分的多个子task,分别定义成FutureTask由Executor去执行，要求子task之间依赖性较低。用在合适的场景，确实效果不错
task越离散，多快数据之间没有依赖关系，也越接近于ajax可以实施的范围。 目前是支持依赖关系的处理，如果子task返回的对象model，存在一定的依赖关系，也只影响整个依赖的这一条链表的请求，其他不相关的同样是能走异步并行加载。 可以说业务越复杂，外部接口调用越多，提升的空间就越大 |
| 返回顶楼 | |
|
发表时间：2011-02-23
ModelA modelA = serviceA.getModel(); ModelB modelB = serviceB.getModel(modelA.getResult()); ModelC modelC = serviceC.getModel(modelB.getResult()); 这种情况？？？？ |
| 返回顶楼 | |
|
发表时间：2011-02-23
最后修改：2011-02-23
opal 写道 ModelA modelA = serviceA.getModel(); ModelB modelB = serviceB.getModel(modelA.getResult()); ModelC modelC = serviceC.getModel(modelB.getResult()); 这种情况？？？？ 针对这种情况，就回归到最原始的串行请求了，因为所有的服务处于一条的依赖关系链中。 总的请求的响应时间等于依赖关系链的所有服务请求之后。 新的例子： ModelA modelA = serviceA.getModel(); ModelD modelD = serviceD.getModel(); //加入多这么一次请求 ModelB modelB = serviceB.getModel(modelA.getResult()); ModelC modelC = serviceC.getModel(modelB.getResult()); 加入多了一次modelD的请求，这个请求的响应时间就可以被“挤“出来了，最后总的响应时间就=max(serviceD , serviceA+serviceB+serviceC); 因为我们的代码开发，存在很多的情况就是调用服务取到了结果，并不立即去使用，这样就有一定的提升空间了 |
| 返回顶楼 | |
|
发表时间：2011-02-23
页面的几个调用有业务上的先后顺序，通过并行处理的话可能会乱序，这个方面你怎么考虑的
|
| 返回顶楼 | |
|
发表时间：2011-02-23
我做过类似的一个实现，是做接口服务调用，
主要是用jdk并发包中的BlockingQueue和Future机制， 基本是按生产者-消费者模型，有一个线程会执行定时任务，检测Future是否拿到结果，和你的modelA.isOk())作用应该类似。 |
| 返回顶楼 | |
|
发表时间：2011-02-23
大任务包含分支任务分解，可以参考下fork/join并行分解模型
|
| 返回顶楼 | |
|
发表时间：2011-02-23
donglee 写道 我做过类似的一个实现，是做接口服务调用，
主要是用jdk并发包中的BlockingQueue和Future机制， 基本是按生产者-消费者模型，有一个线程会执行定时任务，检测Future是否拿到结果，和你的modelA.isOk())作用应该类似。 理念上貌似有所不同吧，isOk()这是我随意写的一个内容。整套机制目前是无嵌入性，不需要应用代码实现任何接口或者啥的。 不存在一个定时任务去检查。 而是在你的model想要进行一个getXXX()方法调用时，再去检查future的结果(已拿到就直接返回，没拿到就阻塞)， 所以这时的检查是一个lazy的过程。 |
| 返回顶楼 | |
|
发表时间：2011-02-23
tutu1982 写道 页面的几个调用有业务上的先后顺序，通过并行处理的话可能会乱序，这个方面你怎么考虑的
主文档中，已经有提到。 ============================= 引入的问题： 但同样，引入并行加载的设计后，需要考虑的一个点就是如果A和B的数据之间是有一定的依赖关系时怎么处理。 例子 Java代码 if(modelA.isOk()){//先依赖modelA的请求 modelB.getXXX() } 一种解决方案： 半自动化处理。 任何异步并行加载的时机点，全都取决于代码编写的顺序。 如果有依赖关系的存在，比如例子中的B依赖A的结果，则B会阻塞等待至A的结果返回。 A和B的处理就又回归到一个有顺序序的请求处理 |
| 返回顶楼 | |
|
发表时间：2011-02-23
嗯，半自动确实能解决，但这样就给业务开发人员带来了一定的负担，我一直在思考能否对业务开发人员做到全透明
|
| 返回顶楼 | |
