Distributed task scheduling engine 1 + N cluster control and transverse capacity expansion system and device

Abstract

The invention provides a distributed task scheduling engine 1 + N cluster control and transverse expansion system and device, and the system comprises a scheduling platform based on a non-main architecture, all scheduling services have the same weight, and the linear expansion of the scheduling capability is supported by transversely increasing scheduling nodes; the scheduling resource quantification module is used for carrying out granularity calculation and statistics on the triggering frequency of the CRON fixed-period task; the scheduling unit packaging module is used for packaging the scheduling resources which cannot be divided into independent scheduling units; a sidecar mode governance service is provided, low-coupling federated cluster management and control capability is provided, and second-level access and non-intrusive resource management of newly-added cluster resources are supported; the dynamic elastic contraction module is used for adjusting the number and the scale of scheduling units in real time according to the change of the business volume, and realizing non-inductive resource capacity expansion or capacity contraction of a user through a service discovery mechanism; and the multi-tenant isolation module is used for physically isolating the scheduling resources based on the service granularity and dynamically integrating a plurality of scheduling units through the scheduling group.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of distributed task scheduling, in particular to a distributed task scheduling engine 1+N cluster management and control and horizontal expansion system and device. BACKGROUND

[0002] XXL-JOB is a distributed task scheduling project open sourced by Dianping, using a centralized architecture, based on scheduling center DB lock to ensure the consistency of distributed scheduling. Quartz is used as a periodic trigger engine, and tasks are broadcasted and sharded by executors. Dynamic expansion of executor clusters is supported to dynamically increase the number of shards, and business processing is coordinated; when performing large data volume business operations, the task processing capacity and speed can be significantly improved.

[0003] However, in terms of isolation of the task scheduling platform and dynamic expansion ability of the scheduling resources, XXL-JOB still has obvious bottlenecks under large volume of business and high concurrency pressure. First, the centralized architecture needs to ensure consistency through a lock mechanism, which will directly limit the scheduling throughput capacity, second, due to the limitations of the Quartz service, the periodic scheduling carrying capacity cannot be expanded horizontally, in addition, if the scheduling pressure continues to surge, once a scheduling service is abnormal, it will cause a snowball service downtime, causing serious impact on the entire business, and the impact of part of the business cannot be isolated within a controllable range.

[0004] Patent application document CN119759594A discloses a cloud-native heterogeneous task-oriented distributed task scheduling method and system, including a user submitting a task through a task management module, the task being accompanied by description information, the system acquiring the hardware status and task load information of all nodes in the cluster in real time through a resource monitoring module, the scheduling optimization module analyzing the task characteristics according to the task type and selecting the optimal scheduling strategy in combination with the current resource state, the task distribution module distributing the task to the best computing node and starting task execution, and the system continuously monitoring the task state during task execution and dynamically adjusting resource allocation or performing preemptive scheduling when necessary. However, this patent cannot completely solve the existing technical problems and cannot meet the needs of the present application. SUMMARY

[0005] In view of the defects in the prior art, the present application aims to provide a distributed task scheduling engine 1+N cluster management and control and horizontal expansion system and device.

[0006] The distributed task scheduling engine 1+N cluster management and control and horizontal expansion system according to the present application comprises:

[0007] Based on a masterless scheduling platform, all scheduling services have the same weight, and support linear expansion of scheduling capabilities by adding scheduling nodes horizontally;

[0008] The scheduling resource quantification module is used to perform granular calculation and statistics on the trigger frequency of CRON periodic tasks, generate quantitative data, and divide the trigger intervals into high frequency, medium frequency, low frequency, and zero frequency according to preset thresholds;

[0009] The scheduling unit encapsulation module encapsulates indivisible scheduling resources into independent scheduling units. The scheduling units include metadata storage resources, concurrency control resources, and CRON resources, and implement dynamic registration and governance based on the service registration mechanism.

[0010] The sidecar governance service is independently deployed outside the scheduling cluster, providing loosely coupled federated cluster management capabilities, supporting the integration of new cluster resources within seconds, and non-intrusive resource management.

[0011] The dynamic scaling module adjusts the number and scale of scheduling units in real time based on changes in business volume, and uses a service discovery mechanism to achieve user-imperceptible resource expansion or contraction.

[0012] The multi-tenant isolation module physically isolates scheduling resources based on business granularity and dynamically integrates multiple scheduling units through scheduling groups to ensure that the impact range in abnormal situations can be controlled.

[0013] Preferably, the scheduling resource quantization module includes:

[0014] A parameter configuration unit for dynamically adjusting system-level quantitative parameters, including physical upper limit, attenuation factor, high-frequency threshold, intermediate-frequency threshold, high-frequency ratio limit, and intermediate-frequency ratio limit;

[0015] The data structure storage unit stores the number of task triggers based on the time dimension, including the number of triggers at minute granularity, the number of triggers at hour granularity, and the number of triggers at year granularity;

[0016] The visualization unit displays the real-time proportion of tasks in different frequency bands through a Nightingale rose diagram, and dynamically monitors the minute-level task triggering frequency through a bar chart.

[0017] Preferably, the attenuation factor is used to calculate the dynamic attenuation value of the scheduling capability, and the specific formula is: attenuation carrying value = physical upper limit × (1-attenuation factor), and the control interval of the task trigger frequency band is divided by the high-frequency threshold and the medium-frequency threshold.

[0018] Preferably, the sidecar model governance service includes:

[0019] The service registration center is used to automatically detect the registration information of newly added scheduling units or computing nodes;

[0020] a routing management module encapsulating scheduling details and realizing dynamic routing of requests through east-west traffic control;

[0021] a compatibility interface supporting original service requests to add scheduling group and scheduling unit information through headers to realize forward compatibility of service exposure.

[0022] Preferably, in the scheduling unit encapsulation module, the minimum unit of scheduling resources is determined based on the query performance, write performance and concurrency performance of the metadata engine, and high availability is improved through master-slave architecture and bypass cache mechanism.

[0023] Preferably, the dynamic scaling module comprises:

[0024] a resource abstraction layer separating scheduling resources from computing resources, wherein the computing resources are in the form of stateless nodes as the minimum unit;

[0025] an elastic policy engine automatically triggering scaling operations of scheduling units according to quantitative data and service load prediction results.

[0026] Preferably, the multi-tenant isolation module supports at least one of the following strategies:

[0027] physical isolation: allocating independent scheduling unit groups for different tenants;

[0028] logical isolation: limiting the resource occupation ratio of each tenant in the same scheduling unit group through resource quota;

[0029] priority isolation: dynamically allocating scheduling resources based on task priority.

[0030] Preferably, it further comprises:

[0031] an exception fusing module automatically fusing task distribution of a certain scheduling unit and triggering an alarm when the triggering frequency of the scheduling unit exceeds the product of the physical upper limit and the attenuation factor;

[0032] a self-healing module taking over abnormal tasks through redundant scheduling units and reallocating loads after resource recovery.

[0033] Preferably, the metadata storage layer of the scheduling platform adopts a sharding architecture to separate static metadata from dynamic history data and dynamically partition and store the history data based on the business volume.

[0034] The distributed task scheduling engine 1+N cluster management and control and horizontal expansion device provided by the application is applied to the distributed task scheduling engine 1+N cluster management and control and horizontal expansion system.

[0035] Compared with the prior art, the application has the following beneficial effects:

[0036] The present application realizes linear growth of consumption capacity in the range of maximum concurrent requests supported by the database through horizontally increasing machines based on the same weight of all scheduling services in the masterless architecture. In addition, the present application can realize horizontal expansion of scheduling resources following the business volume of users, and realize business isolation based on different business tenants. In the case of sudden abnormal conditions, the impact is isolated according to the business granularity, and the business of other users on the scheduling platform is not affected. BRIEF DESCRIPTION OF DRAWINGS

[0037] Other features, objects and advantages of the present application will become more apparent from the following detailed description of non-limiting embodiments, made with reference to the following drawings:

[0038] Figure 1 The scheduling platform cluster federalization governance architecture diagram and the comparison effect;

[0039] Figure 2 The CRON periodic task bearing capacity quantification system;

[0040] Figure 3 Quantitative data;

[0041] Figure 4 The monitoring pie chart;

[0042] Figure 5 The monitoring column chart;

[0043] Figure 6 The scheduling resource quantification architecture diagram. DETAILED DESCRIPTION

[0044] The present application will be described in detail below with specific embodiments. The following examples will help those skilled in the art to further understand the present application, but do not limit the present application in any form. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present application. These are within the scope of protection of the present application.

[0045] Embodiments

[0046] The present application provides a distributed task scheduling engine 1+N cluster management and control and horizontal expansion system, comprising:

[0047] A measurement model is designed to realize quantitative statistics of CRON periodic expression tasks. CRON is an expression tool for accurately describing the task trigger period. The specific implementation is based on the calculation of the CRON expression based on the current year in seconds, and then all CRON tasks carried by the current year scheduling platform are triggered according to the minute granularity. The current year is aggregated, and finally the periodic scheduling bearing capacity is quantified, such asFigure 2 .

[0048] Through the CRON periodic task quantification mechanism, the distributed scheduling platform realizes the quantification and visualization of its periodic triggering bearing capacity. Based on the previously statistical CRON triggering frequency, the aggregation results of periodic tasks of different frequencies are visualized according to the minute or hour and the open user-defined quantification threshold factor.

[0049] The existing scheduling platform supports user's dynamic expansion scheduling and computing resources from the perspective of resource management. Based on the distributed service discovery mechanism, the automatic registration function is realized in the scheduling computing service, the scheduling or computing resources are expanded horizontally, and the scheduling platform automatically senses and the user expands without feeling.

[0050] The specific process of horizontal expansion based on the distributed service discovery mechanism is as follows:

[0051] 1. Horizontal expansion trigger condition

[0052] Objective: Real-time monitoring of resource load, dynamically determining whether to expand.

[0053] Collect the CPU usage U of the scheduling service node CPU , memory usage U Mem , task queue backlog Q Task .

[0054] Calculate the comprehensive load L of the current node by the weighted formula current :

[0055]

[0056] Where, α+β+γ=1, Q Max is the maximum capacity of the queue.

[0057] If L current >0.8, trigger horizontal expansion.

[0058] 2. Automatic registration and service discovery process

[0059] Objective: New node automatically registers to the service registry center and is perceived by the scheduling platform.

[0060] When the new scheduling or computing node starts, send a registration request to the sidecar management service, including node type (scheduling / computing), resource capacity (such as maximum concurrent task number, CPU core number).

[0061] The sidecar management service writes the node information into the service registry center (such as Consul or Etcd), records the unique identifier (IP+Port) of the node, health status, and load weight.

[0062] Newly added nodes periodically send heartbeat packets to the service registry. If there is no response for 3 consecutive times, it is marked as unavailable.

[0063] 3. User-agnostic capacity expansion implementation

[0064] Objective: Automatically route business requests to new nodes without user intervention.

[0065] The service registry notifies the routing management module of the new node information, and the routing module updates the distribution strategy based on node load weight.

[0066] Load balancing algorithm: Weighted Round Robin or Least Connections.

[0067] After the health check, the newly added node gradually receives new task requests, and the old node continues to process the inventory tasks until load balancing.

[0068] Business requests access the scheduling platform through a unified gateway entry (such as API Gateway), and the gateway dynamically selects nodes based on the routing table, without the need for the client to perceive changes in the backend nodes.

[0069] 4. Estimation of the number of expanded nodes

[0070] Scenario: Current system load L current = 0.85, needs to be expanded to L target = 0.6.

[0071] Single node capacity: Assume the maximum concurrent task number of a single node is C unit = 1000.

[0072] Current total capacity: Existing node number N current = 5, total capacity C total = 5 × 1000 = 5000.

[0073] Target total capacity:

[0074]

[0075] Number of nodes to be added:

[0076]

[0077] 5. Fault tolerance and consistency guarantee

[0078] New scheduling nodes pull task configuration, CRON expression, and other metadata from the master node through the metadata synchronization service to ensure task state consistency.

[0079] Use distributed locks (such as ZooKeeper) to ensure atomicity of task distribution, avoid the same task being executed repeatedly by multiple nodes.

[0080] If the new node is abnormal, the governance service automatically marks it as offline, and cuts back the traffic to the healthy node through the routing table.

[0081] Based on the Side Car concept, existing cluster resources are managed without invasion, and new cluster resources are accessed in seconds. To the calling party, it still appears as a complete distributed scheduling cluster. Service routing and scheduling details are encapsulated inside the platform. The Side Car mode can be simply understood as system decoupling or pluggable capability. Through the Side Car mode scheduling platform, it can be deployed independently, or it can be horizontally expanded according to the specific business volume of users, and completely realize the horizontal expansion of the cluster without affecting the user.

[0082] The distributed scheduling platform implements multiple granularity isolation strategies, and the resource allocation can be dynamically optimized according to the user business volume. Based on encapsulating scheduling and computing resources into scheduling units according to a certain scale, combined with the implementation of the cluster federation governance service based on the Side Car mode, the scheduling platform can provide multiple isolation strategies and dynamic planning management according to business needs.

[0083] Based on the non-invasive dynamic governance mechanism, the resource horizontal and vertical dynamic governance of the super large distributed scheduling cluster is realized, and the original scheduling resource horizontal expansion bottleneck is broken. After the scheduling platform is encapsulated into a unit, it can be understood as the smallest unit of scheduling and computing capacity. This unit cannot be further divided. Therefore, when the business volume continues to rise, users can adjust the size of the scheduling unit to realize resource expansion. In addition, the number of scheduling units has no theoretical upper limit, so this design breaks the system-level limitation bottleneck.

[0084] Specific technical solutions:

[0085] As Figure 1 , the application provides a distributed task scheduling engine 1+N cluster management and control and horizontal expansion architecture method and system. The core purpose is to realize the dynamic governance of the distributed workflow scheduling and arrangement platform, and break the horizontal expansion bottleneck of the platform scheduling resource.

[0086] First, rely on the design of a quantitative model and the corresponding logical function to realize the measurement and visualization monitoring of the scheduling platform on the periodic trigger carrying capacity of the CRON expression.

[0087] The quantitative model design is based on the CRON expression. A set of quantitative parameter system is designed for the expression of periodic scheduling. The parameters are shown as follows:

[0088] CRON total limit: An integer value parameter designed to limit the total number of user-configurable periodic tasks.

[0089] Physical upper limit: An integer value parameter representing the maximum scheduling capacity of the scheduling system per minute, which is one of the important indicators of system performance.

[0090] Decay factor: A percentage parameter reflecting the decay of the scheduling system's scheduling capacity over time, which helps to more accurately assess the system's performance at different time periods.

[0091] High frequency threshold: An integer value parameter that defines high frequency triggers when the trigger frequency of a certain minute exceeds the parameter value but is lower than the physical upper limit multiplied by the decay factor. This parameter value is called the high frequency threshold.

[0092] High frequency ratio limit: A percentage parameter used to limit the number of high frequency triggered tasks.

[0093] Medium frequency threshold: An integer value parameter that defines medium frequency triggers when the trigger frequency of a certain minute is between the high frequency threshold and the parameter value. This parameter value is called the medium frequency threshold.

[0094] Medium frequency ratio limit: A percentage parameter used to limit the number of medium frequency triggered tasks.

[0095] The above parameters are all service system level configurations, which can be dynamically adjusted by the operation and maintenance personnel according to their own system situation. Through this set of quantitative parameter system, the quantitative process of CRON expression can be more accurately managed, ensuring efficient use of system resources and stable improvement of scheduling performance.

[0096] Measurement statistics need to have corresponding data structures for CRON expressions, which provide a theoretical basis for programmatic storage and calculation, so the specific data structures will be shown:

[0097] dayNum: Identifies the day of the year that the current hour belongs to.

[0098] hourNum: Identifies the hour of the year that the current hour belongs to.

[0099] year: Identifies the specific year that the task belongs to, ensuring the accuracy of the time dimension of the data.

[0100] month: Identifies the month that the task belongs to, which helps to perform statistical and analytical tasks by month.

[0101] day: Identifies the specific date that the task belongs to.

[0102] hour: Identifies the hour that the task belongs to, ensuring that the task can be monitored at the hour level.

[0103] hourGranularity: Records the total number of triggers for tasks belonging to the minutes within that hour.

[0104] minuteGranularityJson: This is a mapping structure that stores information at the minute level. Through it, you can quickly understand the number of task triggers per minute, achieving minute-level task execution monitoring.

[0105] For example, using the CRON expression 0,10 30,59 12 15 1?2025, the CRON parser will parse it and encapsulate the result into the designed granularity information data structure. The quantized data after parsing is as shown in Figure 3 This data structure not only makes it clearer and easier to understand, but also more effectively supports precise management and monitoring of task trigger frequency. Through it, you can better plan your task scheduling strategy to ensure stable operation of the system under high load. This design enables quick access to task trigger frequency information corresponding to the CRON expression, providing strong data support for subsequent scheduling and monitoring.

[0106] Visual monitoring uses a South African rose pie chart and a column chart to conduct in-depth monitoring and statistical analysis of quantized data, clearly displaying the data in chart form. The specific display methods are as follows:

[0107] The pie chart is mainly used to display the real-time usage of different frequency bands, including the actual usage ratio and specific usage amount. This display method can more intuitively monitor the current resource utilization of the system, quickly identify potential problems and bottlenecks. The following is a detailed display of the pie chart, providing a comprehensive view of system resource usage, as shown in Figure 4 .

[0108] The column chart is used to display the task trigger frequency at a certain minute, with different heights of columns intuitively reflecting the task scheduling load of each time period. This display method helps operations personnel quickly identify time points with abnormal task scheduling quantities, and then take appropriate measures to ensure stable operation of the system, as shown in Figure 5 .

[0109] Through the combined use of these two charts, you can more comprehensively understand the running state and resource usage of the system, providing strong data support for optimizing system performance and improving user experience.

[0110] Based on the CRON periodic scheduling carrying capacity quantization mechanism, non-divisible scheduling resources are encapsulated as scheduling resource units for resource management - referred to as scheduling units.

[0111] The scheduling resource quantization processing is started when a user starts a periodic scheduling task, the granularity information of the CRON expression is calculated, the scheduling resources in the cache are compared, and if the check rule is met, the user is successfully online. When the user logs out of the task, the corresponding value in the cache is subtracted.

[0112] The scheduling resource quantization architecture is as shown in Figure 6 The scheduling resource measurement judgment rule is as follows: for example, the upper limit of the system scheduling task quantity is 3500 times / minute, and the decay factor is 0.2, then the decay bearing value is: 3500 times / minute*(1-0.2)=2800 times / minute. Four levels are set for granularity: high frequency, medium frequency, low frequency and empty frequency, for example, the high frequency threshold is configured as 2000 times, and the medium frequency threshold is configured as 400 times. The frequency of 0 times per minute is empty frequency, the frequency of [0,400) times is low frequency interval, the frequency of [400,2000) times is medium frequency interval, the frequency of [2000,2800) times is high frequency interval, and the frequency greater than 2800 times / minute is not allowed. Low frequency and empty frequency are not limited, only the proportion of high frequency and medium frequency is controlled, and a certain proportion of high frequency and medium frequency can occur. For example, there are 527040 minutes in a year, if the number of high frequency overload allowed is: 527040*15%=79056 high frequency loads, the number of medium frequency overload allowed is: 527040*35%=184464 medium frequency loads, the number of low frequency overload allowed is: 527040*40%=210816 medium frequency loads, and the number of empty frequency is: 527040*10%=52704 empty frequency.

[0113] Based on the Side Car concept, the northbound service request control and the service registration center mechanism are combined to realize the independently deployable resource management control service, which has the centralized resource management capability of cluster federation.

[0114] Sidecar deployment mode: based on the Side Car concept, the 1+N cluster control design is independent of the periodic scheduling cluster deployment service, which provides a low-coupling multi-cluster federation solution. The distributed periodic scheduling engine can provide various solutions to dynamically meet the user's demand based on the user's business volume change.

[0115] Visual resource management: the cluster management architecture is designed based on the dynamic registration mode, so various resources are dynamically registered in a unitized way, and the visual management interface can be displayed in real time to provide real-time monitoring and management experience for users.

[0116] The existing distributed scheduling cluster has completely realized the horizontal and vertical dynamic management and supervision of resources. Finally, based on independent resource management and control services in the upper layer, centralized supervision and management of existing scheduling units is realized, complex underlying technical details are encapsulated, and the supervision and management of the entire life cycle of the exposed service is focused on. When the business rapidly expands, dynamic horizontal expansion of scheduling and computing resources is supported. The entire process of resource discovery, registration, and real-time scaling for users is already realized without user awareness. The distributed workflow scheduling and orchestration cluster realizes the entire resource quantification supervision and real-time dynamic scaling, which has a milestone significance.

[0117] Resource abstraction layering: based on distributed fixed-period scheduling engine resources, after abstraction, they are divided into two layers, namely scheduling resources and computing resources. The scheduling resources have a linear expansion bottleneck, so they need to be encapsulated as indivisible units for registration and management. The computing resources theoretically have no expansion bottleneck, so the computing resources continue to use nodes as indivisible units for registration and management.

[0118] Scheduling resource management: scheduling resources mainly include CRON resources, metadata storage resources, and metadata concurrency resources. They need to be considered comprehensively according to the query, write, and concurrency performance of the metadata engine, and combined with the master scheduling service to encapsulate into scheduling units.

[0119] Computing resource management: computing resources mainly focus on CPU, Memory, disk IO, and bandwidth resources of processing nodes. Because the computing task framework is designed in a stateless mode, the computing unit takes the node as the smallest unit, and through a dynamic registration mechanism, it realizes the federation management of the cluster.

[0120] According to the problems of scheduling cluster resource management and horizontal expansion encountered in actual production, the core technical difficulties are:

[0121] 1: The existing distributed scheduling cluster is limited by the three-party dependency bottleneck, which makes it impossible to horizontally expand

[0122] Based on technical analysis, if the third-party service source code is modified, the difficulty and cost are too high. The performance of any single-point service has a performance bottleneck. Therefore, based on the requirement of isolation ability and horizontal expansion ability of the cluster service, the existing architecture is selected for further evolution and upgrade to realize multi-level horizontal and vertical division management of resources. By fully utilizing the distributed idea, various divisible resources or services are split and re-encapsulated into independent units to establish a masterless management system to finally realize the dynamic scaling of various cluster resources.

[0123] 2: The business configuration expression CRON is too complex, and the corresponding scheduling carrying capacity cannot be quantitatively counted

[0124] Design to support a variety of time statistical units, aggregation statistics online task trigger frequency of fixed cycle scheduling, and based on the quantitative model to realize the quantitative and visual needs of the distributed scheduling platform for the trigger carrying capacity of the fixed cycle task.

[0125] 3: Fixed cycle scheduling framework Quartz cannot achieve horizontal expansion of trigger capacity

[0126] The open source Quartz framework is widely integrated in the industry as a support for high availability fixed cycle scheduling center, but the framework has the limitation of not being able to horizontally expand. Only the master node in multiple nodes can consume and process the tasks to be triggered, so based on the isolation and horizontal scalability requirements, Quartz is selected as a non-divisible unit and encapsulated as a scheduling resource for dynamic scaling management.

[0127] 4: The distributed scheduling platform cannot support the rapid growth of subsequent business volume due to the limitations of the early architecture design

[0128] The existing distributed scheduling platform based on the deep reconstruction of open source DolphinScheduler cannot support the business pressure of shares, groups and other daily million computing instances, as well as the foreseeable business volume growth requirements. Therefore, it is decided to further reconstruct and evolve the architecture level and iterate related technologies. The data storage layer and Dao layer are mainly split and reconstructed, and finally abstracted and encapsulated as metadata and history data for isolation management. Metadata is mainly static data cooperating with master-slave architecture and introducing bypass cache to ensure the performance and high availability of the overall cluster under high concurrency pressure of big data; history data belongs to scheduling resources and follows the change of business volume for dynamic scaling.

[0129] 5: How to improve the isolation capability while dynamically scaling the distributed scheduling platform resources

[0130] Scheduling resources need to support dynamic scaling in multi-tenant mode while supporting multiple isolation strategies. Through service architecture reconstruction and resource level segmentation and reorganization, all scheduling layer resources that cannot be divided are uniformly encapsulated as scheduling units. Through scheduling groups, multiple scheduling units are dynamically integrated into a whole to provide scheduling services. In the scheduling group, multiple tenants share scheduling resources, scheduling units are physically isolated, and independent governance services are used to achieve dynamic governance.

[0131] 6: How to realize the forward compatibility of service exposure after the distributed scheduling platform accepts non-master governance

[0132] The various service resources registered in the resource center are combined and dispatched according to the user's demand by the governance center service, and the dispatched resources provide services to the user according to the dispatch group. In the service exposure process, all dispatched resources will be registered in the governance center first, and then the request access will be routed and managed in the service east-west traffic management layer. All original business requests only need to add the corresponding dispatch group and dispatch unit information in the header, so as to conveniently realize the dynamic selection of the dispatched resources, without any other operation on the original service, and the Restful request path and interface parameter are unchanged, the upgrade cost is extremely low, and the distributed dispatch service can be deployed according to the dispatch unit mode.

[0133] Those skilled in the art know that, in addition to implementing the system, device and each module thereof provided by the present application in the form of pure computer readable program code, the same program can also be realized by logically programming the method steps in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded microcontrollers. Therefore, the system, device and each module thereof provided by the present application can be considered as a hardware component, and the modules included therein for realizing various programs can also be considered as structures in the hardware component; the modules for realizing various functions can also be considered as both software programs for realizing methods and structures in the hardware component.

[0134] The specific embodiments of the present application are described above. It should be understood that the present application is not limited to the specific embodiments described above, and various changes or modifications can be made by those skilled in the art within the scope of the claims, which does not affect the essential content of the present application. The embodiments of the present application and the features in the embodiments can be arbitrarily combined with each other without conflict.

Claims

1. A distributed task scheduling engine 1+N cluster management and horizontal expansion system, characterized by: include: Based on a masterless scheduling platform, all scheduling services have the same weight, and support linear expansion of scheduling capabilities by adding scheduling nodes horizontally; The scheduling resource quantification module is used to perform granular calculation and statistics on the trigger frequency of CRON periodic tasks, generate quantitative data, and divide the trigger intervals into high frequency, medium frequency, low frequency, and zero frequency according to preset thresholds; The scheduling unit encapsulation module encapsulates indivisible scheduling resources into independent scheduling units. The scheduling units include metadata storage resources, concurrency control resources, and CRON resources, and implement dynamic registration and governance based on the service registration mechanism. The sidecar governance service is independently deployed outside the scheduling cluster, providing loosely coupled federated cluster management capabilities, supporting the integration of new cluster resources within seconds, and non-intrusive resource management. The dynamic scaling module adjusts the number and scale of scheduling units in real time based on changes in business volume, and uses a service discovery mechanism to achieve user-imperceptible resource expansion or contraction. The multi-tenant isolation module physically isolates scheduling resources based on business granularity and dynamically integrates multiple scheduling units through scheduling groups to ensure that the impact range in abnormal situations can be controlled.

2. The distributed task scheduling engine 1+N cluster management and horizontal expansion system according to claim 1 is characterized in that: The scheduling resource quantization module includes: A parameter configuration unit for dynamically adjusting system-level quantitative parameters, including physical upper limit, attenuation factor, high-frequency threshold, intermediate-frequency threshold, high-frequency ratio limit, and intermediate-frequency ratio limit; The data structure storage unit stores the number of task triggers based on the time dimension, including the number of triggers at minute granularity, the number of triggers at hour granularity, and the number of triggers at year granularity; The visualization unit displays the real-time proportion of tasks in different frequency bands through a Nightingale rose diagram, and dynamically monitors the minute-level task triggering frequency through a bar chart.

3. The distributed task scheduling engine 1+N cluster management and horizontal expansion system according to claim 2 is characterized in that: The attenuation factor is used to calculate the dynamic attenuation value of the scheduling capacity. The specific formula is: attenuation carrying value = physical upper limit × (1-attenuation factor), and the control range of the task trigger frequency band is divided by the high-frequency threshold and the medium-frequency threshold.

4. The distributed task scheduling engine 1+N cluster management and horizontal expansion system according to claim 1, characterized in that: The sidecar model governance services include: The service registration center is used to automatically detect the registration information of newly added scheduling units or computing nodes; The routing management module encapsulates scheduling details and implements dynamic routing of requests through east-west traffic control; The compatibility interface supports adding scheduling group and scheduling unit information through the header of the original business request to achieve forward compatibility of service exposure.

5. The distributed task scheduling engine 1+N cluster management and horizontal expansion system according to claim 1 is characterized in that: In the scheduling unit encapsulation module, the minimum unit of scheduling resources is determined based on the query performance, write performance and concurrency performance of the metadata engine, and high availability is improved through the master-slave architecture and bypass cache mechanism.

6. The distributed task scheduling engine 1+N cluster management and horizontal expansion system according to claim 1, characterized in that: The dynamic elastic shrinkage module includes: The resource abstraction layer separates scheduling resources from computing resources, with computing resources taking stateless nodes as the smallest unit. The elastic policy engine automatically triggers the expansion and contraction operations of the scheduling unit based on quantitative data and business load forecast results.

7. The distributed task scheduling engine 1+N cluster management and horizontal expansion system according to claim 1, characterized in that: The multi-tenant isolation module supports at least one of the following strategies: Physical isolation: assigning independent scheduling unit groups to different tenants; Logical isolation: resource quotas are used to limit the resource usage ratio of each tenant in the same scheduling unit group; Priority isolation: Dynamically allocate scheduling resources based on task priority.

8. The distributed task scheduling engine 1+N cluster management and horizontal expansion system according to claim 1, characterized in that: Also includes: Abnormal fusing module: When the trigger frequency of a scheduling unit exceeds the product of the physical upper limit and the attenuation factor, the task distribution of the unit is automatically fused and an alarm is triggered; The self-healing module takes over abnormal tasks through redundant scheduling units and redistributes the load after resources are restored.

9. The distributed task scheduling engine 1+N cluster management and horizontal expansion system according to claim 1, characterized in that: The metadata storage layer of the scheduling platform adopts a database and table partitioning architecture to separate static metadata from dynamic historical data, and dynamically partitions and stores historical data based on business volume.

10. A distributed task scheduling engine 1+N cluster management and horizontal expansion device, characterized in that: A distributed task scheduling engine 1+N cluster management and horizontal expansion system according to any one of claims 1 to 9 is applied.

Images