一种网络异构环境下容错系统架构的制作方法

1.本发明涉及数据存储管理技术领域，具体为一种网络异构环境下容错系统架构。


背景技术：

2.通过基础设施与上层应用程序的协同来有效地利用硬件资源随着云计算的发展及推广,众多涉及海量数据处理的应用蓬勃涌现,如网络搜索、电子地图、生物医学、流体力学等这些应用每天都会产生海量数据,要对其进行处理，就需要海量存储空间，由于资源节点的动态性和异构性，创建多个数据副本进行容错和负载均衡副本技术是一种数据管理机制，将数据项复制多份分别放在分布式文件系统的多个节点上,用以提高系统的可靠性和访问效率.副本管理主要包括副本创建副本放置和副本调整副本管理策略分为静态副本策略和动态副本策略静态副本策略基于已知的访问方式，在文件创建时确定副本的数目及放置位置,适用于资源环境稳定的情况动态副本策略根据资源环境的变化而动态调整副本数目和位置，以适应不稳定的资源环境，现有采用静态副本管理机制,在文件分块时自动创建固定数目的副本，副本放置时未考虑资源节点异构性，导致节点负载不均，节点间数据传输量大，因此需要一种网络异构环境下容错系统架构。


技术实现要素：

3.本发明的目的在于提供一种网络异构环境下容错系统架构，以解决上述背景技术中提出的问题。
4.为实现上述目的，本发明提供如下技术方案：
5.一种网络异构环境下容错系统架构，所述容错分为服务宕机容错和任务重试，服务宕机容错又分为master容错和worker容错两种情况，所述master容错的一个进程是master节点，就在一台机器上，负责统一管控分散在多台机器上的数据；另外一批进程叫做slave节点，每台机器上都有一个slave节点，负责管理那台机器上的数据，跟master节点进行通信。
6.作为本发明优选的方案，所述容错设计依赖于zookeeper的watcher机制。
7.作为本发明优选的方案，所述master监控其他master和worker的目录，如果监听到remove事件，则会根据具体的业务逻辑进行流程实例容错或者任务实例容错。
8.作为本发明优选的方案，所述zookeepermaster容错完成之后则重新由dolphinscheduler中scheduler线程调度，遍历dag找到”正在运行”和“提交成功”的任务，对”正在运行”的任务监控其任务实例的状态，对”提交成功”的任务需要判断task queue中是否已经存在，如果存在则同样监控任务实例的状态，如果不存在则重新提交任务实例。
9.作为本发明优选的方案，所述master scheduler线程一旦发现任务实例为“需要容错”状态，则接管任务并进行重新提交；由于“网络抖动”可能会使得节点短时间内失去和zookeeper的心跳，从而发生节点的remove事件；对于这种情况，我们使用最简单的方式，那就是节点一旦和zookeeper发生超时连接，则直接将master或worker服务停掉。
10.作为本发明优选的方案，所述master节点发现一段时间没收到某个slave节点发送过来的心跳，此时就会认为这个slave节点所在机器宕机了，那台机器上的数据副本都丢失了，然后master节点就不会告诉别人去读那个丢失的数据副本，master节点就可以通知去读副本1或者副本2。
11.作为本发明优选的方案，所述master节点一旦感知到某台机器宕机，就能感知到某个数据分片的副本数量不足了；此时，就会生成一个副本复制的任务，挑选另外一台机器来从有副本的机器去复制一个副本。
12.作为本发明优选的方案，所述master节点感知到机器复活，会发现副本数量过多，此时会生成一个删除副本任务，会在机器发送心跳的时候，下发一个删除副本的指令，让机器删除自己本地多余的副本。
13.作为本发明优选的方案，所述master容错和worker容错任务失败重试是任务级别的，是调度系统自动进行的，比如一个shell任务设置重试次数为3次，那么在shell任务运行失败后会自己再最多尝试运行3次，流程失败恢复是流程级别的，是手动进行的，恢复是从只能从失败的节点开始执行或从当前节点开始执行，流程失败重跑也是流程级别的，是手动进行的，重跑是从开始节点进行。
14.作为本发明优选的方案，所述master容错和worker容错任务节点分为两种类型，一种是业务节点，这种节点都对应一个实际的脚本或者处理语句；还有一种是逻辑节点，这种节点不做实际的脚本或语句处理，只是整个流程流转的逻辑处理；每一个业务节点都可以配置失败重试的次数，当该任务节点失败，会自动重试，直到成功或者超过配置的重试次数，逻辑节点不支持失败重试，但是逻辑节点里的任务支持重试。
15.与现有技术相比，本发明的有益效果是：
16.本发明中，通过提出异构环境数据副本动态管理模型在副本创建时，考虑资源节点性能及访问热度，选择最优副本放置节点；在系统运行过程中,worker的角色主要负责任务的执行工作并维护和master的心跳，以便master可以分配任务，数据分片存储、多副本冗余、宕机感知、自动副本迁移、多余副本删除，主要是避免了参与者在长时间无法与协调者节点通讯(协调者挂掉了)的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地从而进行释放资源，而这种机制也侧面降低了整个事务的阻塞时间和范围，能够有效减少节点之间数据传输，提高负载均衡，降低作业执行时间。
附图说明
17.图1为本发明的系统原理结构图；
18.图2为本发明的master容错流程图；
19.图3为本发明的worker容错流程图。
具体实施方式
20.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例,基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
21.为了便于理解本发明，下面将参照相关附图对本发明进行更全面的描述,附图中给出了本发明的若干实施例,但是，本发明可以以许多不同的形式来实现，并不限于本文所描述的实施例，相反地，提供这些实施例的目的是使对本发明的公开内容更加透彻全面。
22.除非另有定义，本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在本发明的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本发明，本文所使用的术语“及/或”包括一个或多个相关的所列项目的任意的和所有的组合。
23.请参阅图1-3本发明提供一种技术方案：
24.一种网络异构环境下容错系统架构，所述容错分为服务宕机容错和任务重试，服务宕机容错又分为master容错和worker容错两种情况，所述master容错的一个进程是master节点，就在一台机器上，负责统一管控分散在多台机器上的数据；另外一批进程叫做slave节点，每台机器上都有一个slave节点，负责管理那台机器上的数据，跟master节点进行通信。
25.容错设计依赖于zookeeper的watcher机制。
26.master监控其他master和worker的目录，如果监听到remove事件，则会根据具体的业务逻辑进行流程实例容错或者任务实例容错。
27.zookeepermaster容错完成之后则重新由dolphinscheduler中scheduler线程调度，遍历dag找到”正在运行”和“提交成功”的任务，对”正在运行”的任务监控其任务实例的状态，对”提交成功”的任务需要判断task queue中是否已经存在，如果存在则同样监控任务实例的状态，如果不存在则重新提交任务实例。
28.master scheduler线程一旦发现任务实例为“需要容错”状态，则接管任务并进行重新提交；由于“网络抖动”可能会使得节点短时间内失去和zookeeper的心跳，从而发生节点的remove事件；对于这种情况，我们使用最简单的方式，那就是节点一旦和zookeeper发生超时连接，则直接将master或worker服务停掉。
29.master节点发现一段时间没收到某个slave节点发送过来的心跳，此时就会认为这个slave节点所在机器宕机了，那台机器上的数据副本都丢失了，然后master节点就不会告诉别人去读那个丢失的数据副本，master节点就可以通知去读副本1或者副本2。
30.master节点一旦感知到某台机器宕机，就能感知到某个数据分片的副本数量不足了；此时，就会生成一个副本复制的任务，挑选另外一台机器来从有副本的机器去复制一个副本。
31.master节点感知到机器复活，会发现副本数量过多，此时会生成一个删除副本任务，会在机器发送心跳的时候，下发一个删除副本的指令，让机器删除自己本地多余的副本。
32.master容错和worker容错任务失败重试是任务级别的，是调度系统自动进行的，比如一个shell任务设置重试次数为3次，那么在shell任务运行失败后会自己再最多尝试运行3次，流程失败恢复是流程级别的，是手动进行的，恢复是从只能从失败的节点开始执行或从当前节点开始执行，流程失败重跑也是流程级别的，是手动进行的，重跑是从开始节点进行。
33.master容错和worker容错任务节点分为两种类型，一种是业务节点，这种节点都
对应一个实际的脚本或者处理语句；还有一种是逻辑节点，这种节点不做实际的脚本或语句处理，只是整个流程流转的逻辑处理；每一个业务节点都可以配置失败重试的次数，当该任务节点失败，会自动重试，直到成功或者超过配置的重试次数，逻辑节点不支持失败重试，但是逻辑节点里的任务支持重试。
34.通过提出异构环境数据副本动态管理模型在副本创建时，考虑资源节点性能及访问热度，选择最优副本放置节点；在系统运行过程中,worker的角色主要负责任务的执行工作并维护和master的心跳，以便master可以分配任务，数据分片存储、多副本冗余、宕机感知、自动副本迁移、多余副本删除，主要是避免了参与者在长时间无法与协调者节点通讯(协调者挂掉了)的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地从而进行释放资源，而这种机制也侧面降低了整个事务的阻塞时间和范围，能够有效减少节点之间数据传输，提高负载均衡，降低作业执行时间。
35.实施例：容错分为服务宕机容错和任务重试，服务宕机容错又分为master容错和worker容错两种情况，所述master容错的一个进程是master节点，就在一台机器上，负责统一管控分散在多台机器上的数据；另外一批进程叫做slave节点，每台机器上都有一个slave节点，负责管理那台机器上的数据，跟master节点进行通信，分布式存储系统，当然就是负责把一个超大数据集拆分成多块，然后放到多台机器上来存储，接着统一管理这些分散在多台机器上存储的数据的一套系统；容错设计依赖于zookeeper的watcher机制；master监控其他master和worker的目录，如果监听到remove事件，则会根据具体的业务逻辑进行流程实例容错或者任务实例容错；zookeepermaster容错完成之后则重新由dolphinscheduler中scheduler线程调度，遍历dag找到”正在运行”和“提交成功”的任务，对”正在运行”的任务监控其任务实例的状态，对”提交成功”的任务需要判断task queue中是否已经存在，如果存在则同样监控任务实例的状态，如果不存在则重新提交任务实例；master scheduler线程一旦发现任务实例为“需要容错”状态，则接管任务并进行重新提交；由于“网络抖动”可能会使得节点短时间内失去和zookeeper的心跳，从而发生节点的remove事件；对于这种情况，我们使用最简单的方式，那就是节点一旦和zookeeper发生超时连接，则直接将master或worker服务停掉；master节点发现一段时间没收到某个slave节点发送过来的心跳，此时就会认为这个slave节点所在机器宕机了，那台机器上的数据副本都丢失了，然后master节点就不会告诉别人去读那个丢失的数据副本，master节点就可以通知去读副本1或者副本2，那么此时，master节点就可以通知人家去读数据的副本1或者副本2，哪个都行，因为那两个副本其实还是在的，举个例子，比如可以通知客户端去读副本1，此时客户端就可以找那台机器上的slave节点说要读取那个副本1；master节点一旦感知到某台机器宕机，就能感知到某个数据分片的副本数量不足了；此时，就会生成一个副本复制的任务，挑选另外一台机器来从有副本的机器去复制一个副本，可以挑选另外一台机器从第二台机器去复制一个副本，当另外一台机器发送心跳过去的时候，master节点就通过心跳响应把这个复制任务下发给另外一台机器，让另外一台机器从没有宕机的机器复制一个副本好了；master节点感知到机器复活，会发现副本数量过多，此时会生成一个删除副本任务，会在机器发送心跳的时候，下发一个删除副本的指令，让机器删除自己本地多余的副本，会在机器3发送心跳的时候，下发一个删除副本的指令，让机器3删除自己本地多余的副本就可以了。这样，就可以保持副本数量只有3个；master容错和worker容错任务失败重试
是任务级别的，是调度系统自动进行的，比如一个shell任务设置重试次数为3次，那么在shell任务运行失败后会自己再最多尝试运行3次，流程失败恢复是流程级别的，是手动进行的，恢复是从只能从失败的节点开始执行或从当前节点开始执行，流程失败重跑也是流程级别的，是手动进行的，重跑是从开始节点进行；master容错和worker容错任务节点分为两种类型，一种是业务节点，这种节点都对应一个实际的脚本或者处理语句；还有一种是逻辑节点，这种节点不做实际的脚本或语句处理，只是整个流程流转的逻辑处理；每一个业务节点都可以配置失败重试的次数，当该任务节点失败，会自动重试，直到成功或者超过配置的重试次数，逻辑节点不支持失败重试，但是逻辑节点里的任务支持重试；按照不同流程实例优先级优先于同一个流程实例优先级优先于同一流程内任务优先级优先于同一流程内任务提交顺序依次从高到低进行任务处理。具体实现是根据任务实例的json解析优先级，然后把流程实例优先级_流程实例id_任务优先级_任务id信息保存在zookeeper任务队列中，当从任务队列获取的时候，通过字符串比较即可得出最需要优先执行的任务其中流程定义的优先级是考虑到有些流程需要先于其他流程进行处理，这个可以在流程启动或者定时启动时配置，共有5级，依次为highest、high、medium、low、lowest；由于web(ui)和worker不一定在同一台机器上，所以查看日志不能像查询本地文件那样。有两种方案：将日志放到es搜索引擎上，通过grpc通信获取远程日志信息，介于考虑到尽可能的dolphinscheduler的轻量级性，所以选择了grpc实现远程访问日志信息；通过提出异构环境数据副本动态管理模型在副本创建时，考虑资源节点性能及访问热度，选择最优副本放置节点；在系统运行过程中,worker的角色主要负责任务的执行工作并维护和master的心跳，以便master可以分配任务，数据分片存储、多副本冗余、宕机感知、自动副本迁移、多余副本删除，主要是避免了参与者在长时间无法与协调者节点通讯(协调者挂掉了)的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地从而进行释放资源，而这种机制也侧面降低了整个事务的阻塞时间和范围，能够有效减少节点之间数据传输，提高负载均衡，降低作业执行时间。
36.尽管已经示出和描述了本发明的实施例，对于本领域的普通技术人员而言，可以理解在不脱离本发明的原理和精神的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由所附权利要求及其等同物限定。