Lightweight service scheduling method and system based on file system

Abstract

The invention relates to the technical field of task scheduling, in particular to a lightweight service scheduling method and system based on a file system. The method comprises the following steps: creating an identification file comprising a file name for encoding task state information and file content for each task to form a file system; a task list file is formed by a set of the identification files of all the tasks, and a dependency file used for listing all the front tasks is independently created for each task; and periodically judging whether the dependency of the tasks is met or not by adopting a dependency check rule based on file existence, scanning a file system when the dependency of the tasks is judged to be met, determining a to-be-executed task list from the tasks meeting the dependency by adopting a priority ranking rule based on a time window, and executing the to-be-executed task list in sequence. And performing state updating on the identification file of the task based on the execution result of the task. While core scheduling capability in a limited environment is not lost, light weight, high environmental adaptability, strong robustness and easy maintainability of scheduling are realized.

Description

Technical Field

[0001] This invention relates to the field of task scheduling technology, specifically to a lightweight business scheduling method and system based on a file system. Background Technology

[0002] In technical fields such as meteorology and oceanography, which require highly reliable task scheduling, existing task flow orchestration methods face the following two major technical problems:

[0003] 1. Strong dependence on complex environments: Existing mature scheduling systems (such as Airflow and Azkaban) typically rely on complex middleware components such as databases and message queues to store and query task status and manage dependencies. However, in constrained environments (such as domestic ARM platforms and secure isolated networks), installing and deploying these middleware components is extremely difficult, or even infeasible, preventing the implementation of advanced task scheduling technologies.

[0004] 2. Rigid scheduling logic and poor robustness: Existing scheduling methods based on simple scheduled tasks cannot dynamically perceive the dependencies between tasks. They indirectly achieve "sequence" by preset execution times, requiring accurate analysis of the runtime of each business program to schedule the execution of scheduled tasks. However, if a preceding task fails or times out, subsequent tasks will still start blindly, leading to cascading errors. Furthermore, this existing technology lacks the ability to automatically re-trigger downstream tasks after a failure, usually requiring manual intervention, thus making it difficult to guarantee 24 / 7 automated operation.

[0005] The root of the above technical problems lies in the fact that existing technical solutions deeply couple the two core functions of task state management and dependency resolution with specific, heavyweight middleware, thus inevitably sacrificing lightweightness and environmental adaptability. Summary of the Invention

[0006] To address the aforementioned technical issues, this invention proposes a lightweight business scheduling method and system based on a file system. This method aims to simultaneously achieve lightweight design, high environmental adaptability, strong robustness, and ease of maintenance without sacrificing core scheduling capabilities, providing an effective solution for high-reliability task scheduling in constrained environments.

[0007] Firstly, this application provides a lightweight service scheduling method based on a file system, including the following steps:

[0008] S1. Create a globally unique identifier file for each business program task to form a file system. The identifier file includes a filename for encoding task status information and file content for storing subtask completion information.

[0009] S2, the collection of all task identifier files forms the task list file;

[0010] S3 creates a dependency file for each task in the task manifest file. The dependency file lists the identifier files corresponding to all the preceding tasks that each task depends on.

[0011] S4. Using a dependency check rule based on file existence, periodically check whether the task's dependencies are satisfied. If the task's dependencies are determined to be satisfied, proceed to the next step S5; otherwise, wait for the next cycle to re-execute step S4.

[0012] S5 scans the file system and uses a time window-based priority sorting rule to determine the list of tasks to be executed in the current period from the tasks that satisfy the dependencies.

[0013] S6. Execute each task in the order of the task list, update the status of the task's identifier file based on the execution result of the task, obtain the identifier file of the success status or the identifier file of the failure status, and record the number of tasks that have been executed.

[0014] S7. Repeat step S6 until the number of executed tasks exceeds the preset maximum number of backtracking tasks, then end the task execution for this cycle.

[0015] In some embodiments, a globally unique identifier file is created for each business process task. The identifier file includes a filename used to encode task status information. The method is as follows:

[0016] Extract the key business attributes of the task from the business process task;

[0017] Generate a unique task identifier based on the key business attributes of the task according to the preset splicing rules;

[0018] The task is initially set to a status flag, which includes success, failure, and execution. The default status flag is "execution".

[0019] By concatenating the task's unique identifier and status identifier, the filename of the corresponding identifier file for that task is obtained.

[0020] In some embodiments, a globally unique identifier file is created for each business process task. The identifier file includes file content for storing subtask completion information. The method is as follows:

[0021] Retrieve all subtasks that can be executed in parallel within the business program task;

[0022] Each subtask of this task is uniquely coded to obtain a unique identifier for the subtask.

[0023] Based on the execution results of each subtask in the task, the unique identifier of the completed subtask is recorded in the file content of the corresponding identifier file in text form, line by line.

[0024] In some embodiments, a dependency check rule based on file existence is used to periodically determine whether the task's dependencies are satisfied, including:

[0025] Periodically read the task list file to obtain all tasks for the current period;

[0026] Read the dependency files corresponding to each task to obtain the identifier files corresponding to the preceding tasks that each task depends on;

[0027] For each task, check whether all the preceding tasks that the task depends on have a success status identifier file. If all the preceding tasks have a success status identifier file, the task's dependency is determined to be satisfied. If a preceding task does not have a success status identifier file, the task's dependency is determined to be unsatisfactory.

[0028] In some embodiments, for each task, it is checked whether all the preceding tasks that the task depends on have a success status identification file, including:

[0029] Based on the unique identifier of each preceding task, the file system directory is directly scanned to check if a filename with a corresponding success status exists. The filename with a success status is obtained by concatenating the unique identifier of the preceding task and the success status identifier.

[0030] In some embodiments, the file system is scanned, and a time-window-based priority sorting rule is used to determine a list of tasks to be executed in the current period from tasks that satisfy dependencies, including:

[0031] Obtain the status update timestamps of each identifier file;

[0032] Based on the tasks that satisfy the dependencies, determine the list of identifier files to be executed;

[0033] Scan the file system and check if there are any filenames that begin with the unique identifier of the corresponding task, based on the list of identified files to be executed.

[0034] If it does not exist, the identifier file to be executed is determined to be a new task. For the new task, the identifier file is created according to step S1, forming a highest priority queue.

[0035] If they exist, collect the identification files of the failure status as candidate files, read the file content and status update timestamp of the candidate files, and sort all candidate files in order of the most recent status update timestamp to form a secondary priority queue.

[0036] The highest priority queue is merged with the second-highest priority queue to form a list of tasks to be executed in the current period.

[0037] In some embodiments, a list of identifier files to be executed is determined based on tasks that satisfy dependencies, including:

[0038] For all tasks that satisfy the dependencies, calculate the time difference between the current time and the status update timestamp of each identifier file;

[0039] Tasks with a time difference exceeding the preset backtracking time are removed, and a list of identifier files to be executed is formed based on the identifier files corresponding to the remaining tasks.

[0040] In some embodiments, each task is executed sequentially according to the order of the task list, and the task identification file is updated based on the execution result to obtain a success identification file or a failure identification file, including:

[0041] Execute each task in the order of the pending tasks list, and rename the status flag of the corresponding task file name to "Executing".

[0042] If all subtasks in a task are completed, the task is considered to have been executed successfully. The contents of the corresponding identifier file are updated, and the status identifier of the corresponding file name is renamed to success, thus obtaining a success identifier file.

[0043] If not all subtasks in a task are completed, the task is deemed to have failed. The contents of the corresponding identifier file are updated, and the status identifier of the corresponding file name is renamed to "failure," thus obtaining a failure identifier file.

[0044] Secondly, this application provides a lightweight business scheduling system based on a file system, including:

[0045] The task status identification module is used to create a globally unique identification file for each business program task, forming a file system. The identification file includes a filename for encoding task status information and file content for storing subtask completion information. The collection of identification files for all tasks forms a task list file.

[0046] The task flow orchestration module is used to create a dependency file for each task in the task list file. The dependency file lists the identification files corresponding to all the preceding tasks that each task depends on. It uses a dependency check rule based on file existence to periodically check whether the task's dependencies are satisfied. If the task's dependencies are determined to be satisfied, the task execution module is called; otherwise, it waits for the next cycle to re-check.

[0047] The task execution module scans the file system and uses a time window-based priority sorting rule to determine the list of tasks to be executed in the current period from the tasks that meet the dependencies. Each task is executed sequentially according to the order of the task list. The status of the task's identifier file is updated based on the execution result of the task to obtain an identifier file with a successful status or a failure status, and the number of tasks executed is recorded. The task execution in this period ends when the number of executed tasks exceeds the preset maximum number of backtracking tasks.

[0048] In some embodiments, it also includes:

[0049] The visualization and interaction module is used to display all the identified files in the file system in a visual way on the interface, and to realize human-computer interaction for intervention of the identified files through the interface.

[0050] The beneficial technical effects of the present invention include at least the following:

[0051] 1. Traditional approaches to task scheduling in constrained environments typically follow two paths: one is to attempt laborious trimming, porting, or finding lightweight branches of existing mature scheduling systems, but this still struggles to escape dependence on core components such as databases; the other is to degenerate into more primitive script-based timed triggering, but this comes at the cost of automation reliability and intelligence. This invention, however, employs a lightweight business scheduling method and system based on a file system, breaking free from the conventional thinking of "subtracting from an existing complex architecture" or "adding to a simple solution." Instead, it reconstructs the essence of the scheduling problem (state management and dependency resolution), creatively building the core logic of the scheduling system on a general-purpose file system. This achieves excellent environmental adaptability, dynamic scheduling robustness, and system maintainability while maximizing the simplification of the overall architecture. Its non-obviousness lies in the fact that those skilled in the art typically view file systems merely as passive, low-speed storage media. Specifically, this invention ingeniously elevates the file system into an active, materialized state bus and communication medium through the collaboration of S1 (encoding task status in filenames), S3 (describing dependencies with independent files), and S4 (periodic checks based on file existence). This design enables the system to achieve precise dependency awareness and trigger control—which originally required a complex workflow engine—without any complex communication protocols between resident services, using only the most basic file read / write primitives provided by the operating system. This not only allows the system to be deployed with zero dependency in any extreme environment that supports file operations, achieving unprecedented lightweightness and adaptability, but more importantly, the closed loop formed by S6 (updating file status based on execution results) and S4 naturally creates a dynamic, event-driven scheduling flow. The success or failure status of the preceding task is broadcast in real time through filename changes, and the downstream task determines its readiness by periodically checking the status file. This eradicates the cascading errors caused by the inability to perceive real-time status in existing timed scheduling technologies, and also incorporates a self-healing capability of automatically re-triggering after failure recovery. Meanwhile, the separation of S2 (static task list) and S3 (independent dependency files) completely externalizes the scheduling strategy into an easily editable text configuration, making logic modifications incredibly flexible without requiring service restarts. The entire system's runtime panorama is clearly visible through the file directory list, greatly simplifying operation and maintenance debugging.

[0052] 2. This application cleverly utilizes the "filename" and "file content" of a single identifier file to respectively carry the two layers of information: "overall task status" and "subtask completion details." The subtask status relationships, which would otherwise require a database table to maintain, are flattened and encoded into a single text file. Therefore, there is no need to establish and maintain external association tables between subtasks and parent tasks, nor to create independent tags for a large number of subtasks. This greatly simplifies the state storage model, maintaining zero database dependency and extreme lightweight advantages while achieving fine-grained management capabilities comparable to complex scheduling systems. Specifically, this embodiment no longer creates independent external tags for each subtask. Instead, it uses a simple text format (storing unique subtask identifiers line by line) to serialize and store the set of subtask completion information within the content of the same status identifier file in the parent task, greatly reducing the number of status identifier files and management complexity. The file content is elevated from a "log" or "description" role to a part of the core status data, making querying the subtask completion status equivalent to reading the file and parsing its text lines. Furthermore, the retry logic for subsequent tasks has been upgraded from being based on the "failure" status of the entire task to being based on a "list of incomplete subtasks" parsed from the file content, enabling more granular execution decisions. The system can achieve subtask-level state management by reading, parsing, and updating this file content without introducing any additional storage or management components. This design allows the lightweight scheduling system to possess not only "coarse-grained" task-driven capabilities but also "fine-grained" process-level control capabilities, making it one of the key innovations enabling it to replace traditional heavy-duty scheduling systems in computationally intensive fields such as meteorology and oceanography.

[0053] 3. By materializing and persisting the two abstract pieces of information—task status and dependencies—into the most universally applicable file system, intelligent task flow is achieved through periodic scanning and parsing of file status. The abstract concept of a "task flow dependency graph" is decomposed and mapped to two specific levels of the file system: 1) using text files to declare dependencies (i.e., dependency files); 2) using the existence of files to indicate state satisfaction (identifier files for success states). This simplifies the scheduling system's work into a "file lookup by list" process. Thus, the complex workflow scheduling problem is transformed into a file operation problem that can be supported by any environment and is intuitively managed. This concept not only perfectly inherits the characteristics of this embodiment—few dependent components and cross-platform compatibility—but also endows the system with excellent flexibility, maintainability, and robustness. This is the key innovation that enables this lightweight solution to handle serious business scheduling tasks.

[0054] 4. Traditional solutions have weak backtracking capabilities, making it difficult to easily "backtrack" failed tasks. They either require manual intervention to resubmit or complex operations such as modifying database states, failing to achieve a "one-click" automatic retrieval of all recent failures. To address this, this application further provides a time-window-based intelligent backtracking filtering strategy on top of a lightweight scheduling architecture. The filtering logic only processes tasks where "current time - file status update timestamp ≤ preset backtracking duration," actively ignoring tasks exceeding this preset backtracking duration. This narrows the list of pending files to be executed to a list filtered by the backtracking duration, ensuring the system avoids getting stuck in a meaningless retrieval loop of historically persistent faults and ensuring that scheduling resources focus on recently resolvable problems.

[0055] 5. This application proposes a dynamic priority queue construction scheme based on real-time file system status diagnosis. Specifically, the task execution module is designed as an intelligent cleanup module with time and content awareness capabilities. Instead of blindly executing instructions, it actively scans the file system and dynamically plans the optimal execution order based on the task's "freshness" (whether it is a new task), "urgency of the problem" (the recentity of failure), and "completion of work" (the list of subtasks in the file content). Because this application forcibly prioritizes new tasks over any historically failed tasks, no matter how many old tasks are backlogged and awaiting retry, newly generated business program task requirements can always be responded to and executed immediately, fundamentally ensuring the timeliness of core business operations and meeting the stringent requirements for forecast timeliness in fields such as meteorology and oceanography. The task execution module works by periodically collecting, filtering, and sorting these file facts to derive the optimal execution strategy. This is a decision-making process based entirely on local, declarative data. Therefore, this advanced scheduling scheme is implemented without introducing any additional decision engine or relying on complex database queries. It perfectly matches the lightweight design of the overall architecture of this embodiment, thus achieving timeliness, resource utilization, and self-maintenance capabilities comparable to large-scale distributed scheduling systems in resource-constrained scheduling environments.

[0056] Other features and advantages of the present invention will be disclosed in detail in the following detailed description and accompanying drawings. Attached Figure Description

[0057] The invention will now be further described with reference to the accompanying drawings:

[0058] Figure 1 This is a flowchart of a lightweight service scheduling method based on a file system, according to Embodiment 1 of the present invention.

[0059] Figure 2 This is a schematic diagram of the structure of a lightweight business scheduling system based on a file system, according to Embodiment 2 of the present invention.

[0060] Figure 3 This is a schematic diagram of the structure of a lightweight business scheduling system based on a file system, according to Embodiment 3 of the present invention. Detailed Implementation

[0061] The technical solutions of the embodiments of the present invention will be explained and described below with reference to the accompanying drawings. However, the following embodiments are only preferred embodiments of the present invention and not all of them. Other embodiments obtained by those skilled in the art based on the embodiments in the implementation methods without creative effort are all within the protection scope of the present invention.

[0062] In the following description, terms such as “inner,” “outer,” “upper,” “lower,” “left,” and “right” are used only to facilitate the description of embodiments and simplify the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the present invention.

[0063] Example 1:

[0064] Please see the appendix Figure 1 , Figure 1 A flowchart illustrating a file system-based lightweight service scheduling method provided in one embodiment of this specification is shown.

[0065] like Figure 1 As shown, this file system-based lightweight service scheduling method may include at least the following steps:

[0066] S1. Create a globally unique identifier file for each business program task to form a file system. The identifier file includes a filename for encoding task status information and file content for storing subtask completion information.

[0067] It is understandable that the inventive concept of this embodiment is to completely abandon external middleware such as databases and creatively propose a state materialization and encoding model based on a file system. Specifically, this embodiment decouples the core task metadata (identity) and runtime state of the scheduling system from a dedicated and complex database structure, maps and solidifies them onto the lowest level abstraction of the general operating system—files. By carefully designing the encoding rules of filenames and using the file content of the identifier file to record the completion list of subtasks, a total-to-subtotal structure is formed with the overall task state identified only by the "filename", making the identifier file itself a "smart state tag" containing complete information.

[0068] Specifically, in this embodiment, a globally unique identifier file is created for each business program task. The identifier file includes a filename used to encode task status information. The method is as follows:

[0069] S111, extract the key business attributes of the task from the business program task.

[0070] In this embodiment, the key business attributes include, but are not limited to, abbreviation of business operation scope, mode type, target operation time and task type.

[0071] It is understandable that the extraction process of key business attributes in this embodiment essentially involves the scheduling system collecting all necessary fields based on a predefined task template and the context (especially time) at the time of task triggering. This is achieved through configuration reading and parameter calculation / transmission, and finally, the fields are formatted and concatenated according to a fixed string template to generate a unique ID with business meaning that identifies the task instance throughout the entire system lifecycle. This identifier is determined at the beginning of task creation and is used throughout the subsequent state marking, dependency checking, execution, and backtracking processes.

[0072] S112, Generate a unique task identifier by combining the key business attributes of the task according to the preset splicing rules.

[0073] The global uniqueness of the task identifier can be ensured by using the uniqueness of preset splicing rules for key business attributes or by introducing a serial number. This embodiment will not elaborate on this. For example, for a task running a WRF mode reporting data for Zhejiang Province starting at 00:00 on December 1, 2025, the unique identifier of the task in the corresponding identifier file can be defined as ZJ_WRF_2025120100_RUN. Here, ZJ represents the abbreviation of the geographical area of ​​the business operation (e.g., Zhejiang Province), WRF represents the mode of the business program (e.g., WRF weather mode), 2025120100 represents the target time of the task operation (e.g., 00:00 on December 1, 2025), and RUN represents the type of task (e.g., running a task).

[0074] Understandably, the ingenuity of this step lies in encoding the "task metadata" (task name, parameters, time, etc.) originally stored in a database table into a self-interpreting, structured filename itself. This design allows the basic context of a task to be understood simply by looking at the filename, without needing to query additional configuration tables or databases.

[0075] S113, initially create a status flag for the task. The status flag includes success, failure, and execution. The default value for the initially created status flag is execution.

[0076] Different status identifiers are distinguished by different strings. For example, the success status identifier is "success," which is marked by the system after the business program completes execution and returns a success exit code; the failure status identifier is "fail," which is marked by the system after the business program execution encounters an exception, times out, or returns an error exit code; the executing status identifier is "try," which is created when the task is selected by the scheduling system and begins execution, and is renamed to either success or failure status after execution. In this embodiment, the identifier file formed with the "executing" status identifier as a suffix can serve as both a temporary "executing" marker and a marker for retrying after manual intervention, thus unifying status identifiers and control commands.

[0077] S114. Concatenate the task's unique identifier and status identifier to obtain the filename of the identifier file corresponding to the task, and create the empty file (or a file containing subtask completion information) in the specified directory of the file system.

[0078] It is understandable that this embodiment uses the unique task identifier as the core filename, and adds different status identifier suffixes to form a complete identifier file name. This integrates and persists the two core pieces of information—the task's "identity" and "status"—through the filename, the most basic and universal attribute of the file system. The existence of the identifier file and its suffix are directly equivalent to a status record in the database, and the status is determined entirely by the actual result of task execution, rather than by human pre-setting. This combines task status identifiers and control commands, simplifying system design and improving flexibility. For example, the filename ZJ_WRF_2025120100_RUN.success indicates that the WRF mode task in Zhejiang Province was successfully executed.

[0079] Specifically, in this embodiment, a globally unique identifier file is created for each business program task. The identifier file includes file content used to store subtask completion information. The method is as follows:

[0080] S121, obtain all subtasks that can be executed in parallel in the business program task;

[0081] S122, each subtask of the task is uniquely encoded to obtain a unique identifier for the subtask.

[0082] In this embodiment, the unique encoding of a subtask is directly derived from the most natural, distinguishable, and discretized identifier within its business context. This identifier can be a time index (forecast lead time), a spatial index (grid, region), a data source identifier (mode, observation type, member number), or an experiment configuration number. Regardless of the type, the goal is to generate a simple, unambiguous string. By recording this identifier string line by line within the task's file content, fine-grained management, state persistence, and precise retries for complex parallel task sets can be achieved while maintaining an extremely lightweight architecture (using only the file system).

[0083] For example, for tasks with multiple forecast steps, such as 1-hour forecasts and 2-hour forecasts, the integer string of the forecast step can be used to uniquely encode the subtask. For regional gridded processing tasks, such as meteorological and oceanographic models and post-processing tasks (e.g., interpolation, diagnostics, plotting) based on regular latitude and longitude grids or unstructured grids, the index number of the grid block or sub-region can be used to uniquely encode the subtask. For multi-model / multi-ensemble ensemble forecasting tasks, such as running multiple different numerical forecasting models (e.g., ECMWF, GFS, WRF), or running multiple ensemble members of a single model and performing integrated post-processing on all results, the model name or ensemble member number can be used to uniquely encode the subtask. For observation data assimilation or verification tasks, such as processing massive amounts of data from multiple observation platforms (e.g., satellites, radars, radiosondes, ground stations) during data assimilation or forecast verification, these processes are often performed in parallel according to observation type, satellite platform, or time batch, so the type identifier of the observation data or the data source number can be used to uniquely encode the subtask.

[0084] S123, based on the execution results of each subtask in this task, record the unique identifier of the completed subtask in the file content of the corresponding identifier file in text form, line by line.

[0085] Understandably, in traditional task scheduling systems, achieving refined management of subtasks (or steps, procedures) typically faces the following challenges:

[0086] 1. High management overhead: If an independent status record is created in the database for each subtask, the number of records will surge, increasing the overhead of storage, query and transaction management, which will become a bottleneck in lightweight or high-concurrency scenarios.

[0087] 2. Strong environmental dependence: Traditional task scheduling systems rely on database-based fine-grained management, which strengthens the dependence on centralized databases, contradicting the goal of this embodiment to adapt to a restricted environment without complex component dependencies.

[0088] 3. Coarse granularity and wasteful resources: If only one status flag is used to represent the entire complex task, then the failure of any subtask will cause the entire task to be marked as failed. During retries, all subtasks must be rerun, including those that have already succeeded, resulting in a serious waste of computing resources. This is especially inefficient for time-consuming and resource-intensive scientific computing tasks (such as running in different forecast lead times).

[0089] To address this, this embodiment cleverly utilizes the "filename" and "file content" of a single identifier file to respectively carry the "overall task status" and "subtask completion details" information. The subtask status relationships, which would otherwise require a database table to maintain, are flattened and encoded into a single text file. Therefore, there is no need to establish and maintain external association tables between subtasks and parent tasks, nor to create independent tags for a large number of subtasks. This greatly simplifies the state storage model, maintaining zero database dependency and extreme lightweight advantages while achieving fine-grained management capabilities comparable to complex scheduling systems. Specifically, this embodiment no longer creates independent external tags for each subtask. Instead, it uses a simple text format (storing unique subtask identifiers line by line) to serialize and store the set of subtask completion information within the content of the same status identifier file in the parent task, significantly reducing the number of status identifier files and management complexity. The file content is elevated from a "log" or "description" role to a part of the core status data, making querying the subtask completion status equivalent to reading the file and parsing its text lines. Furthermore, the retry logic for subsequent tasks has been upgraded from being based on the "failure" status of the entire task to being based on a "list of incomplete subtasks" parsed from the file content, enabling more granular execution decisions. The system can achieve subtask-level state management by reading, parsing, and updating this file content without introducing any additional storage or management components. This design allows the lightweight scheduling system to possess not only "coarse-grained" task-driven capabilities but also "fine-grained" process-level control capabilities, making it one of the key innovations enabling it to replace traditional heavy-duty scheduling systems in computationally intensive fields such as meteorology and oceanography.

[0090] S2, the collection of all task identifier files forms the task list file.

[0091] In this embodiment, the task list file is a global, linear list of task execution sequences. Its sole function is to list, row by row, the unique identifiers of tasks that need to be included in the dependency check. It does not directly describe dependencies, but rather defines the "set of tasks" that the scheduler needs to focus on and their approximate check order. The task list file is a static, predefined text configuration file, written and maintained automatically by the system or manually by the administrator.

[0092] S3 creates a separate dependency file for each task in the task manifest file. The dependency file lists the identifier files corresponding to all the preceding tasks that each task depends on.

[0093] In this embodiment, the design allows the dependencies of each task to be modified independently without affecting each other.

[0094] Understandably, existing scheduling systems are deeply coupled with complex middleware such as databases and message queues, making deployment difficult in restricted environments such as domestically produced or isolated networks. To address the issue of strong environmental dependencies in existing technologies, this embodiment constructs a decentralized state storage layer through the collaboration of S1 (creating an identifier file) and S2 (forming a task list file). The metadata (identity) and runtime state of each task are materialized into an independent identifier file, and the set of all tasks is defined by a plain text task list file. Simultaneously, S3 (creating a dependency file) stores dependencies in a divide-and-conquer manner within the file system, also in plain text file format, separate from the task list file. Through the collaborative action of S1, S2, and S3, the core data (task metadata, runtime state, and dependencies) centralized in the database in traditional architectures are decomposed and mapped to ordinary text files in the file system. The file system is the most basic and universal component of any operating system (including the domestic ARM platform), requiring no additional installation or deployment. Therefore, the design of this embodiment completely eliminates any dependence on external middleware such as databases and message queues for the entire scheduling system. Its core state relies entirely on the file abstraction provided by the underlying operating system, possessing strong environmental adaptability and lightweight deployment. It can be driven by scripts or lightweight programs that can read and write files, enabling advanced scheduling technology to be implemented in constrained environments. Furthermore, since the definition and modification of task flows in this embodiment no longer require modifying program code, restarting services, or performing database migrations, but only need to be completed by editing the task list file and the corresponding dependency files, business personnel can flexibly and quickly adjust, test, and roll back the task execution order and dependencies, greatly reducing operational costs and improving the agility of business response.

[0095] S4 uses a dependency check rule based on file existence to periodically determine whether the task's dependencies are satisfied. If the task's dependencies are determined to be satisfied, the next step S5 is executed; otherwise, the process waits for the next cycle to re-execute step S4.

[0096] It is understandable that the core innovation of this embodiment lies in using two plain text files (task list file and dependency file) in conjunction with the status identifier file in the file system, and adopting a file existence check mechanism to manage dependencies. Under the premise of relying entirely on the file system, it realizes the dependency resolution and trigger scheduling that originally required a complex workflow engine to complete, completely avoiding the use of databases or complex middleware.

[0097] Specifically, in this embodiment, a dependency check rule based on file existence is used to periodically determine whether the task's dependencies are satisfied, including:

[0098] S41, periodically read the task list file to obtain all tasks for the current period;

[0099] S42, Read the dependency files corresponding to each task to obtain the identification files corresponding to the preceding tasks that each task depends on;

[0100] S43. For each task, check whether all the preceding tasks that the task depends on have a success status identification file. If all the preceding tasks have a success status identification file, the task's dependency is determined to be satisfied. If a preceding task does not have a success status identification file, the task's dependency is determined to be unsatisfactory.

[0101] Specifically, this embodiment can be activated by a timed trigger (e.g., every 30 minutes). Once activated, its core logic is a loop algorithm: it reads the task list file and iterates through predefined task flow dependencies. For each task to be executed in the task list file, it checks in the file system whether all its predecessor tasks have corresponding success status identifier files. The dependency determination condition is simplified to a Boolean logic: all predecessor tasks listed in the dependency files must have corresponding success status identifier files found in the file system; if any one is not found, the dependency is deemed not satisfied.

[0102] Furthermore, in this embodiment, for each task, it is checked whether all the preceding tasks that the task depends on have identification files with a successful status, including:

[0103] Based on the unique identifier of each preceding task, the file system directory is directly scanned to check if a filename with a corresponding success status exists. The filename with a success status is obtained by concatenating the unique identifier of the preceding task and the success status identifier.

[0104] Understandably, the core inventive concept of this step is to materialize and persist the two abstract pieces of information—task state and dependency relationships—into the most universally applicable file system. Intelligent task flow is achieved through periodic scanning and parsing of file states. The abstract concept of a "task flow dependency graph" is broken down and mapped to two specific levels of the file system: 1) using text files to declare dependencies (i.e., dependency relationship files); 2) using the existence of files to indicate state satisfaction (identifier files for success states). This simplifies the scheduling system's work into a process of "searching for files by list." Specifically, for each line in the dependency relationship file (i.e., the unique identifier of a preceding task), the scheduling system does not call any APIs or query the database; instead, it directly checks the file system directory for the existence of a file named "[unique identifier of the preceding task].success". The deterministic operation of "checking if a successful status file exists" designed in this embodiment is a dependency judgment mechanism with minimal logical complexity, high reliability, and cross-platform compatibility. The dependency check rule based on file existence does not concern itself with how the task succeeded; it only consumes the existence of the successful status object (i.e., the identifier file for the successful status), making dependency judgment extremely lightweight and reliable, since file existence is one of the most stable and fastest native states provided by the operating system. This embodiment transforms a complex workflow scheduling problem into a file operation problem that can be supported by any environment and is intuitively manageable. This concept not only perfectly inherits the characteristics of few dependent components and cross-platform compatibility of this embodiment but also endows the system with excellent flexibility, maintainability, and robustness. This is the key innovation that enables this lightweight solution to handle serious business scheduling tasks.

[0105] Understandably, since the dependency logic and state of the entire system in this embodiment are entirely represented by text files and identifier files on the disk, even if the scheduler process itself crashes and restarts, the new process only needs to reread the task list file and dependency file, and scan the existing success status identifier files in the file system to instantly reconstruct the previous complete task flow state and progress. This achieves rapid fault recovery for the stateless scheduler, resulting in extremely strong overall system robustness. Furthermore, because this solution replaces complex database queries and transaction management with the simplest file checks, the scheduler itself has extremely low resource consumption and high execution efficiency. Moreover, by supporting AND logic for multiple pre-dependencies through dependency files, it is sufficient to describe most complex linear or fan-in business workflows, thus achieving an excellent balance between resource consumption and functional completeness.

[0106] S5 scans the file system and uses a time-window-based priority sorting rule to determine the list of tasks to be executed in the current cycle from the tasks that satisfy the dependencies.

[0107] Unlike the aforementioned "task list file," the task list to be executed in this embodiment is a dynamic, runtime-generated temporary task queue. It is generated and used within the task execution module, existing only temporarily within the execution module's cycle, and becomes invalid after the current execution is completed. The task list file declares "which tasks need to be scheduled," belonging to the static configuration layer, while the task list to be executed determines "the specific order in which task instances are executed," belonging to the dynamic runtime decision layer. The two are related as a goal and an execution plan, with clear division of labor and seamless integration, together forming a complete path from task definition to task execution.

[0108] Understandably, step S5 is the core decision-making step in task execution. It is not simply about executing a list of tasks, but rather about proactively diagnosing the file system status and intelligently constructing an optimal execution sequence.

[0109] Specifically, in this embodiment, the file system is scanned, and a priority sorting rule based on time windows is used to determine the list of tasks to be executed in the current period from tasks that satisfy dependencies, including:

[0110] S51, obtain the status update timestamps of each identifier file;

[0111] S52, based on the tasks that satisfy the dependencies, determine the list of identifier files to be executed.

[0112] Specifically, the identifier files corresponding to the tasks that satisfy the dependencies can be listed directly in rows to form a list of identifier files to be executed.

[0113] Furthermore, in this embodiment, determining the list of identifier files to be executed based on tasks that satisfy dependencies also includes:

[0114] For all tasks that satisfy the dependencies, calculate the time difference between the current time and the status update timestamp of each identifier file;

[0115] Tasks with a time difference exceeding the preset backtracking time are removed, and a list of identifier files to be executed is formed based on the identifier files corresponding to the remaining tasks.

[0116] Understandably, traditional solutions have weak backtracking capabilities, making it difficult to easily "backtrack" failed tasks. They either require manual intervention to resubmit or complex operations such as modifying database states, failing to achieve a "one-click" automatic retrieval of all recent failures. Therefore, this embodiment further provides a time-window-based intelligent backtracking filtering strategy on top of a lightweight scheduling architecture. The filtering logic only processes tasks where "current time - file status update timestamp ≤ preset backtracking duration," actively ignoring tasks exceeding this preset backtracking duration. This narrows the list of pending files to be executed to a list filtered by the backtracking duration, ensuring the system doesn't get stuck in a meaningless retrieval loop of historically persistent faults and ensuring scheduling resources focus on recently resolvable problems.

[0117] S53, scan the file system, and check if there is a filename that begins with the unique identifier of the corresponding task, based on the list of identifier files to be executed.

[0118] If it does not exist, the identifier file to be executed is determined to be a new task. For the new task, the identifier file is created according to step S1, forming a highest priority queue.

[0119] If they exist, collect the identification files of the failure status as candidate files, read the file content and status update timestamp of the candidate files, and sort all candidate files in order of the most recent status update timestamp to form a secondary priority queue.

[0120] Specifically, the implementation method of S5 in this embodiment is as follows:

[0121] First, a full scan of the file system directory is performed to obtain a list of identifier files corresponding to all tasks in the list of identifier files to be executed. Each identifier file carries key metadata: filename (containing a unique identifier and status identifier for the task) and status update timestamp.

[0122] Secondly, a highest-priority queue is constructed. During the file system scan, the system searches for any files that begin with the unique identifier of the task (i.e., [target task unique identifier].success, [target task unique identifier].fail, and [target task unique identifier].try). If none of these files are found, the task is considered a "brand new, never-before-tried" task. To begin execution immediately, the system calls the task marking module to create an identifier file named [target task unique identifier].try, places the new task represented by this identifier file into a temporary queue, and marks it as the highest priority.

[0123] Next, a secondary priority queue is constructed. From the file list filtered by backtracking duration, all files with the identifier "[target task unique identifier].fail" are collected as candidate files, representing historical failures awaiting retry. For each candidate file, its status update timestamp and file content are read. The file content stores a list of unique identifiers of successfully completed subtasks under that task, line by line. This information is crucial to avoid duplicate calculations later. All candidate tasks are strictly sorted according to their status update timestamps from newest to oldest (from most recent to oldest), with the most recently failed task at the top.

[0124] S54 merges the highest priority queue with the second-highest priority queue to form a list of tasks to be executed in the current period.

[0125] Specifically, the highest priority queue is placed before the second-highest priority queue and merged to form the final linear list of tasks to be executed with clear priorities in the current cycle. The dynamic priority sorting of the task list ensures that business timeliness is prioritized while also taking into account failure recovery: brand-new business program tasks are executed with absolute priority, followed by retrying historical failed tasks in descending order of the relevance of the failure.

[0126] S6. Execute each task sequentially according to the order of the task list. Update the status of the task's identifier file based on the execution result of the task to obtain an identifier file with a successful status or an identifier file with a failed status, and record the number of tasks that have been executed.

[0127] Understandably, the updated identifier file directly alters the file system's state information. When the next check cycle arrives, a new loop will begin again from step S4. At this point, because the successful task in the previous cycle generated a new identifier file with a new success status, it may unlock new subsequent tasks that depend on it, thus driving the workflow forward.

[0128] Specifically, in this embodiment, each task is executed sequentially according to the order of the task list. The task identification file is updated based on the execution result to obtain either a success identification file or a failure identification file, including:

[0129] S61, execute each task in the order of the task list, and rename the status flag of the file name corresponding to the task to "Executing", that is, ensure that the file name of the flag file has the suffix ".try".

[0130] Furthermore, this embodiment can perform precise retries based on file content when executing tasks. Specifically, during the task backtracking phase (step S53), the task execution module reads the file content of the failure status identifier file to accurately determine which subtasks have been completed. Thus, it determines that those subtasks that do not appear in the file content are the subtasks that have not yet been completed. Subsequently, when executing the task, only those subtasks that have not yet been completed are scheduled and executed, rather than re-executing the entire task.

[0131] S62, if all subtasks in the task are completed, the task is determined to be successful. The file content of the corresponding identifier file is updated, that is, the unique identifiers of all subtasks are recorded in the file content of the corresponding identifier file in text form, and the status identifier of the file corresponding to the task is renamed to success. The file name of the renamed success identifier file is obtained by concatenating the unique identifier of the task and the success status identifier.

[0132] If not all subtasks in a task are completed, the task is deemed to have failed. The contents of the corresponding identifier file are then updated. Specifically, the unique identifiers of the completed subtasks (partial subtasks) are recorded line by line in the contents of the corresponding identifier file. The status identifier of the corresponding file is renamed to "failure". The filename of the renamed failure identifier file is obtained by concatenating the unique identifier of the task and the failure status identifier.

[0133] Specifically, the system continuously checks the completion status of all planned subtasks under a given task. Only when all subtasks are detected as completed (i.e., the file content contains unique subtask identifiers) will the task execution module rename the task's marker file from .try to .success. At this point, the list in the file content will be a complete record of all completed subtasks. If the task ultimately fails, the marker file is renamed from .try to .fail, and its content retains the list of completed subtasks at the moment of failure, which can be used for subsequent diagnostics. Furthermore, the atomic state update (renaming operation) centered on file operations ensures system reliability.

[0134] Understandably, traditional task executors (whether simple timed scripts or part of a complex scheduling framework) often face the following technical problems when handling task queues:

[0135] 1. Lagging and rigid state awareness: The executor usually passively receives scheduling instructions and lacks the ability to proactively and intelligently sort out historical failure states. The retry logic is often a simple fixed number of retries and cannot be filtered based on business time windows. That is, the executor itself lacks the ability to dynamically adjust the execution priority according to the real-time system state (especially the accumulation of task failure states).

[0136] 2. Resource waste: The lack of an automatic abandonment mechanism for continuously failing tasks leads to the unlimited occupation of scheduling resources. Furthermore, when retries fail, the entire task is often re-executed without considering potentially completed subtasks, resulting in significant waste of computing resources.

[0137] 3. Insufficient guarantee of business timeliness: In scenarios that mix new tasks and backlogged failed tasks, the lack of an effective priority arbitration mechanism may cause important new business requests to be blocked by backlogged historical retry tasks, affecting the overall business timeliness.

[0138] To address this, this embodiment proposes a dynamic priority queue construction scheme based on real-time file system status diagnosis. Specifically, the task execution module is designed as an intelligent cleanup module with time and content awareness capabilities. Instead of blindly executing instructions, it actively scans the file system and dynamically plans the optimal execution order based on the task's "freshness" (whether it's a new task), "urgency of the problem" (the recentity of failure), and "completion level" (the list of subtasks in the file content). Because this embodiment forcibly prioritizes new tasks over any historically failed tasks, regardless of how many old tasks are backlogged for retry, newly generated business program task requirements can always be responded to and executed immediately, fundamentally ensuring the timeliness of core business and meeting the stringent requirements for forecast timeliness in fields such as meteorology and oceanography. By reading the file content of the failure status identifier file, the completion status at the subtask level is perceived, allowing retry actions to be precisely reduced from the task level to the subtask level. During retries, only the truly failed subtask sets can be scheduled and calculated, avoiding the huge waste of computing resources and time caused by traditional full retries. This is particularly beneficial for computationally intensive tasks such as numerical weather prediction. The technical principle of this scheme is based on the file system as the "source of facts." The presence or absence of a target task identifier file indicates the existence of the task; the age of the file (status update timestamp) indicates the order in which events occurred; and the file content represents the internal progress of the task. The task execution module works by periodically collecting, filtering, and sorting these file facts to derive the optimal execution strategy. This is a decision-making process based entirely on local, declarative data. Therefore, this advanced scheduling scheme is implemented without introducing any additional decision engine or relying on complex database queries. This perfectly matches the lightweight design goal of the overall architecture of this embodiment, thus achieving timeliness, resource utilization, and self-maintenance capabilities comparable to large-scale distributed scheduling systems in resource-constrained scheduling environments.

[0139] S7. Repeat step S6 until the number of executed tasks exceeds the preset maximum number of backtracking tasks, then end the task execution for this cycle.

[0140] It is understood that this embodiment is an active execution scheme based on file system scanning, driven by status identifier files, and with fine-grained backtracking capabilities. Its innovation lies in using the file system to manage task status and realizing task execution and backtracking through timestamp filtering, priority sorting, and file operations.

[0141] In summary, existing scheduling technologies based on scheduled tasks cannot dynamically perceive task status; failure of a preceding task leads to the blind execution of subsequent tasks, and there is a lack of automatic recovery mechanisms. Therefore, this embodiment addresses the rigid scheduling logic and poor robustness of existing technologies by implementing a lightweight file system-based design for S1-S7, achieving a fundamental innovation in the scheduling system architecture. Specifically:

[0142] 1. Dynamic Awareness and High Robustness to Avoid Cascading Errors: Through the collaborative work of S1 (state encoded in filename) and dependency checking rules based on file existence, combined with S6 (state update after execution) to form a feedback loop, task states are materialized as files, simplifying dependency checking to a scan and query of the file system state. The scheduling logic changes from "time-driven" to "event (state)-driven." The system no longer needs to preset precise execution times, but instead triggers downstream tasks through the event of "file state change." When a preceding task fails (a file with a failed state exists), the dependency checking rules naturally fail, and subsequent tasks will not even enter the list of tasks to be executed. This mechanism eliminates cascading errors and solves the problem of chaotic execution caused by inaccurate time estimation or task failure in traditional scheduled tasks.

[0143] 2. Built-in self-healing capability ensures continuous automated operation: A closed-loop mechanism consisting of S4 (periodic checks) and S6 (state updates) forms a self-healing capability. Once a failed task is repaired and successfully re-executed, its identifier file is updated to a success status. In the next check cycle, the system automatically detects this status change and immediately triggers the execution of all downstream tasks that depend on this task. This gives the system the ability to automatically recover from breakpoints, significantly reducing manual intervention and truly achieving a highly available automated task flow, effectively supporting the uninterrupted business operation needs of meteorological, marine, and other fields.

[0144] 3. Simple, flexible, and easy-to-maintain architecture: Business definitions and dependencies are separated through S2 (static task manifest file) and S3 (independent dependency file). Combined with the general-purpose interpreted execution engine provided by S4-S7, flexible task flow orchestration is achieved collaboratively. The static task manifest file and dependency file intuitively define the "blueprint" of the scheduling logic, while the dynamic checking, sorting, and execution steps (S4-S7) are responsible for following the blueprint. Modifying task dependencies only requires editing the corresponding dependency file, and the scheduling logic can be dynamically adjusted without restarting the scheduling service or modifying the core code, achieving flexibility and maintainability of the scheduling logic. The entire system's state is fully materialized in the file system. By viewing the file list and contents in the directory, the current status and historical execution results of all tasks can be directly and completely observed, greatly facilitating troubleshooting and system auditing.

[0145] Example 2:

[0146] Please see the appendix Figure 2 , Figure 2 This is a schematic diagram of a lightweight service scheduling system based on a file system, provided as an embodiment of this specification.

[0147] like Figure 2 As shown, this file system-based lightweight business scheduling system may include at least:

[0148] Task status identification module 1 is used to create a globally unique identification file for each business program task, forming a file system. The identification file includes a filename for encoding task status information and file content for storing subtask completion information. The collection of identification files for all tasks forms a task list file.

[0149] Task flow orchestration module 2 is used to create a dependency file for each task in the task list file. The dependency file lists the identification files corresponding to all the preceding tasks that each task depends on. It uses a dependency check rule based on file existence to periodically check whether the task's dependency is satisfied. If the task's dependency is determined to be satisfied, the task execution module is called; otherwise, it waits for the next cycle to re-check.

[0150] Task execution module 3 is used to scan the file system and uses a time window-based priority sorting rule to determine the list of tasks to be executed in the current period from the tasks that meet the dependencies. Each task is executed in the order of the task list. The status of the task's identifier file is updated based on the execution result of the task to obtain an identifier file with a successful status or a failure status, and the number of tasks executed is recorded. The task execution of the current period ends when the number of executed tasks is greater than the preset maximum number of backtracking tasks.

[0151] It is understood that the technical concept of the file system-based lightweight service scheduling system provided in this embodiment is similar to the technical concept of the aforementioned file system-based lightweight service scheduling method, and will not be repeated here.

[0152] Example 3:

[0153] This embodiment only applies to comparisons with... Figure 2 The differences between the two embodiments will be described in detail here. The technical concepts of the rest of the design are similar to those of the two embodiments, and will not be repeated here.

[0154] Please see the appendix Figure 3 In this embodiment, the lightweight service scheduling system based on the file system further includes:

[0155] The visualization and interaction module 4 is used to display all the identified files in the file system in a visual way on the interface, and to realize human-computer interaction for intervention of the identified files through the interface.

[0156] Specifically, the visualization interaction module 4 is used to query and view the status of business program task flows, and can publish, delete, and modify the status of business program tasks through human-computer interaction, achieving the purpose of interacting with the business flow system. The visualization interaction module 4 reads file markers within the file system, filters, and displays the status of business program task flows according to date, calendar, or other formats, using different character conventions to identify different task statuses. Simultaneously, based on human-computer interaction file intervention commands, it can publish new task markers, delete unnecessary task markers, and modify the status of existing task markers, thus realizing human-computer interaction.

[0157] The above description is merely a preferred embodiment disclosed in this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of protection involved in this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this disclosure.

[0158] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

Claims

1. A lightweight service scheduling method based on a file system, characterized in that, Includes the following steps: S1. Create a globally unique identifier file for each business program task to form a file system. The identifier file includes a filename for encoding task status information and file content for storing subtask completion information. S2, the collection of all task identifier files forms the task list file; S3 creates a dependency file for each task in the task manifest file. The dependency file lists the identifier files corresponding to all the preceding tasks that each task depends on. S4. Using a dependency check rule based on file existence, periodically check whether the task's dependencies are satisfied. If the task's dependencies are determined to be satisfied, proceed to the next step S5; otherwise, wait for the next cycle to re-execute step S4. S5 scans the file system and uses a time window-based priority sorting rule to determine the list of tasks to be executed in the current period from the tasks that satisfy the dependencies. S6. Execute each task in the order of the task list, update the status of the task's identifier file based on the execution result of the task, obtain the identifier file of the success status or the identifier file of the failure status, and record the number of tasks that have been executed. S7. Repeat step S6 until the number of executed tasks exceeds the preset maximum number of backtracking tasks, then end the task execution for this cycle.

2. The lightweight service scheduling method based on a file system as described in claim 1, characterized in that, For each business process task, a globally unique identifier file is created. The identifier file includes a filename used to encode task status information, as follows: Extract the key business attributes of the task from the business process task; Generate a unique task identifier based on the key business attributes of the task according to the preset splicing rules; The task is initially set to a status flag, which includes success, failure, and execution. The default status flag is "execution". By concatenating the task's unique identifier and status identifier, the filename of the corresponding identifier file for that task is obtained.

3. The lightweight service scheduling method based on a file system as described in claim 1, characterized in that, For each business process task, a globally unique identifier file is created. The identifier file includes file content used to store subtask completion information, as follows: Retrieve all subtasks that can be executed in parallel within the business program task; Each subtask of this task is uniquely coded to obtain a unique identifier for the subtask. Based on the execution results of each subtask in the task, the unique identifier of the completed subtask is recorded in the file content of the corresponding identifier file in text form, line by line.

4. The lightweight service scheduling method based on a file system as described in claim 2, characterized in that, A dependency check rule based on file existence is used to periodically determine whether the task's dependencies are satisfied, including: Periodically read the task list file to obtain all tasks for the current period; Read the dependency files corresponding to each task to obtain the identifier files corresponding to the preceding tasks that each task depends on; For each task, check whether all the preceding tasks that the task depends on have a success status identifier file. If all the preceding tasks have a success status identifier file, the task's dependency is determined to be satisfied. If a preceding task does not have a success status identifier file, the task's dependency is determined to be unsatisfactory.

5. The lightweight service scheduling method based on a file system as described in claim 4, characterized in that, For each task, check whether all the prerequisite tasks that the task depends on have a success status identification file, including: Based on the unique identifier of each preceding task, the file system directory is directly scanned to check if a filename with a corresponding success status exists. The filename with a success status is obtained by concatenating the unique identifier of the preceding task and the success status identifier.

6. The lightweight service scheduling method based on a file system as described in claim 2, characterized in that, The file system is scanned, and a priority sorting rule based on time windows is used to determine the list of tasks to be executed in the current period from tasks that satisfy dependencies, including: Obtain the status update timestamps of each identifier file; Based on the tasks that satisfy the dependencies, determine the list of identifier files to be executed; Scan the file system and check if there are any filenames that begin with the unique identifier of the corresponding task, based on the list of identified files to be executed. If it does not exist, the identifier file to be executed is determined to be a new task. For the new task, the identifier file is created according to step S1, forming a highest priority queue. If they exist, collect the identification files of the failure status as candidate files, read the file content and status update timestamp of the candidate files, and sort all candidate files in order of the most recent status update timestamp to form a secondary priority queue. The highest priority queue is merged with the second-highest priority queue to form a list of tasks to be executed in the current period.

7. The lightweight service scheduling method based on a file system as described in claim 6, characterized in that, Based on the tasks that satisfy the dependencies, a list of identifier files to be executed is determined, including: For all tasks that satisfy the dependencies, calculate the time difference between the current time and the status update timestamp of each identifier file; Tasks with a time difference exceeding the preset backtracking time are removed, and a list of identifier files to be executed is formed based on the identifier files corresponding to the remaining tasks.

8. The lightweight service scheduling method based on a file system as described in claim 3, characterized in that, Execute each task sequentially according to the order of the task list. Update the task's identifier file based on the execution result to obtain either a success identifier file or a failure identifier file, including: Execute each task in the order of the pending tasks list, and rename the status flag of the corresponding task file name to "Executing". If all subtasks in a task are completed, the task is considered to have been executed successfully. The contents of the corresponding identifier file are updated, and the status identifier of the corresponding file name is renamed to success, thus obtaining a success identifier file. If not all subtasks in a task are completed, the task is deemed to have failed. The contents of the corresponding identifier file are updated, and the status identifier of the corresponding file name is renamed to "failure," thus obtaining a failure identifier file.

9. A lightweight business scheduling system based on a file system, characterized in that: include: The task status identification module is used to create a globally unique identification file for each business program task, forming a file system. The identification file includes a filename for encoding task status information and file content for storing subtask completion information. The collection of identification files for all tasks forms a task list file. The task flow orchestration module is used to create a dependency file for each task in the task list file. The dependency file lists the identification files corresponding to all the preceding tasks that each task depends on. It uses a dependency check rule based on file existence to periodically check whether the task's dependencies are satisfied. If the task's dependencies are determined to be satisfied, the task execution module is called; otherwise, it waits for the next cycle to re-check. The task execution module scans the file system and uses a time window-based priority sorting rule to determine the list of tasks to be executed in the current period from the tasks that meet the dependencies. Each task is executed sequentially according to the order of the task list. The status of the task's identifier file is updated based on the execution result of the task to obtain an identifier file with a successful status or a failure status, and the number of tasks executed is recorded. The task execution in this period ends when the number of executed tasks exceeds the preset maximum number of backtracking tasks.

10. The lightweight service scheduling system based on a file system as described in claim 9, characterized in that, Also includes: The visualization and interaction module is used to display all the identified files in the file system in a visual way on the interface, and to realize human-computer interaction for intervention of the identified files through the interface.

Images