流处理任务调度方法和分布式流处理系统与流程

1.本技术涉及计算机技术领域，尤其涉及一种流处理任务调度方法和分布式流处理系统。


背景技术：

2.流式数据是随着时间的推移而不断产生的一系列具有连续性的数据的集合，例如，随直播活动的进行而不断产生的音频和视频数据即直播流。流处理是流式数据生命周期中的重要一环，以直播流为例，其生命周期包括：直播流采集(摄像头、麦克风)
→
前处理(美颜、滤镜等)
→
编码(h264或h265等)
→
传输到网络，之后经过内容分发网络(content delivery network，cdn)
→
直播源站
→
流处理，最后用户通过cdn边缘网络回源到源站。直播流的流处理包括转推、转码、加水印、多源混流、从视频或图片文件推流、录制、监控等多种类型。
3.由于流处理任务体量大、实时性要求高，因此目前大都采用分布式系统进行流处理。分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的任务，其目的是利用更多的机器、处理更多的数据，而非用一台机器处理所有问题。
4.对流处理任务进行合理调度是分布式系统高效、成功完成流处理的关键。然而，目前的流处理任务调度方案存在很多不足，需要改进。


技术实现要素：

5.本技术实施例提供一种流处理任务调度方法和分布式流处理系统，以对流处理任务进行更合理的调度，从而避免相关技术中的流处理任务调度方案存在的至少一种不足。
6.第一方面，本技术实施例提供一种流处理任务调度方法，应用于分布式流处理系统，所述系统包括调度机和多个工作机，所述工作机中部署有至少一个工作者和所述至少一个工作者的代理，所述方法包括：
7.通过所述调度机接收待处理任务，并将所述待处理任务发送至目标工作机中的代理，其中，所述目标工作机是所述多个工作机中的一个；
8.通过所述目标工作机中的代理将所述待处理任务发送至所述目标工作机中处于在线状态的目标工作者；
9.通过所述目标工作者对所述待处理任务进行处理。
10.第二方面，本技术实施例还提供一种分布式流处理系统，包括：调度机和多个工作机，所述工作机中部署有至少一个工作者和所述至少一个工作者的代理；
11.所述调度机，用于接收待处理任务，并将所述待处理任务发送至目标工作机中的代理，其中，所述目标工作机是所述多个工作机中的一个；
12.所述目标工作机中的代理，用于将所述待处理任务发送至所述目标工作机中处于在线状态的目标工作者；
13.所述目标工作者，用于对所述待处理任务进行处理。
14.本技术实施例采用的上述至少一个技术方案，至少可以取得下述效果：由于采用包含调度机、工作者和工作者的代理三个角色的分布式流处理系统，由调度机统一接收和分发来自外部的待处理任务，由工作机中的代理接收来自调度机的任务，并由工作机中的代理将任务分配给处于在线状态的工作者，由工作机中处于在线状态的工作者对新接收的任务进行处理，因此，可以很好地对有状态的流处理任务进行处理而不中断。
附图说明
15.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
16.图1是本技术实施例提供的一种分布式流处理系统的架构示意图。
17.图2是本技术实施例提供的一种分布式流处理系统进行流处理任务调度的原理示意图。
18.图3a是本技术实施例提供的docker实验结果示意图之一。
19.图3b是本技术实施例提供的docker实验结果示意图之二。
20.图4是本技术实施例提供的一种分布式流处理系统的详细架构示意图。
21.图5a是本技术实施例提供的调用系统api获取工作机的cpu使用率的示意图。
22.图5b是本技术实施例提供的调用系统api获取工作机的内存使用率的示意图。
23.图6是本技术实施例提供的工作机可用度获取过程示意图。
24.图7是本技术实施例提供的调度机对分布式集群中的工作机的可用度从高到低排序的结果示意图。
25.图8是本技术实施例提供的故障转移机制的原理示意图。
26.图9是本技术实施例提供的一种流处理任务调度方法的流程示意图。
具体实施方式
27.为使本技术的目的、技术方案和优点更加清楚，下面将结合本技术具体实施例及相应的附图对本技术技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
28.本技术实施例提供的一种流处理任务调度方法和分布式流处理系统，可用于对流式数据的处理任务(简称流处理任务)进行调度，所述流处理任务包括但不限于有状态的任务，例如直播流处理任务。
29.下面，先对本技术实施例中涉及的术语进行解释。
30.有状态的任务是指非孤立的、有较长生命周期的任务。有状态的任务被中断时，需要将其上下文和历史记录存储下来，根据其上下文进行恢复。比如对某场直播的转码，一场直播的时长往往是持续很久的、且结束时间是不可预测的，有的观众想观看标清的清晰度就会触发转码，此时转码任务的生命周期应该和直播一致，直播不结束，转码就不应该停止。如果直播过程中转码异常中断了，则观看标清流的用户体验就是画面卡顿了，造成不好的体验。作为对比，无状态的任务往往是孤立的、耗时很短就能完成的，比如场景的请求
‑
>
响应式的http请求的处理。
31.直播流是直播过程产生的音频和视频数据，这种数据是随着直时间的推移而不断产生的，是一种流式数据。直播流的生命周期包括直播流采集(摄像头、麦克风)
→
前处理(美颜、滤镜等)
→
编码(h264或h265等)
→
传输到网络，之后经过内容分发网络(content delivery network，cdn)
→
直播源站
→
流处理，最后用户通过cdn边缘网络回源到直播源站。
32.源站的目的是处理和响应来自互联网上客户端传入的请求，其概念通常和cdn结合使用。在直播场景下，直播源站的主要作用就是接收主播发送的直播流，当观众播放时再通过cdn回源拉取直播流。
33.cdn，即內容分发网络(content delivery network)，分布在世界各地，用于解决用户和源站之间网络链路过长而导致网络不稳定的问题。cdn上缓存了从源站回源的直播流数据，用户可以从就近的cdn节点上直接从缓存拉流并播放，保证其播放的流畅度。
34.直播流的流处理包括转推、转码、加水印、多源混流、从视频或图片文件推流、录制、监控等多种类型。以转码为例，包括转清晰度、转h265编码等，为了保证各种播放器和网络条件下使直播流尽量的高清、无卡顿、减少cdn带宽成本等。
35.可用度计算是综合服务器的cpu使用率、gpu使用率(有的工作机没有gpu)、内存可用量、io使用量、磁盘用量、网卡可用带宽等综合计算完成。对直播流的处理，需要将直播流进行解协议
‑
>解封装
‑
>解码
‑
>处理
‑
>编码
‑
>封装
‑
>推流，在这个过程是相当耗费cpu或gpu资源的。此外，码率较高的流也会占用较多的带宽，程序运行时会占用内存，推拉流时会使用io。由于直播流的处理是有状态的任务、持续时间是不可预测的，因此一台工作机(一台服务器，是分布式集群中的一个节点)可以处理多少的任务，新增一个任务是否会导致工作机负载过高、进而导致所有处理任务出现延迟或卡顿的问题，各类任务对资源的消耗有多少，这些可通过可用度进行衡量。
36.相关技术中的流处理任务调度方案至少存在下述不足：
37.(1)常规的处理无状态任务的应用管理方式的缺点：常规的分布式流处理系统架构不考虑任务的状态，每个任务的处理是独立的且耗时较短，服务器中处理任务的应用的管理相对简单。当处理任务的应用下线时，将其设置为不接收新的任务，之后稍等几十秒即可完全关闭。但是，有状态的任务因为任务持续时长较长且结束时间不确定，当处理任务的应用需要更新时，不能直接下线旧处理应用，因为这样会导致旧应用中的正在进行的任务异常中断，造成直播卡顿或任务处理失败这种不好的体验。
38.(2)常规的处理有状态任务的应用管理方式的缺点：常规的处理有状态任务的应用管理，为了实现应用关闭时不对现有任务造成中断的目的，需要先将应用设置为下线状态，之后一直等待应用上所有任务都执行完毕后再将其关闭，之后才启动新的应用。这是因为提供服务的端口往往是固定的，如果新旧应用同时启动会产生端口冲突的问题，造成新应用启动失败。这种方案，应用更新部署时上线流程过长，耗时不确定且需要较高的人工参与度。
39.(3)常规的任务调度方式的缺点：常规的任务分发方式有轮询法、随机法、加权法随机法等，基本思想是为了尽量的平均和随机，达到负载均衡的目的。然而由于各种类型任务占用的资源不同、任务的持续时长不同、源流的码率和帧率不同、不同服务器的性能特点
也可能不同，使得常规的任务下发方式并不能很好地负载均衡的目的。例如，在极端情况下，很可能出现一台同时处理10个任务的服务器，比另一台在处理100个任务的服务器的负载更高。这使得有的服务器过载，影响任务的正常执行，例如造成直播的卡顿，而有的服务器的处理能力并没有得到很好的发挥，造成资源的浪费。
40.(4)常规的故障转移方案的缺点：当任务处理失败时，需要有故障转移机制使任务能被正确的处理。在常规的故障转移方案中，当某台服务器有问题时，对于无状态的任务可以通过简单重试来恢复，因为重试时任务可能被另一台服务器处理。而有状态的任务则比较复杂，要保障任务的全局唯一性，即确保在旧应用上删除了被转移的任务，且该任务在新机器上执行成功，同时任务转移时也需要检查服务器的可用度，而不能转移到另一台有问题的机器上，但常规方案并没有考量这一因素。
41.(5)常规的系统容量存在支撑不稳定的缺点：在直播场景下，每天开播的场次是随时间变化的，往往在每天18点～凌晨2点是晚高峰时间，在其他时间相对来讲同时开播的场次较少。同时开播的场次越多，意味着要处理的任务也就越多，消耗的系统资源越多，需要的服务器数量也就越多。如果日常保留能支撑晚高峰、甚至还有一定冗余度的机器数量，在低谷时则会存在资源浪费；如果常备台数较少，则又不足以支撑晚高峰的流量。当支持扩容后，常规的调度系统也无法保证新机器承载更多的流量，当缩容时，对有状态任务的下线管理能力也较差。
42.为了克服当前的流处理调度方案存在的上述至少一种不足，本技术实施例提供了一种流处理任务调度方法和分布式流处理系统，下面进行详细介绍。
43.下面先对本技术实施例提供的分布式流处理系统进行介绍。
44.如图1所示，本技术实施例提供的一种分布式流处理系统(可看作是一个分布式集群)，可包括调度机(dispatcher)和多个工作机(worker)，如工作机1、工作机2和工作机3等，其中，一个工作机中部署有至少一个工作者(runner)和所述至少一个工作者的代理(agent)，如工作机1、工作机2和工作机3中分别部署有工作者1、工作者2以及工作者1和工作者2代理。
45.需要说明的是，一个调度机和一个工作机可以分别是分布式流处理系统中的一台服务器(或一个计算节点)。
46.参考图1可知，本技术实施例提供的一种分布式流处理系统包括调度机、工作者和工作者的代理这3个核心角色。其中，工作者又称处理机，工作者是流处理任务的真正执行者，在单机上支持多实例部署，可实现新旧任务处理应用同时在线工作的目的，不同工作者启动时会使用一套全新的部署端口，因此不会出现端口冲突；代理负责代理工作者和维护工作者的生命周期，并将所在工作机的可用度和当前处理的任务状态等信息定时上报给调度机，对于流处理任务生命周期的变更，由调度机将变更命令发送给代理，由代理根据工作者的在线状态决定执行变更命令的目的任务处理应用；调度机是整个系统(或称集群)的调度者角色，它负责对外接收任务、收集工作机的可用度以及承担故障转移决策等。
47.图2示出了本技术实施例提供的一种流处理任务的调度方法的原理示意图。参考图2可知，在一种应场景下，流管理中心2会调用本技术实施例提供的分布式流处理系统1进行流处理。其中，流管理中心2可能包括任务创建模块21、变更/停止已有任务模块22、任务状态回调模块23和集群人物监控模块24等功能模块。分布式流处理系统1包括调度机11、多
个工作机12(图2中仅示出了一个)和资源13，其中，调度机11包括工作者版本管理模块111、任务管理模块112、工作机管理模块113和任务状态定时检查
‑
>重派模块114；工作机12包括工作者1、工作者2和代理121，代理121又包括工作者进程管理/监控模块1211、任务接收模块1212和注册&心跳发送模块1213等功能模块。
48.如图2所示，以直播流转码任务为例，流管理中心2与分布式流处理系统1中的一些模块的功能大致包括：
①
流管理中心2的任务创建模块21，用于在创建完直播流转码任务以后，向调度机11中的任务管理模块112发送直播流转码任务的详情和/或流处理的相关参数配置；
②
变更/停止已有任务模块22，用于向任务管理模块112传递需要停止或变更的已有任务的id；
③
任务管理模块112，可用于向任务状态回调模块23返回任务的当前状态，以便于任务状态回调模块23进行任务状态回调；
④
任务管理模块112，可用于从工作机管理模块113查询分布式流处理系统1中的可用工作机；
⑤
注册&心跳发送模块1213，可用于向调度机11中的工作机管理模块112发送注册工作机请求和心跳，所述心跳用于向调度机11上报工作机12的可用度；
⑥
任务管理模块112，还可用于向任务接收模块1212派发新任务/变更已有任务/停止已有任务；
⑦
任务接收模块1212，可用于向处于在线状态的工作者2派发新任务/变更已有任务/停止已有任务；
⑧
工作者2还可以定时向任务管理模块112反馈任务的执行状态，如果ffmpeg(一套可以用来记录、转换数字音频、视频，并能将其转化为流的开源计算机程序)启动失败，则返回失败原因；
⑨
工作者进程管理/监控模块1211，可用于上线(start)工作者2；
⑩
工作者进程管理/监控模块1211，还可用于下线(stop)工作者1；工作者2上线后可以启动或禁止ffmpeg
‑
1、ffmpeg
‑
2、
……
、ffmpeg
‑
n进程；工作者1下线后可以终止ffmpeg
‑
1、ffmpeg
‑
2、
……
、ffmpeg
‑
n进程，等等。
49.继续参考图2可知，调度机11在向工作机派发任务时，还会参考资源(如缓存)13中存储的工作机
‑
可用度
‑
优先级队列、工作机
‑
上次心跳时间
‑
优先级队列和指定工作机在执行的任务
‑
上次心跳时间
‑
优先级队列等优先级队列，其中，指定工作机是指需要变更的任务所在的工作机。
50.下面对分布式流处理系统中工作机的部署进行详细的说明。
51.如图1所示一个工作机(worker)包括至少一个工作者(runner)和所述至少一个工作者的代理(agent)。本技术实施例中的工作机的部署是针对有状态任务处理的，因此可看作是有状态的工作机部署方案。
52.在本技术实施例中，工作者和代理可通过容器(如docker)部署在工作机中。可以理解，容器化部署对于集群扩容来说很便利，因为新增一台服务器之后，通过下载安装相应的容器即可完成工作者和代理的部署，无需的外搭建复杂的环境。
53.以直播流这种有状态的任务处理为例，本技术实施例提供的工作机的部署存在以下几个特点：
54.(1)一台工作机上，不能只有ffmpeg而没有java管理进程，而工作者就是java管理进程，因此，工作机上至少要部署一个工作者。
55.(2)工作者上线时，不能采用常规的镜像替换方式，要由代理进行管理。
56.(3)工作者下线前，要确保已分配给自身的任务已处理完，从而避免有损缩容。
57.(4)代理的上线不受约束。
58.(5)工作机和调度机之间的交互命令与工作者无关，而是由代理负责。
59.鉴于上述特点，工作机中的代理，当需要在所述工作机中上线一个新工作者时，将该工作机中处于在线状态的旧工作者设置为下线状态，并将该工作机中部署的新工作者设置为在线状态，其中，旧工作者处于下线状态时不接收新的待处理任务，且对已分配给自身的待处理任务继续进行处理，并在处理完已分配给自身的待处理任务后自动退出；工作机中的代理，还可将接收到新的待处理任务发送至所述新工作者，以使该新工作者对该新的待处理任务进行处理。
60.可以理解，在新工作者上线、旧工作者下线的这一过渡阶段，工作机中同时有两个工作者在运行，因此，本技术实施例提供的工作机支持多工作者(多实例)的部署和运行，可实现新旧任务处理应用同时在线工作的目的，不同工作者启动时会使用一套全新的部署端口，因此不会出现端口冲突。
61.具体实现时，可采用灰度方式对工作机中的代理和工作者进行上线。
62.(1)代理的上线可包括如下过程：503、旧代理停止发心跳给调度机；停止旧代理的进程；启动新代理的进程；200、新代理开始发心跳给调度机。
63.(2)工作者的上线可包括如下过程：工作者不直接上线，但可以通过scm打docker镜像；新工作者由代理通过传入docker image tag完成新进程的部署和启动；代理在部署新工作者成功之后，会对旧工作者发送下线命令；旧工作者在下线中不接收新任务，但需等待自己所有的ffmpeg进程执行完毕后自行退出；代理将新任务派发给新工作者。
64.其中，200：接收新任务；503：不接收新job，但接收已有job的修改和停止。处于下线状态(下线中)的工作者，不接收新任务、已有任务的修改和停止需调度机不断重试。
65.工作机中的代理和工作者上线后，还可以通过该工作机中的代理下发任务进行测试。测试没有问题后，可以进行全量上线。全量上线时，代理可直接全量上线，工作者的上线需要调用代理实现。上线过程中如出现问题，可进行回滚，对于代理，可直接回滚，对于工作者，需要调用其代理回滚。
66.可选地，分布式流处理系统中的服务器在完成工作者和工作者的代理的部署之后，该代理也可以通过访问调度机提供的指定url，向调度机注册成为工作机(worker)，注册的接口文档可包括如下内容：
67.(1)url
68.get/post|json http://live.xxx.weibo.com/dispatcher/worker/register
69.(2)params
70.参数名称必填类型说明workerinneriptruestring服务器内网ipworkerouteriptruestring服务器外网ipavailabilitytruedouble服务器可用度
71.(3)response
[0072][0073]
可选地，为了验证本技术实施例提供的一种分布式流处理系统的可用性，申请人还以直播流转推处理为例做了实验，实验内容如下：
[0074]
(1)ffmpeg实验
[0075]
实验目的
[0076]
探查docker内启动的ffmpeg(一套可以用来记录、转换数字音频、视频，并能将其转化为流的开源计算机程序)进程与docker进程的联系。
[0077]
实验环境
[0078]
docker镜像中已安装ffmpeg，java通过命令行调用的方式启动ffmpeg进行进行转推(一种直播流处理任务)；
[0079]
宿主机未安装ffmpeg；
[0080]
测试命令：ffmpeg
‑
re
‑
i rtmp://pl.live.weibo.com/alicdn/alarm
‑
vcodec libx264
‑
acodecaac
‑
f flv/data1/weibo/logs/test_stream。
[0081]
实验结论
[0082]
在docker中启动的ffmpeg进程是系统进程，可以在宿主机上查到；java中同步的方式调用ffmpeg命令，会阻塞java的线程，用nohup则不会阻塞；启动ffmpeg的java线程停止时，ffmpeg的进程仍在执行、不受影响，但java虚拟机进程(java virtual machine，jvm)或docker进程停止时，ffmpeg则停止；多个ffmpeg进程输出到同一个文件时，只有1个进程能成功。
[0083]
(2)docker实验
[0084]
实验目的
[0085]
在已启动的docker1(容器1)中，启动docker2(docker cli)，验证docker1停止时，docker2是否会停止。
[0086]
实验环境
[0087]
宿主机(host)和docker1的基础镜像均需安装docker命令。
[0088]
实验结论
[0089]
通过挂载
‑
v/var/run/docker.sock:/var/run/docker.sock，即可保证容器1中的docker cli能够访问宿主机上的docker daemon。这时docker1启动docker2时，实际是用宿主机的docker启动的，因此docker2的生命周期与docker1无关。>docker run
‑
ti
‑
v/var/run/docker.sock:/var/run/docker.sockdocker，此时如图3a所示。这时在宿主机和容器1中运行docker images、dockerps等指令会得到相同的输出。如果再次使用docker run创建新的容器，那么这个容器不是在容器1中，而会在宿主机上，具体如图3b所示。
[0090]
上述实验表明，本技术实施例提供的分布式流处理系统是可用的。
[0091]
可选地，在完成本技术实施例提供的分布式流处理系统后，外部系统(如图2中的流管理中心2)可向本技术实施例提供的分布式流处理系统提交任务，以进行处理，例如，提交开始或重新开始直播流转推任务。示例性的，提交任务的接口文档可包括如下内容：
[0092]
(1)url
[0093]
post|json http://live.xxx.weibo.com/dispatcher/job/startturnpushjob
[0094]
(2)params
[0095]
[0096][0097]
(3)response
[0098][0099]
上面介绍了本技术实施例提供的一种分布式流处理系统的架构、部署和可用性验证等过程，下面对利用本技术实施例提供的分布式系统进行任务调度的过程进行说明。
[0100]
需要说明的是，如无特殊说明，本技术实施例中述及的任务指流处理任务。
[0101]
可选地，图1所示的分布式流处理系统，在派发新任务时：
[0102]
调度机，可用于接收待处理任务，并将所述待处理任务发送至目标工作机中的代
理，其中，所述目标工作机是所述多个工作机中的一个。
[0103]
调度机接收的待处理任务可以是来自外部的流管理中心的流处理任务，其中，流管理中心可属于源站，例如，属于直播源站的直播流处理中心。
[0104]
目标工作机中的代理，可用于将接收到的待处理任务发送至目标工作机中处于在线状态的目标工作者。
[0105]
例如，当图1中的工作机1为目标工作机，且其中的工作者2处于在线状态(在线中)，而工作者1处于下线状态(下线中)时，则工作机1中的代理在接收到待处理任务时，可发送至工作机1中的工作者2。
[0106]
目标工作者，可用于对接收到的流处理任务进行处理。
[0107]
可选地，目标工作机中处于下线状态的工作者，可用于对已分配给自身的待处理任务继续进行处理，并在处理完已分配给自身的待处理任务后自动退出。
[0108]
本技术实施例提供的一种分布式流处理系统，包含调度机、工作者和工作者的代理三个角色，由调度机统一接收和分发来自外部的待处理任务，由工作机中的代理接收来自调度机的任务，并由工作机中的代理将任务分配给处于在线状态的工作者，由工作机中处于在线状态的工作者对新接收的任务进行处理，且工作机中处于下线状态的工作者，可对已分配给自身的待处理任务继续进行处理，并在处理完已分配给自身的待处理任务后自动退出。因此，可以很好地对有状态的流处理任务进行处理而不中断。
[0109]
可选地，为了合理利用分布式系统中各个工作机的性能，可以将分布式系统中的多个工作机划分成多个逻辑及集群，其中一个逻辑集群对应处理一种类型的流处理任务，相应的，调度机在将待处理任务发送至目标工作机中的代理前，还可用于基于所述待处理任务的任务类型确定处理所述待处理任务的目标逻辑集群，其中，所述目标逻辑集群是所述多个逻辑集群中的一个；然后基于目标逻辑集群中的工作机的可用度，确定处理所述待处理任务的目标工作机，其中，所述工作机的可用度是根据所述工作机的至少一个性能指标的可用度确定的。当然调度机也可采用其他方式确定目标工作机，例如随机确定，本技术实施例对此不做限制。
[0110]
在本技术实施例中，可以预先根据流处理任务的类型，将分布式流处理系统中的工作机划分成多个逻辑集群(将整个集群划分成多个逻辑集群)，其中，一个逻辑集群对应处理一种类型的流处理任务。如图4所示，可以将分布式流处理系统中的工作机划分成第一逻辑集群41、第二逻辑集群42和第三逻辑集群43等多个逻辑集群。以直播流处理任务为例，可能包括转推、h264转码、h265转码等多种任务类型，相应的，可以将分布式流处理系统中的工作机划分成通用任务集群(均衡型服务器)、拉流转推集群(带宽型服务器，连接外网)、h264转码集群(cpu密集型服务器，无需外网)、h265转码集群(定制gpu板卡型服务器，无需外网)和监控集群(存储型服务器)等几个逻辑集群。
[0111]
此外，还可以按不同的地域对整个集群进行划分，然后针对不同地域的集群再根据任务类型划分成多个逻辑群，相应的，可以先基于产生流处理任务的地域确定地域集群，然后在该地域的集群中，基于待处理任务的任务类型确定处理待处理任务的目标逻辑集群。
[0112]
可以理解，将整个集群划分成多个逻辑集群，可以更好地利用集群的优势资源、节省成本。
[0113]
上述调度机具体可用于：通过工作机中的代理，先确定该工作机的至少一个性能指标的可用度，然后将该工作机的上述至少一个性能指标的可用度中最小者确定为所述工作机的可用度。上述至少一个性能指标可包括但不限于cpu使用率、gpu使用率、空闲内存、空闲磁盘、io使用率、网卡带宽占用情况和任务数量中的至少一个。上述至少一个性能指标的可用度以及最终确定出的工作机的可用度可用0～1之间的数值表示，该值越接近1，表明可用度越大，反之，说明可用度越小。
[0114]
更为具体的，分布式流处理系统中的工作机中的代理会按预设时间间隔(如每秒)获取并统计计算该工作机的上述至少一个性能指标的可用度。例如，工作机中的代理可调用系统api(cat/proc/stat)来获取cpu可用度(cpu可用度＝1
‑
cpu使用率)，调用结果如图5a所示。再如，工作机中的代理可调用系统api(free
‑
m)来获取内存可用度(内存可用度＝内存空闲率)，调用结果如图5b所示。工作机中的代理计算出该工作机的上述至少一个性能指标的可用度后，取这些性能指标的可用度中的最小值作为该工作机的可用度。之所以选最小值，是考虑到木桶的短板效应，当某项性能指标的可用度达到瓶颈时，即使其他性能指标的可用度很富余，也是无法处理新任务的。
[0115]
可选地，工作机中的代理，可用于向调度机发送心跳，以上报所述工作机的可用度。
[0116]
具体的，在工作机中的代理确定出该工作机的可用度之后，会调用调度机的http接口发送上报可用度的心跳。如图6所示，工作机1在执行任务1、任务2和任务3的同时，可每秒钟根据cpu/gpu使用率、空闲内存、空闲磁盘、io使用率、网卡带宽占用情况和任务数量等性能指标的可用度，计算工作机1的可用度，并将计算出的数值(可用度为0.9)通过心跳上报给调度机，工作机2和工作机3也通过类似的方式计算并向调度机上报自身的可用度，其中，工作机2和工作机3计算出的可用度分别为0.7和0.5。
[0117]
上述调度机具体可用于：从目标逻辑集群中可用度排名最高的多个工作机中，选择一个工作机作为处理所述待处理任务的目标工作机。
[0118]
更为具体的，调度机在接收到各个工作机的可用度之后，会将其缓存在一个中央的redis缓存中，并通过zset结构按逻辑集群将各个工作机的可用度从高到低进行排序，图7示出了一种以cpu的可用度为工作机的可用度的排序结果，共包含10台工作机。排序完成后，当调度机需要下发新任务(job)时，会将新任务派发给可用度最高多个工作机(如top5)中的一个以保证集群整体的负载均衡。
[0119]
需要说明的是，图5a、图5b和图7还通过打马赛克的方式隐去了一些敏感信息；以及，图7中显示的gpu可用度为0的含义是这些工作机没有gpu这个性能指标。
[0120]
可选地，外部系统(如图2中的流管理中心2，或本技术实施例提供的分布式流处理系统的运维系统等)还可以获取本技术实施例提供的分布式流处理系统的整体可用度(分布式集群的可用度)，示例性的，其接口文档可包括如下内容：
[0121]
(1)调度机提供的统一资源定位器(uniform resource locator,url)
[0122]
post|json http://live.xxx.weibo.com/dispatcher/worker/getavailability
[0123]
(2)参数(params)
[0124]
参数名称必填类型说明workerfalseboolean指定runner的ip
[0125]
(3)结果(response)
[0126][0127]
可选地，图1所示的分布式流处理系统，在对执行中的任务进行变更或修改时：
[0128]
调度机，可用于在接收到任务变更请求时，基于任务变更请求所要变更的目标任务的标识，确定目标任务所在的指定工作机，然后调用指定工作机中的代理，向指定工作机中处理所述目标任务的工作者发送所述变更请求。
[0129]
指定工作机中处理所述目标任务的工作者，可用于对目标任务进行变更。
[0130]
可选地，外部系统(如分布式流处理系统的运维系统)还可以调用调度机获取分布式流处理系统的整体可用度，该整体可用度一般可用分布式流处理系统中工作机的平均可用度来表示，或者用分布式流处理系统中工作机的平均可用度和工作机数量来表示，本技术对此不做限制。
[0131]
相应的，调度机，可用于基于分布式流处理系统中的多个工作机的可用度，确定分布式流处理系统的整体可用度；当所述分布式流处理系统的整体可用度低于第一预设阈值时，提醒运维系统对所述分布式流处理系统进行扩容；当所述分布式流处理系统的整体可用度高于第二预设阈值时，提醒运维系统对所述分布式流处理系统进行缩容；其中，所述第二预设阈值(如0.95)大于所述第一预设阈值(如0.5)。
[0132]
不难看出，本技术实施例提供的分布式系统，可自动发现是否需要扩容，并自动提醒运维系统对齐进行扩容或缩容，且由于代理和工作者是通过容器部署的，因此扩容或缩容过程可由运维系统自动实现，扩容/缩容效率高。
[0133]
可选地，图1所示的分布式流处理系统，在应用中会遇到一些故障，例如会因网络闪断、源流无内容/有ip限制、pts/dts时间戳跳变、推流失败/源站故障、任务启动失败或异常退出等问题引起任务处理中断、失败等异常。为解决这些问题，本技术实施例还提出了一些故障恢复策略，下面结合图8进行介绍。
[0134]
如图8所示，工作机1的工作者在执行任务时，如果当前任务处于存活状态(
①
while(job.isalive))，则继续执行；当当前任务被阻塞时，该工作者会对当前任务进行重启(
②
重启)；当当前任务的主源流中没有内容时，该工作者会从当前任务的备用源流获取
当前任务的内容(
③
切源流)；当当前任务的日志出现异常无法自行恢复时，通过该工作者杀死当前任务的进程并重启当前任务；当工作机1中的代理在预设时长(通过定时器监测)内未向调度机发送包含工作机1的可用度的心跳时，调度机会将工作机1中的工作者未处理完的任务转移给工作机2；工作机1中的工作者还会删除分配自身的过期任务。
[0135]
根据上述描述可知，本技术实施例提供的分布式流处理系统，可以完全自动化地、可靠地实现流处理任务的调度，并且可以很好地对有状态的任务进行调度，当任务出现变更或修改时，可以保证流处理任务不会中断，在直播场景下保障了良好的用户体验，通过逻辑集群划分和可用度计算，可合理的使用服务器资源，保障系统容量并节省了成本。总之，在用本技术实施例提供的分布式流处理系统进行流处理任务的调度时，可以克服相关技术中的流处理任务调度方案存在的至少一种缺陷。
[0136]
在上述分布式流处理系统的基础上，如图9所示，本技术实施例提供了一种流处理任务调度方法，该方法可应用于图1所示的分布式流处理系统，该方法可包括：
[0137]
步骤901、通过所述调度机接收待处理任务，并将所述待处理任务发送至目标工作机中的代理，其中，所述目标工作机是所述多个工作机中的一个。
[0138]
可选地，所述多个工作机被划分成多个逻辑集群，一个逻辑集群对应处理一种类型的流处理任务，在所述将所述待处理任务发送至目标工作机中的代理前，所述方法还包括：基于所述待处理任务的任务类型确定处理所述待处理任务的目标逻辑集群，其中，所述目标逻辑集群是所述多个逻辑集群中的一个；基于所述目标逻辑集群中的工作机的可用度，确定处理所述待处理任务的目标工作机，其中，所述工作机的可用度是根据所述工作机的至少一个性能指标的可用度确定的。
[0139]
所述至少一个性能指标包括cpu使用率、gpu使用率、空闲内存、空闲磁盘、io使用率、网卡带宽占用情况和任务数量中的至少一个。
[0140]
可选地，所述方法还包括：通过所述工作机中的代理将所述工作机的所述至少一个性能指标的可用度中最小者确定为所述工作机的可用度；通过所述工作机中的代理向所述调度机发送心跳，以上报所述工作机的可用度。
[0141]
可选地，所述基于所述目标逻辑集群中的工作机的可用度，确定处理所述待处理任务的目标工作机，包括：从所述目标逻辑集群中可用度排名最高的多个工作机中，选择一个工作机作为处理所述待处理任务的目标工作机。
[0142]
可以理解，利用工作机的可用度确定处理待处理任务的目标工作机，可以合理利用各工作机的性能，既可以避免出现有些工作机的处理压力大无法快速进行流处理的缺陷，也可以避免有些工作机的工作能力未被充分利用存在资源浪费的情况。
[0143]
步骤902、通过所述目标工作机中的代理将所述待处理任务发送至所述目标工作机中处于在线状态的目标工作者。
[0144]
步骤903、通过所述目标工作者对所述待处理任务进行处理。
[0145]
可选地，所述方法还包括：
[0146]
当需要在所述工作机中上线一个新工作者时，通过所述工作机中的代理将该工作机中处于在线状态的旧工作者设置为下线状态，并将该工作机中部署的新工作者设置为在线状态，其中，所述旧工作者处于下线状态时不接收新的待处理任务；
[0147]
通过所述旧工作者对已分配给自身的待处理任务进行处理，其中，所述工作机中
的旧工作者在处理完已分配给自身的待处理任务后自动退出；
[0148]
通过所述工作机中的代理将接收到新的待处理任务发送至所述新工作者；
[0149]
通过所述新工作者对该新的待处理任务进行处理。
[0150]
可选地，所述方法还可包括：
[0151]
当所述调度机接收到任务变更请求时，通过所述调度机基于所述任务变更请求所要变更的目标任务的标识，确定所述目标任务所在的指定工作机；
[0152]
通过所述调度机调用所述指定工作机中的代理，向所述指定工作机中处理所述目标任务的工作者发送所述变更请求；
[0153]
通过所述指定工作机中处理所述目标任务的工作者，对所述目标任务进行变更。
[0154]
可选地，所述方法还可包括：
[0155]
通过所述调度机基于所述多个工作机的可用度，确定所述分布式流处理系统的整体可用度；
[0156]
当所述分布式流处理系统的整体可用度低于第一预设阈值时，通过所述调度机提醒运维系统对所述分布式流处理系统进行扩容；
[0157]
当所述分布式流处理系统的整体可用度高于第二预设阈值时，通过所述调度机提醒运维系统对所述分布式流处理系统进行缩容；
[0158]
其中，所述第二预设阈值大于所述第一预设阈值。
[0159]
可选地，所述方法还可包括下述步骤中的至少一个：
[0160]
当所述工作机中的工作者所处理的当前任务被阻塞时，通过该工作者对所述当前任务进行重启；
[0161]
当所述工作机中的工作者所处理的当前任务的主源流中没有内容时，通过该工作者从所述当前任务的备用源流获取所述当前任务的内容；
[0162]
当所述工作机中的工作者所处理的当前任务的日志出现异常时，通过该工作者杀死所述当前任务的进程并重启所述当前任务；
[0163]
当所述工作机中的代理在预设时长内未向所述调度机发送包含该工作机的可用度的心跳时，通过所述调度机将所述工作机中的工作者未处理完的任务转移给另一工作机；
[0164]
通过所述工作机中的工作者删除分配给该工作者的过期任务。
[0165]
本技术实施例提供的一种流处理任务调度方法，由于采用包含调度机、工作者和工作者的代理三个角色的分布式流处理系统，由调度机统一接收和分发来自外部的待处理任务，由工作机中的代理接收来自调度机的任务，并由工作机中的代理将任务分配给处于在线状态的工作者，由工作机中处于在线状态的工作者对新接收的任务进行处理，因此，可以很好地对有状态的流处理任务进行处理而不中断。
[0166]
此外，当任务出现变更或修改时，可以保证流处理任务不会中断，在直播场景下保障了良好的用户体验；通过逻辑集群划分和可用度计算，可合理的使用服务器资源，保障系统容量并节省了成本。
[0167]
总之，本技术实施例提供的一种流处理任务调度方法，可以克服相关技术中的流处理任务调度方案存在的至少一种缺陷。
[0168]
需要说明的是，由于方法实施例执行的内容是基于系统实施例的，因此，本文对方
法实施例部分描述的较为简略，相关之处请参见方法实施例部分。
[0169]
本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd
‑
rom、光学存储器等)上实施的计算机程序产品的形式。
[0170]
本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0171]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0172]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0173]
需要说明的是，本技术中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0174]
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。
[0175]
以上仅为本技术的实施例而已，并不用于限制本技术。对于本领域技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本技术的权利要求范围之内。