多线程DAG调度
没有找妹子排版，这效果差距是有点大！
git地址：https://github.com/a925907195/dag-flow-platform
第1章 基础介绍
1.1简介
1.2 什么是DAG
1.3 Hystrix
第2章 DAG-FLOW介绍
2.1基础模块介绍
2.2基础流程介绍
- 基础介绍
- 简介
DAG即Directed Acyclic Graph,有向无环图的意思，DAG调度的目的就是把一个作业分成不同阶段，根据依赖构建一张DAG，并进入到阶段内部，把阶段划分为可以并行计算的任务，最后再把一个阶段内的所有任务交付给任务调度器来收尾。
-
- 什么是DAG
DAG，中文名"有向无环图"。"有向"指的是有方向，准确的说应该是同一个方向，"无环"则指够不成闭环。在DAG中，没有区块的概念，他的组成单元是一笔笔的交易，每个单元记录的是单个用户的交易，这样就省去了打包出块的时间。验证手段则依赖于后一笔交易对前一笔交易的验证，换句话说，你要想进行一笔交易，就必须要验证前面的交易，具体验证几个交易，根据不同的规则来进行。这种验证手段，使得DAG可以异步并发的写入很多交易，并最终构成一种拓扑的树状结构，能够极大地提高扩展性。
上面这张图是区块链，其中黑色的是最长链，也是全网的唯一主链。紫色的是分叉链，随着出块数量的增多，由于没有得到认可，最终被抛弃。
上图左右这两张图都是DAG。但他们是不一样的。左边这张图是IOTA的"缠结Tangle"，使用者每发起一笔交易，需要验证前面两笔交易，后面这张图是普通的DAG，对验证次数没有限制。
2：DAG与区块链相比的优缺点
区块链目前有什么问题呢，说白了就是一句话，在保证去中心化和安全性的前提下无法大幅度的提高扩展性，导致难以商业化运用。而DAG，理论状态下是去中心化的、如果网络足够强大，安全性也可以保证，更重要的是能够大幅度的提高扩展性，采用DAG技术的分布式数据库，起步就可以把TPS做到10万+，还能把交易费用做到极低。
既然DAG这么完美，是不是就可以完全替代区块链呢？当然不是，事实上，DAG也有自身的缺陷性。
1：交易时长不可控。DAG的验证规则是后面的交易验证前面的交易，这就很容易出现最后的交易迟迟无法被验证的情况，尤其是在整个网络发展的初期节点数量比较少的情况下，造成交易时长无法预测。当然，解决方法也是有的，但是不管是见证人还是其他超级节点机制，都在一定程度上违背了去中心化。
2：不支持强一致性。DAG作为一种谣言传播算法，其异步通讯机制在提高了扩展性的同时也带来了一致性的不可控问题。区块链是同步操作的验证机制，能够保证较高的一致性。但是DAG作为异步操作，它不存在一个全局的排序机制，在运行智能合约时，这就很可能会出现节点间所存储的数据在运行一段时间以后出现偏差的情况。
3:安全性还没有得到大规模的验证。DAG技术并不新鲜，但是应用到去中心化账本领域确是近几年的事情。他没有像比特币那般经历过长达10年的安全验证。这是他目前大规模的部署DAPP的最大障碍。
DAG技术作为区块链的一个有益补充，其异步通讯机制在提高扩展性、缩短确认时间和降低支付费用方面优势明显，未来在去中心化技术领域将来也会有一席之地。但其安全性和一致性的问题也亟待解决。相信随着以后技术的发展，这些问题也会得到逐步改善。老马也比较看着这方面的发展。
-
- Hystrix
在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC）。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。
如下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。
Hystrix语义为“豪猪"，具有自我保护的能力。Hystrix的出现即为解决雪崩效应。
Hystrix的设计原则是什么？
资源隔离（线程池隔离和信号量隔离）机制：限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其它服务调用。
限流机制：限流机制主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。
熔断机制：当失败率达到阀值自动触发降级（如因网络故障、超时造成的失败率真高），熔断器触发的快速失败会进行快速恢复。
降级机制：超时降级、资源不足时（线程或信号量）降级、运行异常降级等，降级后可以配合降级接口返回托底数据。
缓存支持：提供了请求缓存、请求合并实现
通过近实时的统计/监控/报警功能，来提高故障发现的速度
通过近实时的属性和配置热修改功能，来提高故障处理和恢复的速度
Hystrix是如何实现它的目标的？
（1）通过HystrixCommand或者HystrixObservableCommand来封装对外部依赖的访问请求，这个访问请求一般会运行在独立的线程中，资源隔离
（2）对于超出我们设定阈值的服务调用，直接进行超时，不允许其耗费过长时间阻塞住。这个超时时间默认是99.5%的访问时间，但是一般我们可以自己设置一下
（3）为每一个依赖服务维护一个独立的线程池，或者是semaphore，当线程池已满时，直接拒绝对这个服务的调用
（4）对依赖服务的调用的成功次数，失败次数，拒绝次数，超时次数，进行统计
（5）如果对一个依赖服务的调用失败次数超过了一定的阈值，自动进行熔断，在一定时间内对该服务的调用直接降级，一段时间后再自动尝试恢复
（6）当一个服务调用出现失败，被拒绝，超时，短路等异常情况时，自动调用fallback降级机制
（7）对属性和配置的修改提供近实时的支持
- DAG-FLOW介绍
- 基础模块介绍
dag调度实现了线程以dag图的结构进行执行，其中主要包括两个部分：
- dag-draw:实现dag的画图功能，可以一目了然看到线程执行的顺序。
- dag-flow:配置线程以及执行的依赖关系，包括环路检测以及基础调度功能。
-
- 基础流程介绍
- 线程依赖dag注册。将多线程的依赖关系构造成dag图。
- 环路检测，检测dag图是否有环，如果有环则报错并打印出环路。
- 可以选择性打印出整个dag图，直观查看dag中线程依赖关系。
- 构造hystrixCommand并根据依赖关系封装执行依赖。
- 异步调度执行，等最后一个返回成功则执行完毕（或者超时）。
主要测试类在test下面，其中DataJobFlowTest实现了基础的线程依赖关系配置，环路检测，依赖关系图绘制以及执行结果展示功能。
下图是展示执行的线程流转关系：
