CN116028544B - Timing task dynamic adding method based on OPENSTACK - Google Patents
Timing task dynamic adding method based on OPENSTACK Download PDFInfo
- Publication number
- CN116028544B CN116028544B CN202310322510.XA CN202310322510A CN116028544B CN 116028544 B CN116028544 B CN 116028544B CN 202310322510 A CN202310322510 A CN 202310322510A CN 116028544 B CN116028544 B CN 116028544B
- Authority
- CN
- China
- Prior art keywords
- task
- openstack
- timing
- component
- database
- 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.)
- Active
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a timing task dynamic adding method based on OPENSTACK, and relates to the field of cloud computing. The method of the invention constructs a timing Task dynamic adding architecture based on OPENSTACK, receives timing Task request data created by a user by using Task-API service and stores the timing Task request data in a DB database, and simultaneously calls a Celery method to trigger a Beat component; the task-schedule module in the Beat component loads task content according to the timed task request data, and simultaneously searches the DB database in a second level to reach task execution time, and sends the task to the MQ task queue of the Broker component; the workbench component monitors the MQ task queue in real time, and when the task exists, the workbench invokes and operates the resource data in the DB database to execute the task. The invention can realize flexible and dynamic addition of the timing task.
Description
Technical Field
The invention relates to the technical field of cloud computing, in particular to a timing task dynamic adding method based on OPENSTACK.
Background
OPENSTACK is a cloud management platform with open sources, and uses virtualization technology to virtualize resources such as storage, calculation and network, so as to form a resource pool, and dynamically provide calculation, storage and network resources for users. Currently, more and more enterprise users use open-source OPENSTACK to build private cloud, public cloud, hybrid cloud or industry cloud, however, open-source OPENSTACK does not support dynamic addition of timing tasks or single-period and multi-period timing tasks. There is therefore a need in the art for a unified method of adding internal timing tasks to OPENSTACK to meet the needs of enterprise users to set timing tasks.
Disclosure of Invention
Aiming at the problems in the background technology, the invention provides a timing task dynamic adding method based on OPENSTACK, so as to realize flexible dynamic adding of timing tasks.
In order to achieve the above object, the present invention provides the following solutions: the invention provides a timing task dynamic adding method based on OPENSTACK, which comprises the following steps: constructing a timing task dynamic adding framework based on OPENSTACK; the timing task dynamic adding architecture comprises an OPENSTACK, a DB database, a Beat component, a Broker component and a workbench component; OPENSTACK is communicatively coupled to the Beat component; OPENSTACK, beat component and Broker component are respectively connected with DB database in communication; the Broker component is respectively in communication connection with the Beat component and the workbench component; receiving timing Task request data created by a user through a Task-API service in an OPENSTACK custom timer component; the timed task request data includes: timing task name, task type, execution object resource information, execution cycle type, task execution time, notification event type, and notification mode; based on the timing Task dynamic adding architecture, the Task-API service stores timing Task request data into a DB database, and calls a Celery method to trigger a Beat component; the task-schedule module in the Beat component loads task content according to the timed task request data, and simultaneously searches the DB database in a second level to reach task execution time, and sends the task to the MQ task queue of the Broker component; the Worker component monitors the MQ task queue in real time, when the task exists in the MQ task queue, the Worker component retrieves and operates the resource data in the DB database to execute the task, and the execution result is saved in the DB database.
Optionally, the timed task request data is created by a user through page initiation.
Optionally, the task types include: cloud host startup, cloud host shutdown, cloud host restart, cloud host snapshot, and cloud host backup.
Optionally, the execution object resource information includes: the object name and ID are executed.
Optionally, the execution cycle type includes: single execution and periodic execution.
Optionally, the notification event types include: the execution failure notification, the execution success notification and the success failure notification.
Optionally, the notifying means includes: mail notification, short message notification, and telephone notification.
Optionally, the timing task request data further includes: task reservation policies; the task reservation policy comprises a task reservation rule and a reservation number.
Optionally, before the task-scheduler module in the bean component loads task content according to the timed task request data and retrieves the DB database in seconds, the task-scheduler module further includes: performing secondary development of timing tasks based on a Celery framework, modifying a Beat component in the Celery, using a database Scheduler class to rewrite the Scheduler class in the Beat component, and creating a task-Scheduler module; the task-schedule module comprises a schedule unit, an all_as_schedule unit, a create_or_update_task unit and a delete_task unit; the schedule unit is used for calling a Celery method to trigger a Beat component so as to call an all_as_schedule unit; the all_as_schedule unit is used for retrieving the DB database in the second level to inquire about tasks to be executed; the create_or_update_task unit is used for creating or updating a task, and dynamically adding or updating the task into the Celery; the delete_task unit is used for dynamically deleting tasks in Celery.
According to the specific embodiment provided by the invention, the invention discloses the following technical effects: according to the timing task dynamic adding method based on OPENSTACK, a timing task dynamic adding framework is built based on OPENSTACK; the timing task dynamic adding architecture comprises an OPENSTACK, a DB database, a Beat component, a Broker component and a workbench component; based on the timing Task dynamic adding architecture, task-API service in the OPENSTACK custom timer component can receive timing Task request data created by a user, store the timing Task request data into a DB database, and call a Celery method to trigger the Beat component; the task-schedule module in the Beat component loads task content according to the timed task request data, and simultaneously searches the DB database in a second level to reach task execution time, and sends the task to the MQ task queue of the Broker component; the Worker component monitors the MQ task queue in real time, when the task exists in the MQ task queue, the Worker component retrieves and operates the resource data in the DB database to execute the task, and the execution result is saved in the DB database. The invention provides a unified method for the timing task in the OPENSTACK, and can realize flexible and dynamic addition of the timing task.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings that are needed in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a flowchart of a timing task dynamic adding method based on OPENSTACK.
FIG. 2 is a schematic diagram of a timing task dynamic addition architecture constructed in accordance with the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
The invention aims to provide a timing task dynamic adding method based on OPENSTACK, so as to realize flexible dynamic adding of timing tasks.
In order that the above-recited objects, features and advantages of the present invention will become more readily apparent, a more particular description of the invention will be rendered by reference to the appended drawings and appended detailed description.
Fig. 1 is a flowchart of a timing task dynamic adding method based on OPENSTACK. Referring to fig. 1, a method for dynamically adding a timing task based on OPENSTACK includes the following steps 1 to 5.
Step 1: and constructing a timing task dynamic adding framework based on OPENSTACK.
As shown in FIG. 2, the timing Task dynamic addition architecture constructed based on OPENSTACK comprises OPENSTACK (providing Task-API service), a DB database, a Beat component, a Broker component and a workbench component. Wherein OPENSTACK is communicatively coupled to the Beat component; OPENSTACK, beat component and Broker component are respectively connected with DB database in communication; the Broker component is communicatively coupled to the bean component and the Worker component, respectively.
OPENSTACK is a cloud management platform with open sources, and uses virtualization technology to virtualize resources such as storage, calculation and network, so as to form a resource pool, and dynamically provide calculation, storage and network resources for users. The timing tasks refer to a series of tasks developed based on OPENSTACK and capable of being executed regularly, such as timing a cloud host, creating a cloud host backup, taking a snapshot of the cloud host, and the like; the timing tasks may be repeatedly performed at a specified cycle or may be performed only once.
Step 2: the user-created timed Task request data is received through the Task-API service in the OPENSTACK custom timer component.
The user initiates creation of timed task request data through a page, the timed task request data comprising: timing task name, task type, execution object resource information, execution cycle type, task execution time, notification event type, and notification manner. Wherein the task types may include: cloud host startup, cloud host shutdown, cloud host restart, cloud host snapshot, and cloud host backup. The execution object resource information includes: the object name and ID are executed. The execution cycle types include: single execution and periodic execution. The notification event types include: the execution failure notification, the execution success notification and the success failure notification. The notification method comprises the following steps: mail notification, short message notification, and telephone notification.
The timing task dynamic adding framework also supports policy reservation, namely, when the cloud host and the cloud hard disk automatic snapshot backup operation are executed, the policy, task execution time, number reservation rules and the like can be set. Thus, the timed task request data further comprises: task reservation policies; the task reservation policy comprises a task reservation rule and a reservation number.
The Task-API is a service used for receiving and processing user requests in the OPENSTACK custom timer component, and can call a packaged Celery method to trigger the Beat component while storing data in the DB database.
Step 3: based on the timing Task dynamic adding architecture, the Task-API service stores the timing Task request data into a DB database, and calls a Celery method to trigger a Beat component.
The Celery framework is a simple, flexible and reliable distribution system for processing a large number of tasks, which is developed by Python, and can process the tasks in real time and process the tasks in a timing and asynchronous manner. After receiving the user request, the Task-API service stores the timed Task request data into a DB database, and calls a Celery method to trigger the Beat component to load the corresponding Task content.
Step 4: the task-scheduler module in the Beat component loads task content according to the timed task request data, and simultaneously retrieves the DB database in a second level to reach task execution time, and the task-scheduler module sends the task to the MQ task queue of the Broker component.
The task-schedule module is created by carrying out secondary development of timing tasks based on a Celery framework, modifying a Beat component in the Celery and using a database schedule class to rewrite the schedule class in the Beat component. Specifically, the task-schedule module comprises a schedule unit, an all_as_schedule unit, a create_or_update_task unit and a delete_task unit; the schedule unit is used for calling a Celery method to trigger a Beat component so as to call an all_as_schedule unit; the all_as_schedule unit is used for retrieving the DB database in the second level to inquire about tasks to be executed; the create_or_update_task unit is used for creating or updating a task, and dynamically adding or updating the task into the Celery; the delete_task unit is used for dynamically deleting tasks in Celery.
The DateBaseScheduler class of the Beat component is the core of the timed task, which is based on Celery's secondary development, used to retrieve tasks of the DB database. shelle is a simple data storage scheme, similar to key-value database, and can conveniently store python objects, and the inside of the shelle is used for realizing data serialization through a jackle protocol. shelle has an open function that opens a designated file and returns a shelle object (a persistent, field-like object).
By default in the existing Celery framework, the scheduler of Celery-Beat is a Celery. Bean: persistence scheduler, which stores the configuration in a local shell file, and every time a task is added, the Celery needs to be restarted to achieve the timing effect. The invention uses the DateBaseScheduler to rewrite Scheduler, so that the scheduling of dynamic timing tasks can be realized by searching the database in a second level under the condition that Celery is not restarted any more, and the corresponding task dispatch is completed.
The Database scheduler module created by the invention calls the Celery method through the schedule unit to trigger the Beat component to start the call of the all_as_schedule unit, and the all_as_schedule unit is utilized to inquire the tasks to be executed in the DB database. The Task is created or updated through the create_or_update_task unit, and the Task-API calls the create_or_update_task unit in the Celery operation, so that the Task can be dynamically added or updated into the Celery. The Task is deleted by the delete_task unit, which can be dynamically deleted by the Task-API call in Celery operation.
That is, in the original Celery framework, when the Scheduler starts the Beat, the task is written into the shell file (the file is stored locally) in a key-value form through the configuration file, and each time a new task needs to be added in the Celery configuration file, and meanwhile, the new task needs to be restarted, and then the new task can be added. The invention uses the database Scheduler class to rewrite the Scheduler class, and when the Celery starts the Beat service, the Scheduler unit in the database Scheduler class is called, and the tasks in the Celery are loaded by querying the database in a second level, so that the new tasks are loaded under the condition of not restarting the Celery service.
The task-scheduler module in the Beat component loads task content according to the timed task request data, and simultaneously retrieves the DB database in a second level to reach task execution time, and the task-scheduler module sends the task to the MQ task queue of the Broker component.
RabbitMQ is an open-source and powerful enterprise message system supporting the mainstream operating system and multiple development languages. With the Broker: rabitmq service node, a Broker component can be regarded as a rabitmq server. Therefore, the Broker component can also be regarded as a Task queue itself, and receives a message (i.e. Task) sent by the bean component, and stores the Task in the queue. The executor of the task is a Worker component that uses only RabbitMQ to implement the queue service.
Step 5: the Worker component monitors the MQ task queue in real time, when the task exists in the MQ task queue, the Worker component retrieves and operates the resource data in the DB database to execute the task, and the execution result is saved in the DB database.
The task executing component in the workbench component Celery monitors the MQ task queue in real time, and takes the task out of the queue and executes the task if the task exists. The DB database stores user data, resource data of an execution object, timing task request data, and execution result data.
Open source OPENSTACKT does not support dynamically added timing tasks and does not support multicycle timing tasks. Some manufacturers set timing tasks through Celery, but the Celery framework of open source can only set timing tasks through configuration, and does not support dynamic addition of timing tasks. The method of the invention makes up the blank of adding the open source OPENSTACK timing Task, can execute the timing Task in a single period and multiple periods, dynamically add the timing Task and can call a Task-API service interface at the CMP (Cloud Management Platform ) side to finish the processing of the timing Task. The timing task dynamic adding function is realized based on secondary development of the timing task function of the Celery framework, and by modifying the Beat trigger in the Celery, the task can be dynamically added under the condition of not restarting the Celery service, so that the equipment calculation and communication expenditure is saved.
Two specific examples of the method of the present invention are provided below.
Embodiment one: a user creates a timing task request through a cloud platform page, wherein the timing task name is a cloud host snapshot, the task type is the cloud host snapshot, the execution cycle type is selected for single execution, and the task execution time 10 is input: 30, notifying event type is notification when executing failure, notifying mode is mail notification, and sending to appointed mailbox. At the moment, a nova service in the OPENSTACK is called by the page to inquire out cloud host resources under the current user, a cloud host needing to be snapshot is selected as an execution object, and the name and the ID of the cloud host are acquired as execution object resource information. When clicking page creation, task-API service receives the request, stores the timing Task request data into DB database, and calls Task-scheduler module in the Beat component, which is created by using Celery secondary packaging method, and can load newly set cloud host snapshot Task onto Celery. At this time, the task-schedule module in the Celery service continuously scans the database in a second level to check whether the task in the database reaches the task execution time, the task-schedule module sends the task data to the MQ message queue, each Worker component processes different tasks, the Worker component continuously monitors whether the MQ task queue has tasks, the Worker component distributes the tasks to the corresponding Worker component after taking the tasks, the Worker component takes the name and ID of the cloud host needing to be snapshot, the Worker component processing the cloud host snapshot starts to process the business logic for executing the snapshot operation of the cloud host object, the cloud host snapshot is executed, the execution result of the operation resource is stored in the DB database in a mail form after the operation failure is finished, and the cloud host snapshot is fetched. The user may view the execution record through the cloud platform execution log.
Embodiment two: a user creates a timing task request through a cloud platform page, wherein the timing task name is cloud host backup, the task type is cloud host backup, the execution cycle type is selected to be repeatedly executed, the execution time of the task is input to be executed at 10 points and 13 points of friday every week, the notification event type is notification of success and failure, the notification mode is mail notification, and the mail notification is sent to a designated mailbox. At the moment, a page calls a nova service in an OPENSTACK to inquire out a cloud host resource under the current user, a cloud host needing to be backed up is selected as an execution object, and the name and ID of the cloud host are acquired as execution object resource information; setting a task reservation strategy, wherein the reservation rule is a quantity reservation, and the reserved quantity is two. When clicking page creation, task-API service receives the request, stores the timing Task request data into DB database, and calls Task-schedule module in the Beat component, which is created by Celery secondary packaging method, and can load the newly set cloud host backup Task onto Celery. At this time, the task-schedule module in the Celery service continuously scans the database in second level to check whether the task in the database reaches the task execution time, the task-schedule module sends the task data to the MQ message queue, each Worker component processes different tasks, the Worker component continuously monitors whether the MQ task queue has tasks, the Worker component takes the tasks and distributes the tasks to the corresponding Worker component, the Worker component takes the name and ID of the cloud host needing backup, starts to process the service logic for executing the backup resource operation, invokes the corresponding cloud host resource of nova service operation in OPENSTACK, executes the cloud host backup operation, sends the task data to the appointed mailbox in a mail form no matter whether the task is successful or not after the operation is completed, saves the execution result of the operation resource to the DB database, checks whether the cloud host has more than two backups, and deletes redundant backups if the backups exist. The user may view the execution record through the cloud platform execution log.
The invention realizes a general purpose of the timing task dynamic adding function based on Celery secondary development on the open source OPENSTACK, provides a unified method for the dynamic adding of the timing task in the OPENSTACK, and can dynamically add the timing task by using the method to manage the operations of starting and shutting down, restarting and snapshot, backup and the like of the cloud host. The invention can also be applied to CMP sides such as: when a user purchases the cloud host, the cloud host can be dynamically and flexibly maintained, and the cloud host can be started, shut down and restarted at a single time or multiple times every day, and snapshot and backup can be regularly performed. Meanwhile, the additionally timed task of the invention also supports policy reservation, so that resources can be more reasonably allocated. After successful or failed task execution, the mail is sent to the appointed mailbox, so that the user can be timely informed of the completion condition of the timing task. The method also provides a unified interface for the cloud platform timing service, and the Task-scheduler module in Celery is called through the Task-API service, so that the timing Task can be executed in a single time or multiple time periods, and the selection is more flexible.
In the present specification, each embodiment is described in a progressive manner, and each embodiment is mainly described in a different point from other embodiments, and identical and similar parts between the embodiments are all enough to refer to each other.
The principles and embodiments of the present invention have been described herein with reference to specific examples, the description of which is intended only to assist in understanding the methods of the present invention and the core ideas thereof; also, it is within the scope of the present invention to be modified by those of ordinary skill in the art in light of the present teachings. In view of the foregoing, this description should not be construed as limiting the invention.
Claims (8)
1. The method for dynamically adding the timing task based on the OPENSTACK is characterized by comprising the following steps of:
constructing a timing task dynamic adding framework based on OPENSTACK; the timing task dynamic adding architecture comprises an OPENSTACK, a DB database, a Beat component, a Broker component and a workbench component; OPENSTACK is communicatively coupled to the Beat component; OPENSTACK, beat component and Broker component are respectively connected with DB database in communication; the Broker component is respectively in communication connection with the Beat component and the workbench component;
receiving timing Task request data created by a user through a Task-API service in an OPENSTACK custom timer component; the timed task request data includes: timing task name, task type, execution object resource information, execution cycle type, task execution time, notification event type, and notification mode;
based on the timing Task dynamic adding architecture, the Task-API service stores timing Task request data into a DB database, and calls a Celery method to trigger a Beat component;
the task-schedule module in the Beat component loads task content according to the timed task request data, and simultaneously searches the DB database in a second level to reach task execution time, and sends the task to the MQ task queue of the Broker component;
the task-schedule module in the Beat component loads task content according to the timed task request data and before retrieving the DB database in seconds, the task-schedule module further comprises:
performing secondary development of timing tasks based on a Celery framework, modifying a Beat component in the Celery, using a database Scheduler class to rewrite the Scheduler class in the Beat component, and creating a task-Scheduler module; the task-schedule module comprises a schedule unit, an all_as_schedule unit, a create_or_update_task unit and a delete_task unit; the schedule unit is used for calling a Celery method to trigger a Beat component so as to call an all_as_schedule unit; the all_as_schedule unit is used for retrieving the DB database in the second level to inquire about tasks to be executed; the create_or_update_task unit is used for creating or updating a task, and dynamically adding or updating the task into the Celery; the delete_task unit is used for dynamically deleting tasks in Celery;
the Worker component monitors the MQ task queue in real time, when the task exists in the MQ task queue, the Worker component retrieves and operates the resource data in the DB database to execute the task, and the execution result is saved in the DB database.
2. The OPENSTACK-based timed task dynamic addition method of claim 1, wherein the timed task request data is created by user through page initiation.
3. The OPENSTACK-based timing task dynamic addition method of claim 1, wherein the task type includes: cloud host startup, cloud host shutdown, cloud host restart, cloud host snapshot, and cloud host backup.
4. The method for dynamically adding a timed task based on OPENSTACK according to claim 1, wherein the execution object resource information comprises: the object name and ID are executed.
5. The OPENSTACK-based timing task dynamic addition method of claim 1, wherein the execution cycle type includes: single execution and periodic execution.
6. The OPENSTACK-based timing task dynamic addition method of claim 1, wherein the notification event type includes: the execution failure notification, the execution success notification and the success failure notification.
7. The method for dynamically adding a timing task based on OPENSTACK according to claim 1, wherein the notification mode comprises: mail notification, short message notification, and telephone notification.
8. The OPENSTACK-based timing task dynamic addition method of claim 1, wherein the timing task request data further includes: task reservation policies; the task reservation policy comprises a task reservation rule and a reservation number.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310322510.XA CN116028544B (en) | 2023-03-30 | 2023-03-30 | Timing task dynamic adding method based on OPENSTACK |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310322510.XA CN116028544B (en) | 2023-03-30 | 2023-03-30 | Timing task dynamic adding method based on OPENSTACK |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116028544A CN116028544A (en) | 2023-04-28 |
| CN116028544B true CN116028544B (en) | 2023-06-23 |
Family
ID=86089736
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310322510.XA Active CN116028544B (en) | 2023-03-30 | 2023-03-30 | Timing task dynamic adding method based on OPENSTACK |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116028544B (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020192733A1 (en) * | 2019-03-27 | 2020-10-01 | 京东方科技集团股份有限公司 | Timed task configuration method, server, system and computer-readable storage medium |
| CN111913820A (en) * | 2020-08-11 | 2020-11-10 | 傲普(上海)新能源有限公司 | Method for processing http overtime task |
| CN113157411A (en) * | 2021-03-31 | 2021-07-23 | 北京睿芯高通量科技有限公司 | Reliable configurable task system and device based on Celery |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10606661B2 (en) * | 2017-12-15 | 2020-03-31 | Rubrik, Inc. | On-demand provisioning of customized developer environments |
| CN111654534B (en) * | 2020-04-22 | 2023-05-02 | 国云科技股份有限公司 | Private cloud task management system, method and storage medium |
| CN111506412B (en) * | 2020-04-22 | 2023-04-25 | 上海德拓信息技术股份有限公司 | Airflow-based distributed asynchronous task construction and scheduling system and method |
| CN112073262B (en) * | 2020-08-26 | 2022-03-29 | 中国建设银行股份有限公司 | Cloud platform monitoring method, device, equipment and system |
| CN112559614B (en) * | 2020-12-17 | 2023-01-24 | 济南浪潮数据技术有限公司 | Database access method, openStack cloud platform and medium |
| CN113448749B (en) * | 2021-06-04 | 2023-03-24 | 山东英信计算机技术有限公司 | Method, system, device and medium for optimizing execution of expected timing task |
-
2023
- 2023-03-30 CN CN202310322510.XA patent/CN116028544B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2020192733A1 (en) * | 2019-03-27 | 2020-10-01 | 京东方科技集团股份有限公司 | Timed task configuration method, server, system and computer-readable storage medium |
| CN111913820A (en) * | 2020-08-11 | 2020-11-10 | 傲普(上海)新能源有限公司 | Method for processing http overtime task |
| CN113157411A (en) * | 2021-03-31 | 2021-07-23 | 北京睿芯高通量科技有限公司 | Reliable configurable task system and device based on Celery |
Non-Patent Citations (2)
| Title |
|---|
| 基于Django和Celery框架的进度管理平台的设计与实现;吴斌;中国优秀硕士学位论文全文数据库 (信息科技辑);I138-773 * |
| 基于MySQL＿MongoDB＿Redis的Online Judge多数据库应用;王成;陈果;孙宸;欧阳纯萍;;计算机时代(第09期);第24-27页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116028544A (en) | 2023-04-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7779298B2 (en) | Distributed job manager recovery | |
| JP6223569B2 (en) | Computer apparatus, method and apparatus for scheduling business flows | |
| US9876878B2 (en) | Seamless cluster servicing | |
| CN111338784B (en) | Method and system for realizing integration of code warehouse and computing service | |
| CN113569987A (en) | Model training method and device | |
| US8762929B2 (en) | System and method for exclusion of inconsistent objects from lifecycle management processes | |
| US8332443B2 (en) | Masterless distributed batch scheduling engine | |
| WO2019223173A1 (en) | High-frequency task scheduling method and system, and computer device and storage medium | |
| US20180143856A1 (en) | Flexible job management for distributed container cloud platform | |
| US20020161840A1 (en) | Adapter for interfacing with a workflow engine | |
| CN107220100A (en) | One kind exploitation O＆M method, device and cloud computing PaaS platform | |
| US20070083588A1 (en) | Systems and methods for automated provisioning of managed computing resources | |
| US9098359B2 (en) | Durable execution of long running applications | |
| US6226694B1 (en) | Achieving consistency and synchronization among multiple data stores that cooperate within a single system in the absence of transaction monitoring | |
| US20060294417A1 (en) | In-memory replication of timing logic for use in failover within application server node clusters | |
| CN112463450B (en) | Incremental backup management method, system, electronic equipment and storage medium | |
| CN110569113A (en) | Method and system for scheduling distributed tasks and computer readable storage medium | |
| CN111736809A (en) | Distributed robot cluster network management framework and implementation method thereof | |
| US20190205110A1 (en) | Compilation optimization via dynamic server cloning | |
| CN116028544B (en) | Timing task dynamic adding method based on OPENSTACK | |
| WO2024139011A1 (en) | Information processing method | |
| CN114443239A (en) | Method and device for filling container | |
| CN116860288A (en) | ERP system upgrading method, device, equipment and medium | |
| CN115437766A (en) | Task processing method and device | |
| CN115357336A (en) | Online capacity expansion method and device of container group, terminal equipment and medium |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |