分布式任务协调方法、装置、设备和介质与流程

1.本发明涉及计算机技术领域，尤其是涉及分布式任务协调方法、装置、设备和介质。


背景技术：

2.针对分布式任务协调场景，现有方案中常采用分布式应用程序协调服务软件(zookeeper)的分布式通知协调系统。该系统在实现上一般强依赖于zookeeper的通知机制，而该机制可以很好地起到广播消息的作用。参见图1，当一个子流程以写入一个数据的方式发布一条消息后，如果其他流程模块对写入数据有观察(watch)行为的话，那么就会接收zookeeper下发的数据变更的通知，并且会执行一个提前定义好的回调(callback)函数来执行相关的逻辑。也即zookeeper通过一个抽象的观察接口(watcher application programming interface)来实现事件的下发和通知，并执行自定义的callback函数。
3.但是watcher这样的机制有如下的缺点：watcher机制是一次性的，zookeeper本身对消息是否被接收端获取并做了相应的动作不关心。这样就要求子流程在获取了一次事件通知后，再次的去watch相同的资源，从而才能实现一个永久的watch行为。也正因为这些缺点的存在，导致不能满足高吞吐分布式任务协调的实际需求。


技术实现要素：

4.基于此，有必要针对上述问题，提供分布式任务协调方法、装置、设备和介质，以解决不能满足高吞吐分布式任务协调的问题。
5.一种分布式任务协调方法，应用于包含多个设备节点的分布式数据库集群，所述方法包括：
6.每当集群管理组件获取到前端下发的分布式任务时，异步地对所述分布式任务进行内部初始化，及通过通知下发框架将初始化后的分布式任务下发至等待队列，以等待响应；其中，所述通知下发框架基于远程过程调用技术构建基础框架；
7.所述集群管理组件通过所述通知下发框架将所述等待队列中的分布式任务异步地下发至多个协程，并通过所述多个协程同步地获取连接的设备节点所反馈的应答，以响应所述分布式任务。
8.在其中一个实施例中，所述方法还包括：
9.将与所述分布式任务相关联的内部事件进行缓存。
10.在其中一个实施例中，所述方法还包括：
11.基于所述通知下发框架，通过域名解析协议或负载均衡的策略扩展所述设备节点。
12.在其中一个实施例中，所述异步地对所述分布式任务进行内部初始化之前，还包括：
13.同步地对所述分布式任务的逻辑进行合法性校验，基于校验结果向前端发送应
答。
14.在其中一个实施例中，所述方法还包括：
15.每当获取到传参请求时，生成对应的请求实体；
16.经过串行同步执行的准备阶段、同步等待应答的执行阶段及面向全局的收尾阶段，来执行所述请求实体。
17.在其中一个实施例中，所述方法还包括：
18.获取为每一个设备节点预先设定的通道，当基于单设备的远程过程调用技术实现远程任务时，添加与所述远程任务匹配的通道并执行，及初始化与所述远程任务相关的参数；
19.当基于多设备的远程过程调用技术实现远程任务时，多次添加与所述远程任务匹配的通道并执行，及初始化与所述远程任务相关的参数。
20.在其中一个实施例中，所述方法还包括：
21.通过编排请求实体的处理过程及远程任务的处理过程，以执行涉及到多个阶段，或涉及到多个节点设备同时执行相关指令的目标任务。
22.一种分布式任务协调装置，应用于包含多个设备节点的分布式数据库集群，所述装置包括：
23.等待响应模块，用于每当集群管理组件获取到前端下发的分布式任务时，异步地对所述分布式任务进行内部初始化，及通过通知下发框架将初始化后的分布式任务下发至等待队列，以等待响应；其中，所述通知下发框架基于远程过程调用技术构建基础框架；
24.任务协调模块，用于所述集群管理组件通过所述通知下发框架将所述等待队列中的分布式任务异步地下发至多个协程，并通过所述多个协程同步地获取连接的设备节点所反馈的应答，以响应所述分布式任务。
25.一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时，使得所述处理器执行上述分布式任务协调方法的步骤。
26.一种分布式任务协调设备，包括存储器和处理器，所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行上述分布式任务协调方法的步骤。
27.本发明提供了分布式任务协调方法、装置、设备和介质，该协调过程主要基于远程过程调用技术构建的通知下发框架，首先每当集群管理组件获取到前端下发的分布式任务时，异步地对分布式任务进行内部初始化，从而更好地兼容分布式任务，再通过通知下发框架将初始化后的分布式任务下发至等待队列，以等待响应。接着集群管理组件通过通知下发框架将等待队列中的分布式任务异步地下发至多个协程，这样就能及时对分布式任务进行下发，不会因为某一已分配的分布式任务当前正在长时间的执行就导致分布式数据库集群后续的服务阻塞。最后通过多个协程同步地获取连接的设备节点所反馈的应答，以响应分布式任务。这样就能避免单次握手的风险，远程过程调用技术采用“请求-应答”模式，该模式具有2次握手的通知协议，能够准确的感知下游服务是否能成功接收到相关信息并获取到应答反馈，从而满足高吞吐分布式任务协调的实际需求。
附图说明
28.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
29.其中：
30.图1为一个实施例中分布式任务协调方法的流程示意图；
31.图2为一个实施例中分布式任务协调方法的流程框图；
32.图3为一个实施例中分布式任务协调装置的结构示意图；
33.图4为一个实施例中分布式任务协调设备的结构框图。
具体实施方式
34.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
35.为方便阐述技术方案，下文的部门专有名词以英文及缩写形式表示，现对其进行解释：rpc：远程过程调用；dbms:分布式数据库管理系统；cluster：分布式数据库集群；clustermanager：集群管理组件；node：设备节点；nodemanager：node管理组件；postquery：传参请求；request实体：请求实体；channel：通道；remotetask：远程任务；http：超文本传输协议；coroutine：协程。
36.如图1所示，图1为一个实施例中分布式任务协调方法的流程示意图，应用于包含多个node的cluster。
37.dbms用于对数据库进行统一的管理和控制，原生具有多个物理设备协同工作的诉求，因此需要一个独立的组件对整个cluster进行管理。其核心任务包括但不限于：集群状态维护，分布式任务管理，多节点协同任务的下发与执行，集群状态的查询和展示等。
38.本实施例中，clustermanager作为dbms的集群管理组件，承担上述核心任务。clustermanager是独立的功能模块，可无状态的运行在集群内的任意物理设备上。
39.本实施例中分布式任务协调方法提供的步骤包括：
40.步骤102，每当集群管理组件获取到前端下发的分布式任务时，异步地对分布式任务进行内部初始化，及通过通知下发框架将初始化后的分布式任务下发至等待队列，以等待响应。
41.该阶段，任务的接收、任务的内部初始化及任务的下发是异步执行的，从而避免阻塞。
42.具体的，如图2所示，首先同步地对分布式任务的逻辑进行合法性校验，即requestcheck和get requestid，再基于校验结果向前端发送http应答。当校验结果为合法，这个应答用于向前端反馈当前已接收到分布式任务，且正在进行处理。反之，不进行处理。由于合法性校验的逻辑简单，因此即使采用同步等待也不会有长时间的阻塞。
43.本实施例中，通知下发框架基于rpc技术构建基础框架。rpc是指计算机a上的进
程，调用另外一台计算机b上的进程，其中a上的调用进程被挂起，而b上的被调用进程开始执行，当值返回给a时，a进程继续执行。调用方可以通过使用参数将信息传送给被调用方，而后可以通过传回的结果得到信息。而这一过程，对于开发人员来说是透明的。这样就能避免zookeeper单次握手的风险，rpc技术的“请求-应答”模式这样的2次握手的通知协议，能够准确的感知下游服务是否能成功接收到相关信息并获取到应答反馈，从而满足高吞吐分布式任务协调的实际需求。
44.接着，再异步地对分布式任务进行内部初始化，包括先创建一个外部类的对象，然后利用这个对象创建内部类对象。由于每个内部类都能独立地继承自一个(接口的)实现，所以无论外部类是否已经继承了某个(接口的)实现，对于内部类都没有影响，从而更好地兼容分布式任务。最后通过通知下发框架将初始化后的分布式任务下发至等待队列，以等待响应。
45.步骤104，集群管理组件通过通知下发框架将等待队列中的分布式任务异步地下发至多个协程，并通过多个协程同步地获取连接的设备节点所反馈的应答，以响应分布式任务。
46.本实施例中，如图2所示，clustermanager通过通知下发框架将等待队列中的分布式任务异步地下发至多个coroutine。其中，下发的coroutine是当前空闲的coroutine，coroutine完全由程序所控制，一个coroutine与一个node连接。通过这个多个coroutine可同步地获取连接的node所反馈的应答。该阶段，虽然单个nodemanager的rpc仍然是同步等调用，但是整体的处理流程是异步的，所以整个http服务不会阻塞。
47.可见，clustermanager的任务处理是面向前后端的纯异步框架。这样实现的目的是为了能够保证clustermanager能够持续的对外提供集群管理服务，不会因为某一已分配的分布式任务当前正在长时间的执行就导致cluster后续的服务阻塞。
48.进一步的，考虑到zookeeper的通知机制中，被watch的节点的数据，如果短时间内被频繁更新，那么基于背景技术中所提及的缺点，理论上还会出现消息的丢失，即watch事件的丢失。
49.针对这种问题，在一个具体实施例中，还将与分布式任务相关联的内部事件进行缓存。例如内存事件在被分发前，一定会在内部缓存。这样既保证了事件不会丢失，又保证了高吞吐。
50.进一步的，还考虑到zookeeper的通知机制中，zookeeper服务是一主多备的拓扑结构，能够承载的watcher数量有限，有潜在的性能瓶颈风险，横向扩展能力有限。
51.针对这种问题，在一个具体实施例中，还基于通知下发框架，通过域名解析协议或负载均衡的策略横向扩展node，并形成统一的对外服务的能力，这样就消除了潜在的性能瓶颈的风险。
52.上述分布式任务协调方法，主要基于远程过程调用技术构建的通知下发框架，首先每当集群管理组件获取到前端下发的分布式任务时，异步地对分布式任务进行内部初始化，从而更好地兼容分布式任务，再通过通知下发框架将初始化后的分布式任务下发至等待队列，以等待响应。接着集群管理组件通过通知下发框架将等待队列中的分布式任务异步地下发至多个协程，这样就能及时对分布式任务进行下发，不会因为某一已分配的分布式任务当前正在长时间的执行就导致分布式数据库集群后续的服务阻塞。最后通过多个协
程同步地获取连接的设备节点所反馈的应答，以响应分布式任务。这样就能避免单次握手的风险，远程过程调用技术采用“请求-应答”模式，该模式具有2次握手的通知协议，能够准确的感知下游服务是否能成功接收到相关信息并获取到应答反馈，从而满足高吞吐分布式任务协调的实际需求。
53.下面结合不同具体应用场景对分布式任务协调方法进行说明：
54.第一类应用场景，request-api远程业务处理的抽象：
55.每当clustermanager获取到postquery时，都会在clustermanager中生成一个request实体。其中，该实体用于承担执行子任务，持久化信息等功能。
56.对一个request实体来说，处理这个request的流程是固定的，共包含三个阶段：准备阶段setup()、执行阶段dealrequest()及收尾阶段teardown()。
57.进行内部初始化时，对于不同的分布式任务，均需要继承clusterrequest类，并且填充setupimpl/dealrequest/teardownimpl方法，这些自定的逻辑会在任务执行流程中被调用。
58.1.准备阶段setup()
59.setup需要轻量，因此该阶段是串行单线程执行的。这样做的目的，还是为了方便处理如，排他性任务的需求。例如需要执行一个全局只能唯一存在并执行的任务，就可以将这个任务逻辑上提到setup阶段。
60.2.执行阶段dealrequest()
61.该阶段执行主要任务逻辑,会在coroutine中展开，但是该阶段不会异步的等rpc应答，仍然采用同步的方式。因为该阶段的同步等会影响主逻辑，为了简化编程难度，采用同步即可。
62.3.收尾阶段teardown()
63.该阶段做全局的收尾工作，比如通知计算节点，更新元数据集群等。该阶段同样会在coroutine中展开。
64.第二类应用场景，remotetask-apiremotetask的抽象：
65.1.单设备rpc
66.每一个node在clustermanager中都会被一个channel代表，该对象可以理解为一个远程超文本传输服务(httpserver)的封装，因此当基于单设备的rpc技术实现remotetask时，需要的准备工作包括：需要选择与remotetask匹配的channel并执行allsubchannelsuccess(),然后初始化任务相关的参数即可。
67.2.多设备rpc
68.有些场景需要在多个机器上同时执行命令，并等待所有的设备成功或者任意一个设备有失败，此时就报错终止。这里对应到remotetask实例化的操作上，当基于多设备的rpc技术实现remotetask时，需要的准备工作包括：多次添加与remotetask匹配的channel并执行allsubchannelsuccess(),然后初始化任务相关的参数即可。如果有不同机器执行任务的参数不同的情况，可以用tag加以区分。
69.第三类应用场景，missionrequest对象-复杂任务编排与执行：
70.一个复杂的目标任务，可能涉及到多个阶段，或涉及到多个节点设备同时执行。因此需要一个能够实现复杂remotetask编排的功能。
71.missionrequest继承自clusterrequest,并且组合了remotetask的功能，通过编排请求实体的处理过程及remotetask的处理过程，来实现复杂的目标任务。
72.例如在扩容场景中，只需要实现一个expand类，该类继承自missionrequest，然后对setupmission()/dealrequest()/teardownimpl()/arrangeremotetask()进行实现，即可将整个扩容任务流程统一到现有的任务框架中。
73.其中，arrangeremotetask()需要实现的逻辑就是，按需逐个实例化remotetask然后放入队列中即可。实际执行的时候，会逐个从队列中取出执行。
74.可见，针对上述应用场景，本技术提供了一个统一的抽象接口。基于该抽象接口实现的分布式任务协调框架，屏蔽了多物理设备复杂多次rpc交互的具体逻辑，使得跨物理设备的分布式管理任务在实现上，只需要实现业务逻辑，无需关注复杂的多设备交互逻辑。该统一的抽象模型为整个集群提供了稳定，可控，可观测的子任务协调机制，同时良好的封装使得任务管理逻辑与任务实现逻辑实现了良好的分离，为系统的良性扩展提供了基础。
75.在一个实施例中，如图3所示，提出了一种分布式任务协调装置，该装置包括：
76.等待响应模块302，用于每当集群管理组件获取到前端下发的分布式任务时，异步地对分布式任务进行内部初始化，及通过通知下发框架将初始化后的分布式任务下发至等待队列，以等待响应；其中，通知下发框架基于远程过程调用技术构建基础框架；
77.任务协调模块304，用于集群管理组件通过通知下发框架将等待队列中的分布式任务异步地下发至多个协程，并通过多个协程同步地获取连接的设备节点所反馈的应答，以响应分布式任务。
78.图4示出了一个实施例中分布式任务协调设备的内部结构图。如图4所示，该分布式任务协调设备包括通过系统总线连接的处理器、存储器和网络接口。其中，存储器包括非易失性存储介质和内存储器。该分布式任务协调设备的非易失性存储介质存储有操作系统，还可存储有计算机程序，该计算机程序被处理器执行时，可使得处理器实现分布式任务协调方法。该内存储器中也可储存有计算机程序，该计算机程序被处理器执行时，可使得处理器执行分布式任务协调方法。本领域技术人员可以理解，图4中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的分布式任务协调设备的限定，具体的分布式任务协调设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
79.一种分布式任务协调设备，包括存储器、处理器以及存储在该存储器中并可在该处理器上执行的计算机程序，该处理器执行该计算机程序时实现如下步骤：每当集群管理组件获取到前端下发的分布式任务时，异步地对分布式任务进行内部初始化，及通过通知下发框架将初始化后的分布式任务下发至等待队列，以等待响应；集群管理组件通过通知下发框架将等待队列中的分布式任务异步地下发至多个协程，并通过多个协程同步地获取连接的设备节点所反馈的应答，以响应分布式任务。
80.一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被处理器执行时实现如下步骤：每当集群管理组件获取到前端下发的分布式任务时，异步地对分布式任务进行内部初始化，及通过通知下发框架将初始化后的分布式任务下发至等待队列，以等待响应；集群管理组件通过通知下发框架将等待队列中的分布式任务异步地下发至多个协程，并通过多个协程同步地获取连接的设备节点所反馈的应答，以响应
分布式任务。
81.需要说明的是，上述分布式任务协调方法、装置、设备及计算机可读存储介质属于一个总的发明构思，分布式任务协调方法、装置、设备及计算机可读存储介质实施例中的内容可相互适用。
82.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该程序可存储于一非易失性计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(rom)、可编程rom(prom)、电可编程rom(eprom)、电可擦除可编程rom(eeprom)或闪存。易失性存储器可包括随机存取存储器(ram)或者外部高速缓冲存储器。作为说明而非局限，ram以多种形式可得，诸如静态ram(sram)、动态ram(dram)、同步dram(sdram)、双数据率sdram(ddrsdram)、增强型sdram(esdram)、同步链路(synchlink)dram(sldram)、存储器总线(rambus)直接ram(rdram)、直接存储器总线动态ram(drdram)、以及存储器总线动态ram(rdram)等。
83.以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
84.以上实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本技术专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术专利的保护范围应以所附权利要求为准。