CN116860406A - 基于消息队列系统的调度方法、装置、设备及存储介质 - Google Patents

基于消息队列系统的调度方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN116860406A
CN116860406A CN202310707397.7A CN202310707397A CN116860406A CN 116860406 A CN116860406 A CN 116860406A CN 202310707397 A CN202310707397 A CN 202310707397A CN 116860406 A CN116860406 A CN 116860406A
Authority
CN
China
Prior art keywords
scheduling
instance
master node
cluster
message queue
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310707397.7A
Other languages
English (en)
Inventor
程君杰
袁小栋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Cloud Computing Ltd
Original Assignee
Alibaba Cloud Computing Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Cloud Computing Ltd filed Critical Alibaba Cloud Computing Ltd
Priority to CN202310707397.7A priority Critical patent/CN116860406A/zh
Publication of CN116860406A publication Critical patent/CN116860406A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/548—Queue

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本公开提供一种基于消息队列系统的调度方法，所述方法用于将调度体集合中调度体调度给实例集群中的实例进行处理；所述方法应用于所述实例中，所述实例集群中的实例启动后在所述服务端注册为同一消息队列的消费者，所述方法包括：通过所述服务端确定实例集群中实例是否发生变化，以及确定调度体集合中调度体是否发生变化；若所述实例集群中发生实例变化或所述调度体集合中发生任务变化，确定自身是否为主节点；若自身为主节点，利用设定调度策略，将当前调度体集合中各调度体调度至当前实例集群中的一个或多个目标实例中运行；或，若确定自身不是主节点，获取主节点分配的调度体并处理。

Description

基于消息队列系统的调度方法、装置、设备及存储介质
技术领域
本公开涉及计算机技术领域，尤其涉及基于消息队列系统的调度方法、装置、设备及存储介质。
背景技术
目前，一些业务系统具有调度需求；以安全信息管理和事件管理系统(SIEM，Security Information and Event Management)为例，SIEM系统根据业务需要会接入一个或多个数据源，并且会对每个数据源(例如，日志库等)生成数据采集任务，并且分配机器集群(包括一台或多台机器)用于运行数据采集任务。目前SIEM系统未实现对数据采集任务的调度，其考虑到数据源的数据量是动态变化的，且一些数据源具有负载功能，因此会将每个数据源的数据采集任务都运行在各台机器上。如此，有必要在业务系统中实现调度功能。
发明内容
为克服相关技术中存在的问题，本公开提供了基于消息队列系统的调度方法、装置、设备及存储介质。
根据本说明书实施例的第一方面，提供一种基于消息队列系统的调度方法，所述消息队列系统包括消息队列、消费者、以及管理所述消息队列和所述消费者的服务端；
所述方法用于将调度体集合中调度体调度给实例集群中的实例进行处理；所述方法应用于所述实例中，所述实例集群中的实例启动后在所述服务端注册为同一消息队列的消费者，所述方法包括：
通过所述服务端确定实例集群中实例是否发生变化，以及确定调度体集合中调度体是否发生变化；
若所述实例集群中发生实例变化或所述调度体集合中发生任务变化，确定自身是否为主节点；
若自身为主节点，利用设定调度策略，将当前调度体集合中各调度体调度至当前实例集群中的一个或多个目标实例中运行；或，若确定自身不是主节点，获取主节点分配的调度体并处理。
根据本说明书实施例的第二方面，提供一种基于消息队列系统的调度装置，所述消息队列系统包括消息队列、消费者、以及管理所述消息队列和所述消费者的服务端；
所述装置用于将调度体集合中调度体调度给实例集群中的实例进行处理；所述装置应用于所述实例中，所述实例集群中的实例启动后在所述服务端注册为同一消息队列的消费者，所述装置包括：
发现模块，用于：通过所述服务端确定实例集群中实例是否发生变化，以及确定调度体集合中调度体是否发生变化；
选主模块，用于：若所述实例集群中发生实例变化或所述调度体集合中发生任务变化，确定自身是否为主节点；
调度模块，用于：若自身为主节点，利用设定调度策略，将当前调度体集合中各调度体调度至当前实例集群中的一个或多个目标实例中运行；或，若确定自身不是主节点，获取主节点分配的调度体并处理。
根据本说明书实施例的第三方面，提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现前述第一方面所述方法实施例的步骤。
根据本说明书实施例的第四方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现前述第一方面所述方法实施例的步骤。
本说明书的实施例提供的技术方案可以包括以下有益效果：
本说明书实施例中，实例集群中的实例启动后注册为同一消息队列的消费者，每个实例通过所述服务端确定实例集群中实例是否发生变化，以及确定调度体集合中调度体是否发生变化；若所述实例集群中发生实例变化或所述调度体集合中发生任务变化，确定自身是否为主节点；若自身为主节点，利用设定调度策略，将当前调度体集合中各调度体调度至当前实例集群中的一个或多个目标实例中运行；或，若确定自身不是主节点，获取主节点分配的调度体并处理。因此，任务并未在每个实例中运行，而是由主节点利用设定调度策略进行调度，能够在业务系统中基于消息队列系统实现自定义的调度功能。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本说明书的实施例，并与说明书一起用于解释本公开的原理。
图1是本说明书根据一示例性实施例示出的一种数据采集的场景示意图。
图2A是本说明书根据一示例性实施例示出的一种基于消息队列系统的调度方法示意图。
图2B是本说明书根据一示例性实施例示出的一种消息队列系统的示意图。
图2C是本说明书根据一示例性实施例示出的一种节点通信示意图。
图2D是本说明书根据一示例性实施例示出的一种调度场景示意图。
图2E是本说明书根据一示例性实施例示出的另一种调度场景示意图。
图3是本说明书根据一示例性实施例示出的一种基于消息队列系统的调度装置所在计算机设备的一种硬件结构图。
图4是本说明书根据一示例性实施例示出的一种基于消息队列系统的调度装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。
在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
本公开所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。
很多业务系统具有调度需求。以SIEM系统为例，该系统主要用于维护企业网络安全，保障企业数据安全。SIEM的主要功能包括安全日志管理、安全事件检测、威胁分析、安全响应以及安全审计等功能。安全日志管理，主要是通过采集、分析、存储和管理网络设备、服务器、应用程序等安全日志，来方便用户审计、诊断和响应安全事件。
SIEM系统中包括有数据采集模块，此处的数据采集，需要针对不同的数据源生成不同的采集任务，将用户需要的多类产品的数据进行收集，经过一定的处理、分析和运算，最终写入至SIEM系统的指定位置。数据采集模块产生的数据是SIEM系统中的其他如数据分析等模块的基础，为后续安全事件的检测、分析和响应来服务。因此，数据采集是SIEM系统的重要基础；而数据采集任务的调度，关系到数据是否健全、任务是否稳定、资源消耗是否最优等问题。
SIEM的采集器采用了轻量级的实时计算引擎RStream(Rocket Message QueueStreams，一种消息队列系统的流式处理)作为采集任务的任务引擎。该引擎可兼容SQL(Structured Query Language，结构化查询语音)语法，支持SLS(Log Service，日志服务)、Kafka(Apache Kafka，一种分布式流处理平台和消息队列系统)、OpenAPI(OpenAPISpecification，机器可读接口文档的规范)等数据源类型。Rstream不但支持数据的采集，还支持在采集的过程中对数据做复杂的处理；目前，Rstream实例以进程的模式运行，采集任务则以线程的方式运行在RStream实例上；RStream实例支持横向的动态扩展。
如图1所示，是本说明书根据一示例性实施例示出的一种数据采集的示意图，图中以4个数据源Source为例，包括Source1至Source4；不同Source表示不同数据源。图中的Source还可以根据实际场景进行数据分片。例如图中示出了Source1划分为3个数据分片，包括数据分片P1至P3。Source2当前未进行分片，只有一份数据P1。图中示出了实例集群，以5个实例Instance为例，包括Instance1至Instance5。此处的实例可以是运行数据采集任务的计算引擎的独立单元，如一台主机(物理主机或虚拟主机均可)，也可以是一个进程等。已有技术中会存在一些问题：
1.每个实例运行全量的数据采集任务
已有技术中SIEM系统未有调度功能，其分配了实例集群后，对于每个数据源的数据采集任务均会在每个实例中启动。例如，针对Source1的数据采集任务Task1，从图中可见到5个实例均会运行。图1中各个Task1是一样的，用于对采集到的数据执行相同的处理逻辑，不同在于采集数据的位置或处理后存储的数据的位置可能不同。Source2的数据采集任务Task2也如此，以此类推。如此，在分片数量少于集群中机器数量的情况下，一些机器中的数据采集任务实际上并未采集数据，会造成资源浪费问题。
例如，图1中5个实例都运行了数据采集任务Task1，但由于Source1自身的数据调度，其会将3个分片调度至3个Task中，即图1中的Instance1至Instance3中的Task1，而另外两台Instance4和Instance5虽然也在运行Task1，但是由于Source1未为其调度数据分片，根据任务的相关逻辑，也都会占用一些必要的线程池、缓存、数据库连接等，即便是没有分配到数据分片，资源同样也会被占用，这样就造成了服务器资源的大量浪费。同理，Source2至Source4由于数据分配的调度，也会造成同样的问题。
2.数据源中数据的负载和调度只能依赖数据源自身的特点
由于是由数据源进行负载均衡，因此数据的负载和调度只能依赖数据源自身的特点。分布式场景下数据源，大多都会根据自己对Consumer的限制数量，对数据做负载和调度。以数据源的类型为SLS(Log Service，日志服务)为例，SLS中Source会根据自己的分片数以及集群中机器数量进行一一的匹配。例如图1中示出的，Source会根据分片数n，分配前n个实例来分别处理每个分片。虽然每个实例上都启动任务，但数据源按照调度策略，只会把数据分片调度到前几个实例上，这种情况在数据源的分片数量少于实例分片时尤为明显。而在一些场景下，一些数据源的分片数比较少，例如安全场景下，SIEM的各类型数据源分片数通常是由用户配置的，分片数量都很少，1至2个分片最为常见，这样集群的压力极度的不平衡，例如图1中前两个实例的压力明显大于后面的3个实例。此种情况下，启动再多的计算实例，也无法解决压力不均衡的问题。例如，以10台4CPU(Central Processing Unit)8GB(GigaByte，吉字节)内存的容器组成的集群，整个集群的运行能力取决于前几个实例的运行能力，当每个实例都全量启动20个任务时，前几台实例的CPU占用达到100％，而后面的实例，CPU占用率不到10％，且扩容无法解决资源利用倾斜的问题。
3.无法支持离线数据的采集
对于离线数据的采集任务，依然是运行在每个实例中。由于离线数据作为数据源，数据源不会去主动切割分片，所以每个运行的任务都是拉取的全量的数据，如果调度有问题，就会出现数据丢失或者数据重复，给业务造成很大的影响。
4.Push模式下数据源对消费组有限制
消息队列系统中采用Push(推)模式或Pull(拉)模式进行消息传输。在推模式中，消息生产者主动将消息推送到消息队列中，消息消费者则通过订阅相关主题的消息队列接收消息。在拉模式中，消息消费者主动从对应主题的消息队列中拉取消息进行处理。
目前对于消息数据的采集，大多采用Push(推)的模式，对数据源进行订阅，实现数据的采集。在Push模式下，由数据源进行负载均衡，即由数据源进行采集任务的调度，将采集任务分配至集群中的实例。然而，Push模式下数据源会有消费组的限制。消费组是指一组消息消费者，它们共同从同一个主题的队列中消费消息。在Push模式下会存在多种问题。
以图1为例，集群中有多个实例，假设有某个用户对Source4具有消费需求，其会创建一消费组，假设该消费组中包括Instance1至Instance4共4个消费者；Source4中包括4个数据分片，Source4将4个数据分片平均分配至4个消费者，即4个消费者中分别有一个数据采集任务，即图中Instance1至Instance4中各个Task4，每个数据采集任务用于采集Source4的其中一个数据分片。
实际应用中，存在有其他需求，需要创建另一消费组用于消费Source4(图中未示出更多消费组)，另一消费组中消费者的数量可以根据需要进行配置。因此，消费组数量限制，是指数据源限制的数量，例如一些数据源设置了消费者Consumer数量为2000个。实际应用中若业务数量较多，存在大量的不同业务需要消费同一数据源，当该数据源的消费组数量达到限制数量，则无法再创建消费组，导致业务无法使用数据源。对于实例运行后启动的每个任务，无论是否会分到分片，都会占用Consumer的数量，稍不注意就会超限。再者，Push模式也无法支持离线数据的采集。
基于此，本说明书实施例希望在业务系统中实现对任务的调度，因此需要在业务系统中实现调度引擎。然而，已有的调度框架或多或少都存在一些问题。
例如，常见的调度框架有Apache(阿帕奇)的Yarn(Yet Another ResourceNegotiator，一种集群资源管理系统)以及Mesos(Mesosphere Elastic ScalableOperating System，一种开源集群资源管理系统)，这两个资源管理及调度框架通常用于比较复杂的分布式调度场景，如Hadoop(一种分布式存储和计算框架)、Spark(一种基于内存计算的大数据处理框架)、Flink(一种流式计算引擎)等任务的调度；Kubernetes(一种开源的容器编排系统)主要用于容器的调度；这些调度框架本身较重，也即是这些调度框架需要采用独立的集群实现。而在一些场景下，例如前述的SIEM系统等场景下，业务上已经实现了SIEM系统，希望能SIEM系统内集成调度框架，因此上述的调度框架无法采用。
而轻量级的调度框架有Quartz(一种开源的作业调度框架)和Elastic-Job(一种分布式作业调度解决方案)等，Quartz是基于数据库(Data Base，DB)锁实现分布式的调度，但稳定性不够。而Elastic-Job是基于Zookeeper(一种分布式协调服务)以及Quartz来实现分布式调度，需要依赖Zookeeper。采用Quartz结合数据库锁的方式，可以实现简单灵活的分布式任务调度，但是存在如下问题：
1.性能问题：使用数据库锁可能会影响整个系统的性能，因为当多个节点同时访问数据库时，会增加数据库的负载，可能导致调度系统变慢或者崩溃。
2.高可用性问题：当某个节点崩溃或者网络故障时，可能会导致分布式锁无法释放，从而导致任务调度系统不可用，因此需要考虑如何保证高可用性。
3.数据库单点问题：如果使用的是单个数据库实例，那么数据库本身就成为了系统的单点故障。一旦数据库崩溃，所有的节点都无法获取到锁，整个调度系统将停止工作。
4.复杂性问题：使用数据库锁实现分布式锁需要处理一些复杂的问题，例如死锁、竞态条件等。需要仔细考虑各种边界情况，以确保系统的正确性。
基于此，本说明书实施例希望在已有业务系统的基础上，以较少的依赖实现调度引擎，该调度引擎可集成在已有业务系统内，构建适合业务系统的调度体系。业务系统以SIEM系统为例，希望可以构建适合SIEM系统的数据采集的调度体系，支持SIEM采集任务的调度，更进一步地还能支持SIEM数据源内部分片的调度。基于此，面临的挑战包括：
(1)基于业务系统已有的依赖，不引入额外的依赖，实现调度系统。目前，很多业务系统中采用消息队列系统作为某些功能的支持。例如，以SIEM系统为例，该业务系统数据采集任务采用消息队列系统作为支持，例如RocketMQ系统等，在该SIEM系统中还实现了计算框架RocketMQ Streams(简称RStream)，该RocketMQ Streams是基于RocketMQ构建的一个轻量级的开源实时计算框架。目前RStream框架本身仅依赖了RocketMQ以及数据库DB，因此对于SIEM系统来说，调度引擎也希望能够仅依靠RocketMQ和DB来实现。
(2)分布式的任务调度，会引入一致性的问题；如何保障在调度过程中，集群中运行的任务不会超过预期的数量是需要关注的问题。在离线数据场景下，例如OpenAPI为数据源的采集任务希望是在任何时间点，有且仅有一个或者0个数据采集任务在集群运行才符合预期，否则会造成数据的重复拉取，给后续安全事件的统计分析造成一定的影响。
(3)在数据采集场景下，调度系统需要适配SIEM数据采集不同的场景，兼容实时数据和离线数据的采集。如对于离线数据(如数据库DB或OpenAPI等)的采集任务，调度系统需要确保集群中有一个任务来进行采集，或者对数据源做分片，为每个分片指定一个采集任务；对于实时数据(如SLS，Kafka等)的采集任务，调度系统需要保证集群中的采集任务数与数据源的分片数相同。
基于此，本说明书实施例提供了一种基于消息队列系统的调度方法，所述消息队列系统包括消息队列、消费者、以及管理消息队列和所述消费者的服务端；所述方法用于将调度体集合中调度体调度给实例集群中的实例进行处理；所述方法应用于所述实例中，所述实例集群中的实例启动后注册为同一消息队列的消费者，如图2A所示，包括如下步骤：
步骤202，通过所述服务端确定实例集群中实例是否发生变化，以及确定调度体集合中调度体是否发生变化。
步骤204，若所述实例集群中发生实例变化或所述调度体集合中发生任务变化，确定自身是否为主节点。
步骤206，若自身为主节点，利用设定调度策略，将当前调度体集合中各调度体调度至当前实例集群中的一个或多个目标实例中运行。
步骤208，若确定自身不是主节点，获取主节点分配的调度体并处理。
实际应用中，本实施例方法从实现上，可以作为一调度引擎集成在业务系统中的某个需要调度的模块中。例如，前述SIEM系统中包括数据采集模块，该数据采集模块用于运行数据采集任务，数据采集任务用于从接入的数据源中采集所需的数据。
在数据采集场景下，数据源可以有多种类型，例如前述的在线实时数据SLS或Kafka，以及离线数据如数据库DB或OpenAPI等。作为例子，以云计算场景下的云产品为例，用户配置了多种类型的多个云产品，每一个云产品均可以作为数据源。以WAF(WebApplication Firewall Cloud Product，Web应用防火墙)为例，用户开启了一个WAF云产品实例，其需要获得对该云产品实例的安全服务，则该WAF云产品实例可以接入SIEM系统，业务上则会产生对该WAF云产品实例的日志的数据采集任务。
在一些场景下，数据源的数据存储至库中，可以根据需要由用户配置分片或者是动态产生分片。例如，WAF日志放在一个log store(日志库)里面，该log store可以作为一个数据源Source，如图1中的Source1。一个云产品下有多个logstore(日志库)，就是多个Source。其他云产品例如高防产品的日志在另一个log store(日志库)里面，对应的是Source2。
本实施例方法可以应用于多种业务系统中，并不限定于前述的SIEM系统，只要业务系统在执行业务过程中具有调度需求即可。因此，基于不同的应用场景，此处的任务和实例可以有多种不同的实现方式。其中，任务作为调度体(即被调度的对象)，而实例则用于承载调度体，例如对调度体进行处理。
例如，在数据采集场景下，调度体/任务可以是数据采集任务，实例可以是一台主机(包括虚拟主机或物理主机)。如图1所示的，实例集群有5个实例，假设任务发生变动，例如在已接入数据源1、2和3的情况下，新接入数据源4，其有4个分片，数据源4需要进行数据采集，因此SIEM系统对其产生了数据采集任务Task4。本案的调度，是指在实例集群中的m个实例中，调度j个实例来运行Task4，m≥1。本案的调度，还包括，假设当前实例集群中实例发生变动，如何将已运行的、需继续运行的任务，从变动前的实例集群中调配到变动后的实例集群中。
在数据采集场景下，本实施例的调度，调度体还可以是数据分片，实例还可以是数据采集任务等等。当然，在其他场景下，调度体和实例可以根据需要进行其他的配置，本实施例对此不进行限定。
本实施例中的消息队列(Message Queue，MQ)系统可以包括RabbitMQ、Kafka、ActiveMQ、RocketMQ等。以RocketMQ为例，如图2B所示，是本说明书根据一示例性实施例示出的一种消息队列系统的示意图，包括NameServer(命名服务)集群、Broker(代理)集群、生产者集群和消费者集群四部分；其中：
NameServer集群实现有服务发现机制，用于管理集群中的所有Broker和Topic(主题)信息。NameServer的主要功能包括Topic路由信息管理、Broker管理(包括Broker注册和心跳检测)和消息发送者和消费者白名单管理等。
Broker集群是用于存储和转发消息。Broker集群可以由一台服务器组成，每台服务器上都运行着一个或多个Broker实例。Broker实例主要负责消息存储、投递和消费者拉取等操作。在Broker集群中，会将所有的Message Queue分配到不同的Broker上，实现数据的分布式存储和负载均衡。其中，Broker集群还可以实现Master-Slave(主从)模式，在Master-Slave主从模式下，每个Topic的Master Broker都会有一至多个Slave Broker，Slave Broker会从Master Broker中获取所有的数据，并且实时的进行同步。当MasterBroker发生故障或宕机时，可以很快地将Slave Broker转化为Master Broker，确保消息的持久性和不丢失性。
生产者集群通常包括多个生产者实例，每个生产者实例都可以向消息队列中发送消息。在RocketMQ中，生产者发送消息时可以选择发送到指定的Topic、Message Queue，也可以让RocketMQ自动选择Message Queue。
消费者集群通常由多个消费者实例组成，每个消费者实例可以从指定的MessageQueue中拉取消息进行消费。在RocketMQ中，消费者集群通过协调消费组(Consumer Group)进行消息分配和负载均衡。消费者可以通过指定消费顺序、拉取模式和消息过滤规则等方式来实现不同的消费需求。
本实施例的调度方案有两个功能，发现和调度。其中，发现主要是指集群变化的及时发现以及调度体(运行的任务、数据源的分片等)变化的及时发现。
在一些例子中，可以实现一定时任务，用于定时检测实例集群中各台实例的存活状态。在其他例子中，为了降低开发成本，还可以利用消息队列系统的已有机制来实现。
所述消费者向所述服务端发送心跳消息，所述服务端用于根据各消息者的心跳信息，获取消费者列表并发送给各消费者；
所述通过所述服务端获取实例集群中实例是否发生变化，包括：
从所述服务端获取消费者列表，根据所述消费者列表确定实例集群中实例是否发生变化。
例如，消息队列系统(如RocketMQ)中会通过Consumer心跳的探测，来检测Consumer的存活状态；利用这一点，可以实现实例集群变化的监控。本实施例将实例作为消息队列系统的Consumer，每个Consumer会向服务端发送心跳消息，NameServer会根据各个Consumer的心跳消息，得到各个Consumer的变化，还可以生成Consumer列表发送给各个Consumer。Consumer列表可以记录当前存活的各个Consumer的信息，可以根据当前接收的Consumer列表和上一次的Consumer列表进行比对，即可知道Consumer的变化，例如哪些Consumer上线、哪些Consumer下线、当前存活的Consumer等等。
在一些例子中，消息队列系统中实现有Rebalance(重新平衡)机制，在消息队列系统中，Rebalance是指Consumer客户端加入或退出Consumer组时，由Broker自动生成的负载均衡操作。Rebalance可以让Broker自动地将消息队列均匀地分配给新加入或退出的Consumer，从而使得消费组内各个Consumer的消息负载尽可能平衡。基于此，可以通过hook(钩子函数)Rebalance方法，即可便捷地实现发现功能。
另一方面，调度体的变化，可以通过对调度体的定时检查来发现。其中，对调度体检查的触发机制，也可以借助消息队列系统的Rebalance。因为消息队列系统的Rebalance可触发有俩种情况，一种是Consumer发生变化时触发，另一种是定时的触发，两种触发方式同时存在；通过Rebalance在Consumer发生变化时触发可以发现Consumer的变化，通过Rebalance的定时触发，可以触发对调度体的检查。
在一些例子中，每个所述实例在启动后注册为第一消息队列的消费者，以使所述服务端获取消费第一消息队列的消费者列表；其中，所述第一消息队列是所述实例集群启动后首个主节点创建的。
本实施例中，实例集群启动后首个主节点可以创建消息队列，作为示例，为了与后续的其他消息队列进行区别，本实施例将该消息队列命名为vote_topic；该topic仅用于集群中实例的发现，不做消息的传递；每个实例启动后，即启动该topic下的一个Consumer端，这些Consumer都属于该消息队列下的同一个ConsumerGroup(实例集群)。基于此，服务端通过该消息队列vote_topic，即可发现该消息队列下各Consumer的存活状态。例如，每个Consumer的心跳消息定时发送至该消息队列，服务端即可通过该消息队列确定各Consumer的存活状态的变化。
本实施例的调度主要是指将集群实例和运行在集群中的调度体进行协调和管理，实现整个采集引擎的高效运行；基于发现机制，每个实例可以实时拿到最新的调度体(采集任务或者采集数据源的分片)以及最新的可用实例，根据不同的调度策略，可以对调度体和运行实例进行各种各样的映射，形成最终的调度名单，并将该调度名单通过消息队列的消息，发送给每一个执行实例；执行实例收到最新的调度名单后，会根据当前自己的运行状态，下线已经运行的不在名单上的调度体，上线名单上新的调度体，从而保障调度的完成。
本实施例中的调度策略可以根据业务的实际情况自行定义，基于此，本实施例可以实现灵活的调度策略。作为例子，可以包括如下一种或多种：
全策略AllStrategy，即任务会运行在每个实例上，相当于前述的无调度模式，实例集群中有j个实例，在j个实例均会运行数据采集任务。
通用策略AveragelyStrategy，即任务会平均分配到每个运行的实例上。例如，数据源集合中有n个数据源，数据源i任务为Taski，每个Taski运行在ni个实例上；实例集群中有m个实例；此处的平均，是指任务总数平均分配到m个实例中。
一致性策略ConsistencyStrategy，即任务会平均分配到每个运行的实例上，当集群发生变化时，保障重新调度过程中，变化是最小的。
Hash策略HashStrategy，即基于实例和任务的hash值做匹配。例如，每个实例有标识ID，每个任务有任务标识ID，可以对各实例标识ID进行哈希计算得到哈希值，对各任务标识进行哈希计算得到哈希值，当任务需要与实例进行匹配时，会将任务的哈希值与所有实例的哈希值进行比较，如果找到匹配的哈希值，就说明这个任务应该部署在这个实例上。
最小化策略LeastStrategy，即本次调度的过程与前一轮调度结果相关，保证已经调度好的任务不再重新调度，仅对未调度的新任务做调度。
由上述实施例可见，本实施例在业务系统中实现了基于消息队列系统的调度功能，主节点可以基于设定策略进行调度，以数据采集场景为例，相对于相关技术中未有调度策略、直接让每个数据源的数据采集任务在每个实例中运行的方案，本实施例中由主节点利用调度策略对数据采集任务进行调度和分配，而并非是在每个数据采集任务都在每个实例中都运行，因此可以减少实例中运行的某个数据采集任务空跑的情况，尽量避免实例中的资源浪费。
本实施例中，实例集群是非中心化的，任何一个运行着的实例，都可以作为主节点来执行调度逻辑。其中，主节点是指在某一次集群中实例发现变化或调度体中调度体发生变化后执行调度的实例，如果同时多个节点都执行调度逻辑，不但浪费有限的资源，同时也会引起调度的混乱；因为每个节点执行调度的时间不一样，集群所处的状态也不一样，这样就会造成运行实例在同一时间内所收到的调度名单也不一样，引发脑裂问题。因此，本实施例需要保证在一段时间内，只有一个实例来执行调度逻辑。基于此，每一次发生变化后，每个实例可以确定自身是否为主节点。选主机制可以有多种实现方式。
例如，可以是以主节点尽量少变动的方式实现。例如，实例集群首次启动，此时可能有一台实例最先启动，或者可能同时有两台实例启动，此时还未有主节点，实例可以基于设定选主策略确定自身是否为主节点。例如，选主策略可以根据需要灵活配置，例如可以基于实例的Consumer ID来确定，例如Consumer ID最大或最小等多种方式，只要能唯一确定出一台实例作为主节点即可。此时产生了主节点。后续的，实例集群中还有其他实例也会启动，只要作为主节点的实例未下线，该主节点可以一直作为主节点；实现上也有多种方式，例如可以通过数据库锁的方式实现，主节点持有数据库中某份数据的锁，在主节点未下线的情况下，主节点一直持有锁，而其他实例则未能持有锁，因此保证该实例可持续作为主节点。实际应用中也可以采用其他方式，例如可以是每次有新实例上线或下线，则触发一次选主，例如可以每次都采用相同或不同的选主策略来选择主节点。例如采用上述Consumer ID来选主。或者，还可以采用轮流的方式，实例集群中各台实例按照设定周期轮流作为主节点等。本实施例对此不进行限定。如此，由主节点执行统一调度，可以解决调度的脑裂问题。
在一些例子中，所述利用设定调度策略，将当前调度体集合中各调度体调度至当前实例集群中的一个或多个目标实例中进行处理，包括：
利用设定调度策略，根据当前调度体集合和当前实例集群生成调度名单；其中，所述调度名单中包括目标实例以及为所述目标实例分配的调度体；
将所述调度名单提供给各所述目标实例，以使所述目标实例根据所述调度名单，处理为其分配的调度体；
或，
所述获取主节点分配的调度体并处理，包括：
接收所述主节点发送的调度名单，根据所述调度名单获取自身被分配的调度体并处理；其中，所述调度名单中包括目标实例以及为所述目标实例分配的调度体；所述调度名单是所述主节点利用设定调度策略，根据当前调度体集合和当前实例集群生成的。
本实施例中，主节点执行统一调度，可以生成根据当前调度体集合和当前实例集群生成调度名单，调度名单中可以包括各个需要执行调度的目标实例的标识，以及为每个目标实例分配的调度体。每个目标实例接收到该份调度名单后，可以查看名单，看自身是否需要进行调度体的调整。
考虑到，实例集群中各个运行实例在收到调度名单后，就开始执行自己的逻辑，下线已经运行的不在名单上的调度体，上线名单上新的调度体。而各个运行实例彼此独立，相互不影响；这就会造成，在某一时间点，已经运行在实例A上的调度体a，还没有停止，而实例B接收到新调度名单后，已经将名单中的a在实例B上启动了；此时a同时运行在了实例A和实例B两个实例上，会引发数据重复问题。基于此，在一些例子中，在所述将所述调度名单提供给各所述目标实例，以使所述目标实例根据所述调度名单，处理为其分配的调度体的步骤后，所述方法还包括：
向每个所述目标实例发送停止指令，以使每个所述目标实例在接收到所述停止指令后，根据所述调度名单下线需停止的任务，并在下线完成后向所述主节点发送下线完成消息；
接收到所有目标实例发送的下线完成消息后，向各个目标实例发送启动指令，以使各个目标实例在接收到所述启动指令后，根据调度名单处理新的调度体；
或，
在所述接收所述主节点发送的调度名单，根据所述调度名单获取自身被分配的调度体并处理的步骤后，所述方法还包括：
接收到所述主节点发送的停止指令后，根据所述调度名单下线需停止的调度体，并在下线完成后向所述主节点发送下线完成消息；
接收到所述主节点发送的启动指令后，根据调度名单处理新的调度体；其中，所述启动指令是所述主节点在接收到所有目标实例发送的下线完成消息后发送的。
如图2C所示，是本说明书根据一示例性实施例示出的消息发送示意图，解决的办法就是在实例A没有停止a之前，实例B不允许启动a，保障启动和停止的有序；本实施例通过消息队列的消息来实现。主节点完成调度列表后，不仅会发送一条包含调度列表的消息给其他节点，还需要发送指令；首先发送stop(停止)指令，集群各个节点在收到该指令后，先将不在新调度列表的任务下线，之后发送向所述主节点发送下线完成消息。主节点接收到所有目标实例发送的下线完成消息后，向各个目标实例发送启动指令，以使各个目标实例在接收到所述启动指令后，根据调度名单处理新的任务。如此，任务先下线再启动，保证同一时刻不会出现两个相同任务采集两个相同数据，防止数据重复问题。
其中，主节点和其他节点之间的通信方式可以有多种方式。
在一些例子中，所述在下线完成后向所述主节点发送下线完成消息，包括：
将自身标识和下线完成消息写入至数据库中的指定存储位置；
所述接收到所有目标实例发送的下线完成消息，包括：
访问所述指定存储位置，若所述指定存储位置写入有各目标实例均写入自身标识和下线完成消息，确定接收到所有目标实例发送的下线完成消息。
本实施例中，各从节点会向主节点发送下线完成消息/上线完成消息，可以采用数据库的方式实现。如图2C所示的，从节点在下线完成后，在数据库中记录自己的状态为stopped(停止)状态，该stopped状态即表示下线完成完成，然后就等待start(开始)指令的到来；主节点在发送stop指令后，重复检查数据库，判断所有节点的状态是否都已是stopped(停止)状态。如果检查通过，则才会向集群发送start指令；各个节点在接收到start指令后，开始启动出现在调度列表的新任务，然后将自己的状态置为started(开始)状态；基于此完成一次调度。如此，通过在数据库中写入状态，可以令主节点快速地检查各从节点的下线或上线状态。
在一些例子中，所述主节点用于通过所述第二消息队列向各其他实例发布消息，各个实例用于订阅所述第二消息队列；所述第二消息队列是所述实例集群启动后首个主节点创建的；
所述向每个所述目标实例发送停止指令，包括：向所述第二消息队列发布表示停止指令的消息；
所述向各个目标实例发送启动指令，包括：向所述第二消息队列发布表示启动指令的消息。
本实施例中，实例集群启动后首个主节点可以创建消息队列，本实施例的消息队列message_topic，该消息队列用于节点之间的通信，其中，该消息队列在消息队列系统中的名称可以采用前述创建vote_topic时的ConsumerGroup的名称。主节点生成调度列表后，通过与ConsumerGroup同名的message_topic向集群发送启动、停止的指令，集群中其他节点在收到指令后，可以执行任务的启停动作，完成本轮的调度。
如图2D所示，图中示出了实例集群中的3个实例，每个实例中均可以实现前述的调度流程，底层则示出了消息队列系统的支持，其中示出了消息队列vote_topic，以及defaultGroup，根据需要还可以包括其他消息队列。
vote_topic下，包括3个v_consumer，即图中的v_consumer1、v_consumer2、v_consumer3，分别对应3个实例。
其中，defaultGroup用于实现节点之间的通信，每个实例可作为该defaultGroup的生产者或消费者，如图中示出的m_producer和m_consumer。图中以实例1作为主节点为例，其可以向defaultGroup中发送star指令或stop指令；而实例2和实例3作为从节点，则作为m_consumer，从defaultGroup中消费消息，即从defaultGroup中接收start指令或stop指令。
本实施例的调度引擎可以用于对多个任务在集群的调度的场景中；进一步的，也可以应用在一个任务中对多个分片的调度，统一的调度方式，用户无需关注内部的实现。
对于数据分片的调度，此时调度体是数据分配，实例是数据采集任务；基于此，可以实现对数据分片的调度。实际应用中，也可以考虑采用利用消息队列系统如RocketMQ实现分布式调度。例如，可以利用RocketMQ自身对于分片的调度；RocketMQ会根据topic的分片数目，以及Consumer的个数，自动的将分片均衡的分配在不同的客户端上，如果能将需要调度的任务映射到一个topic的分片上，将运行实例映射到客户端上，就可以利用RocketMQ自身的调度了；但是这个方案也会有一些问题：RocketMQ本身的方案，是分片对应Consumer；
1.为了实现调度的任务与RocketMQ中topic分片的映射，就需要动态的创建topic以及分片，这样频繁的操作会对RocketMQ的稳定性产生重大的影响；同时还需要记录调度任务与topic的映射关系，增加额外的工作量；
2.调度的策略完全取决于RocketMQ自身配置的调度策略，不能灵活定义，无法满足SIEM系统复杂多变的调度场景。
基于此，本实施例中，除了将数据采集任务调度至主机上运行的调度之外，本实施例的调度还可以包括将数据源的一个或多个数据分片，调度至任务集群中的至少一个任务中，也即是调度体是数据分片，实例是数据采集任务。可选的，数据分片至数据采集任务的调度，可以是在数据采集任务调度至目标实例后执行，通过获取数据源的至少一个数据分片，将各所述数据分片调度至所述数据源的至少一个数据采集任务中。
本实施例中，数据的分片可以有多种方式，例如可以是由用户对数据源配置分片数量，也可以是业务系统自动对数据源动态创建分片，例如数据源中数据量满足条件后，自动增加分片数量。对于离线数据，可以是业务系统对一份数据进行分片。
本实施例中，主节点针对一个数据源的数据采集任务，以及集群中的m个实例，需要根据调度策略确定该数据采集任务要运行在集群中n个实例上，其中n≤m。如此，一个数据源会有n个数据采集任务。在此，进一步嵌套了调度：数据源会有k个分片，主节点还可以执行对k个分片调度至n个数据采集任务的调度。
由上述实施例可见，基于消息队列系统的特性，将运行实例与Consumer做映射，而调度任务自行管理，通过消息队列系统检测任务和运行实例的变化，通过自定义的调度策略，完成调度；其优势在于：
可以摒弃前述通过数据库锁实现的方案，而采用消息度列系统，性能及稳定性有更好的保障；不采用RocketMQ自身的调度方案，将topic的分片与调度任务映射，而是采用本实施例的调度方案，这样在增加数据采集任务时，可以不用去动态创建topic的分片；同时多组调度可以采用同一个topic的不同消费组来实现，而不需要创建不同的topic，扩展性更强。
如图2E所示，其示出了本实施例方法的一种产品形态，底层是消息队列系统，结合图2B可知，该消息队列系统中包括服务端，即NameServer和Broker。服务端中实现有NameServer管理功能和Broker管理功能，分别管理一个或多个NameServer和Broker。每个NameServer可以还可以管理多个Broker，如图中示出的NameServer1管理Broker-1至Broker-4。调度引擎依赖于消息队列系统，调度引擎中包括选主功能、注册功能、调度功能(其中可以自定义多种调度策略)，以及消息控制功能。在整个调度引擎的上层，提供了调度功能的SDK(Software development kit，软件开发工具包)，方便用户的使用。通过SDK，可以实现任何场景下的调度。
采用本实施例的调度方案后，调度引擎会为每个任务分配运行实例，例如，当前86个采集任务被均衡的分布在整个集群中，每个实例上任务个数不超10个，CPU占用率不超过40％；且随着任务的增多，可以动态的扩展运行实例来提升系统的采集能力。
对于离线数据(DB或者OpenAPI)的采集，关键在于数据的切分以及分片的调度，如果调度有问题，就会出现数据丢失或者数据重复，给业务造成很大的影响；目前SIEM采集任务中，超过一半(44个)的任务都是基于通过其他产品提供的OpenAPI进行数据采集的，大大降低了SIEM的接入难度，为后续SIEM与第三方云数据的打通提供了基础。同时，也帮助开源轻量级实时框架Rocketmq Streams实现了流批一体的能力。
与前述基于消息队列系统的调度方法的实施例相对应，本说明书还提供了基于消息队列系统的调度装置及其所应用的终端的实施例。
本说明书基于消息队列系统的调度装置的实施例可以应用在计算机设备上，例如服务器或终端设备。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图3所示，为本说明书基于消息队列系统的调度装置所在计算机设备的一种硬件结构图，除了图3所示的处理器310、内存330、网络接口320、以及非易失性存储器340之外，实施例中基于消息队列系统的调度装置331所在的计算机设备，通常根据该计算机设备的实际功能，还可以包括其他硬件，对此不再赘述。
如图4所示，图4是本说明书根据一示例性实施例示出的一种基于消息队列系统的调度装置的框图，所述消息队列系统包括消息队列、消费者、以及管理消息队列和所述消费者的服务端；
所述装置用于将调度体集合中调度体调度给实例集群中的实例进行处理；所述装置应用于所述实例中，所述实例集群中的实例启动后注册为同一消息队列的消费者，所述装置包括：
发现模块41，用于：通过所述服务端确定实例集群中实例是否发生变化，以及确定调度体集合中调度体是否发生变化；
选主模块42，用于：若所述实例集群中发生实例变化或所述调度体集合中发生任务变化，确定自身是否为主节点；
调度模块43，用于：若自身为主节点，利用设定调度策略，将当前调度体集合中各调度体调度至当前实例集群中的一个或多个目标实例中运行；
处理模块，用于：若确定自身不是主节点，获取主节点分配的调度体并处理。
在一些例子中，所述消费者向所述服务端发送心跳消息，所述服务端用于根据各消息者的心跳信息，获取消费者列表并发送给各消费者；
所述发现模块，还用于：
从所述服务端获取消费者列表，根据所述消费者列表确定实例集群中实例是否发生变化。
在一些例子中，每个所述实例在启动后注册为第一消息队列的消费者，以使所述服务端获取消费第一消息队列的消费者列表；其中，所述第一消息队列是所述实例集群启动后首个主节点创建的。
在一些例子中，所述调度模块，还用于：
利用设定调度策略，根据当前调度体集合和当前实例集群生成调度名单；其中，所述调度名单中包括目标实例以及为所述目标实例分配的调度体；
将所述调度名单提供给各所述目标实例，以使所述目标实例根据所述调度名单，处理为其分配的调度体；
或，
所述处理模块，还用于：
接收所述主节点发送的调度名单，根据所述调度名单获取自身被分配的调度体并处理；其中，所述调度名单中包括目标实例以及为所述目标实例分配的调度体；所述调度名单是所述主节点利用设定调度策略，根据当前调度体集合和当前实例集群生成的。
在一些例子中，所述调度模块，还用于：
向每个所述目标实例发送停止指令，以使每个所述目标实例在接收到所述停止指令后，根据所述调度名单下线需停止的调度体，并在下线完成后向所述主节点发送下线完成消息；
接收到所有目标实例发送的下线完成消息后，向各个目标实例发送启动指令，以使各个目标实例在接收到所述启动指令后，根据调度名单处理新的调度体；
或，
所述处理模块，还用于：
接收到所述主节点发送的停止指令后，根据所述调度名单下线需停止的调度体，并在下线完成后向所述主节点发送下线完成消息；
接收到所述主节点发送的启动指令后，根据调度名单处理新的调度体；其中，所述启动指令是所述主节点在接收到所有目标实例发送的下线完成消息后发送的。
在一些例子中，所述主节点用于通过所述第二消息队列向各其他实例发布消息，各个实例用于订阅所述第二消息队列；所述第二消息队列是所述实例集群启动后首个主节点创建的；
所述调度模块，还用于：向所述第二消息队列发布表示停止指令的消息；向所述第二消息队列发布表示启动指令的消息。
在一些例子中，所述处理模块还用于：
将自身标识和下线完成消息写入至数据库中的指定存储位置；
所述调度模块还用于：
访问所述指定存储位置，若所述指定存储位置写入有各目标实例均写入自身标识和下线完成消息，确定接收到所有目标实例发送的下线完成消息。
在一些例子中，所述选主模块，还用于：根据当前实例集群中各实例的信息，利用设定选主策略确定自身是否为主节点。
上述基于消息队列系统的调度装置中各个模块的功能和作用的实现过程具体详见上述基于消息队列系统的调度方法中对应步骤的实现过程，在此不再赘述。
相应的，本说明书实施例还提供了一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现前述基于消息队列系统的调度方法实施例的步骤。
相应的，本说明书实施例还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现基于消息队列系统的调度方法实施例的步骤。
相应的，本说明书实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现基于消息队列系统的调度方法实施例的步骤。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
上述实施例可以应用于一个或者多个计算机设备中，所述计算机设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，所述计算机设备的硬件包括但不限于微处理器、专用集成电路(Application Specific IntegratedCircuit，ASIC)、可编程门阵列(Field-Programmable Gate Array，FPGA)、数字处理器(Digital Signal Processor，DSP)、嵌入式设备等。
所述计算机设备可以是任何一种可与用户进行人机交互的电子产品，例如，个人计算机、平板电脑、智能手机、个人数字助理(Personal Digital Assistant，PDA)、游戏机、交互式网络电视(Internet Protocol Television，IPTV)、智能式穿戴式设备等。
所述计算机设备还可以包括网络设备和/或用户设备。其中，所述网络设备包括，但不限于单个网络服务器、多个网络服务器组成的服务器组或基于云计算(CloudComputing)的由大量主机或网络服务器构成的云。
所述计算机设备所处的网络包括但不限于互联网、广域网、城域网、局域网、虚拟专用网络(Virtual Private Network，VPN)等。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该申请的保护范围内。
其中，“具体示例”、或“一些示例”等的描述意指结合所述实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。
应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。
以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。

Claims (11)

1.一种基于消息队列系统的调度方法，所述消息队列系统包括消息队列、消费者、以及管理所述消息队列和所述消费者的服务端；
所述方法用于将调度体集合中调度体调度给实例集群中的实例进行处理；所述方法应用于所述实例中，所述实例集群中的实例启动后在所述服务端注册为同一消息队列的消费者，所述方法包括：
通过所述服务端确定实例集群中实例是否发生变化，以及确定调度体集合中调度体是否发生变化；
若所述实例集群中发生实例变化或所述调度体集合中发生任务变化，确定自身是否为主节点；
若自身为主节点，利用设定调度策略，将当前调度体集合中各调度体调度至当前实例集群中的一个或多个目标实例中运行；或，若确定自身不是主节点，获取主节点分配的调度体并处理。
2.根据权利要求1所述的方法，所述消费者向所述服务端发送心跳消息，所述服务端用于根据各消息者的心跳信息，获取消费者列表并发送给各消费者；
所述通过所述服务端获取实例集群中实例是否发生变化，包括：
从所述服务端获取消费者列表，根据所述消费者列表确定实例集群中实例是否发生变化。
3.根据权利要求2所述的方法，每个所述实例在启动后注册为第一消息队列的消费者，以使所述服务端获取消费第一消息队列的消费者列表；其中，所述第一消息队列是所述实例集群启动后首个主节点创建的。
4.根据权利要求1所述的方法，所述利用设定调度策略，将当前调度体集合中各调度体调度至当前实例集群中的一个或多个目标实例中进行处理，包括：
利用设定调度策略，根据当前调度体集合和当前实例集群生成调度名单；其中，所述调度名单中包括目标实例以及为所述目标实例分配的调度体；
将所述调度名单提供给各所述目标实例，以使所述目标实例根据所述调度名单，处理为其分配的调度体；
或，
所述获取主节点分配的调度体并处理，包括：
接收所述主节点发送的调度名单，根据所述调度名单获取自身被分配的调度体并处理；其中，所述调度名单中包括目标实例以及为所述目标实例分配的调度体；所述调度名单是所述主节点利用设定调度策略，根据当前调度体集合和当前实例集群生成的。
5.根据权利要求4所述的方法，在所述将所述调度名单提供给各所述目标实例的步骤后，所述方法还包括：
向每个所述目标实例发送停止指令，以使每个所述目标实例在接收到所述停止指令后，根据所述调度名单下线需停止的调度体，并在下线完成后向所述主节点发送下线完成消息；
接收到所有目标实例发送的下线完成消息后，向各个目标实例发送启动指令，以使各个目标实例在接收到所述启动指令后，根据调度名单处理新的调度体；
或，
在所述接收所述主节点发送的调度名单，根据所述调度名单获取自身被分配的调度体并处理的步骤后，所述方法还包括：
接收到所述主节点发送的停止指令后，根据所述调度名单下线需停止的调度体，并在下线完成后向所述主节点发送下线完成消息；
接收到所述主节点发送的启动指令后，根据调度名单处理新的调度体；其中，所述启动指令是所述主节点在接收到所有目标实例发送的下线完成消息后发送的。
6.根据权利要求5所述的方法，所述主节点用于通过第二消息队列向各其他实例发布消息，各个实例用于订阅所述第二消息队列；所述第二消息队列是所述实例集群启动后首个主节点创建的；
所述向每个所述目标实例发送停止指令，包括：向所述第二消息队列发布表示停止指令的消息；
所述向各个目标实例发送启动指令，包括：向所述第二消息队列发布表示启动指令的消息。
7.根据权利要求5所述的方法，所述在下线完成后向所述主节点发送下线完成消息，包括：
将自身标识和下线完成消息写入至数据库中的指定存储位置；
所述接收到所有目标实例发送的下线完成消息，包括：
访问所述指定存储位置，若所述指定存储位置写入有各目标实例均写入自身标识和下线完成消息，确定接收到所有目标实例发送的下线完成消息。
8.根据权利要求1所述的方法，所述确定自身是否为主节点，包括：
根据当前实例集群中各实例的信息，利用设定选主策略确定自身是否为主节点。
9.一种基于消息队列系统的调度装置，所述消息队列系统包括消息队列、消费者、以及管理所述消息队列和所述消费者的服务端；
所述装置用于将调度体集合中调度体调度给实例集群中的实例进行处理；所述装置应用于所述实例中，所述实例集群中的实例启动后注册为同一消息队列的消费者，所述装置包括：
发现模块，用于：通过所述服务端确定实例集群中实例是否发生变化，以及确定调度体集合中调度体是否发生变化；
选主模块，用于：若所述实例集群中发生实例变化或所述调度体集合中发生任务变化，确定自身是否为主节点；
调度模块，用于：若自身为主节点，利用设定调度策略，将当前调度体集合中各调度体调度至当前实例集群中的一个或多个目标实例中运行；或，若确定自身不是主节点，获取主节点分配的调度体并处理。
10.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现权利要求1至8任一所述方法的步骤。
11.一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1至8任一所述方法的步骤。
CN202310707397.7A 2023-06-14 2023-06-14 基于消息队列系统的调度方法、装置、设备及存储介质 Pending CN116860406A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310707397.7A CN116860406A (zh) 2023-06-14 2023-06-14 基于消息队列系统的调度方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310707397.7A CN116860406A (zh) 2023-06-14 2023-06-14 基于消息队列系统的调度方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
CN116860406A true CN116860406A (zh) 2023-10-10

Family

ID=88229506

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310707397.7A Pending CN116860406A (zh) 2023-06-14 2023-06-14 基于消息队列系统的调度方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN116860406A (zh)

Similar Documents

Publication Publication Date Title
US10083048B2 (en) System and method for fully configurable real time processing
US20190377604A1 (en) Scalable function as a service platform
CN104618693B (zh) 一种基于云计算的监控视频在线处理任务管理方法及系统
US8856801B2 (en) Techniques for executing normally interruptible threads in a non-preemptive manner
JP5988621B2 (ja) 高負荷のビジネスプロセスのスケーラビリティ
US8584136B2 (en) Context-aware request dispatching in clustered environments
US7861246B2 (en) Job-centric scheduling in a grid environment
CN109075988B (zh) 任务调度和资源发放系统和方法
CN109803018A (zh) 一种基于Mesos和YARN结合的DCOS云管理平台
US10754702B2 (en) Technique for reconfiguring a virtual machine
Stuedi et al. Darpc: Data center rpc
US20170024251A1 (en) Scheduling method and apparatus for distributed computing system
CN109564528B (zh) 分布式计算中计算资源分配的系统和方法
Wang et al. Pigeon: An effective distributed, hierarchical datacenter job scheduler
US20180176070A1 (en) System and method to handle events using historical data in serverless systems
CN108833462A (zh) 一种面向微服务的自注册服务发现的系统及方法
Heidari et al. Qos assurance with light virtualization-a survey
CN114138434B (zh) 一种大数据任务调度系统
US11656902B2 (en) Distributed container image construction scheduling system and method
US11861406B2 (en) Dynamic microservices allocation mechanism
US10715472B2 (en) System and method for unit-of-order routing
CN114448983A (zh) 基于ZooKeeper的分布式数据交换方法
Zheng et al. A multi-tenant framework for cloud container services
Jayaram et al. Lambda FL: Serverless aggregation for federated learning
CN116860406A (zh) 基于消息队列系统的调度方法、装置、设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination