Task scheduling method and device
By dynamically determining the service number of service nodes in a distributed system, and based on the task sequence number and the number of surviving nodes, dynamic and balanced task allocation is achieved, solving the problems of uneven task allocation and single point of failure, and improving the system's disaster recovery capability and task processing efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NETSUNION CLEARING CORP
- Filing Date
- 2024-10-28
- Publication Date
- 2026-04-28
AI Technical Summary
Existing task scheduling methods in distributed systems suffer from problems such as uneven task allocation, single points of failure, and high management complexity, especially when processing large-scale tasks, making it difficult to achieve effective disaster recovery capabilities.
By deploying service nodes in a distributed system, the service number is dynamically determined using the task sequence number and the number of surviving service nodes, thereby achieving distributed scheduling of the target task. A stateless task scheduling strategy is adopted to dynamically and evenly distribute tasks to each surviving service node.
It achieves distributed and equal scheduling of target tasks, avoids single points of failure in services, provides disaster recovery capabilities, reduces management complexity, and improves task processing efficiency.
Smart Images
Figure CN121934963A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a task scheduling method and apparatus. Background Technology
[0002] Much of the data generated during the daily operation of a database no longer needs to be accessed in real time over time, necessitating data archiving and thus creating data archiving tasks. As the number of database cluster nodes and tables increases, the number of data archiving tasks and the amount of archived data generated within an archiving cycle also increase. This gradually increases the pressure on the data archiving server and makes it prone to single points of failure; the processing of other tasks is similar. Therefore, it is necessary to distribute tasks across multiple servers for execution to reduce the task processing pressure on a single server, improve task processing efficiency, and reduce single points of failure.
[0003] Currently, tasks are handled by a single script (archiving service) deployed on multiple servers, with tasks allocated to different servers according to a fixed ratio. However, this task scheduling method still suffers from drawbacks such as uneven task distribution and single points of failure on servers, and needs improvement. Summary of the Invention
[0004] This application provides a task scheduling method and apparatus to avoid the defects of task scheduling methods in related technologies.
[0005] In a first aspect, embodiments of this application provide a task scheduling method applied to a service node in a distributed system, wherein the service node is configured with a target service for consuming target tasks, and the method includes: Read the current task to be consumed and the sequence number of the current task from the backend database. The backend database stores the target tasks added by each of the service nodes. Each target task is assigned a unique sequence number. The current task is any unconsumed target task in the backend database. Read the number of currently active service nodes in the distributed system from the backend database; The service number of this service node is determined based on the number of service nodes. Based on the sequence number of the current task and the service number, determine whether to schedule the current task at this service node.
[0006] Secondly, embodiments of this application also provide a task scheduling device applied to a service node in a distributed system, wherein the service node is deployed with a target service for consuming target tasks, and the device includes: The first reading module is used to read the current task to be consumed and the sequence number of the current task from the backend database. The backend database stores the target tasks added by each of the service nodes. Each target task is assigned a unique sequence number. The current task is any unconsumed target task in the backend database. The second reading module is used to read the number of currently alive service nodes in the distributed system from the backend database. The number determination module is used to determine the service number of this service node based on the number of service nodes. The scheduling determination module is used to determine whether to schedule the current task on this service node based on the sequence number of the current task and the service number.
[0007] Thirdly, embodiments of this application also provide a distributed system, including: multiple service nodes, wherein a target service for consuming target tasks is deployed in the service nodes; The service node is configured to read the current task to be consumed and the sequence number of the current task from the backend database. The backend database stores the target tasks added by each service node, and each target task is assigned a unique sequence number. The current task is any unconsumed target task in the backend database. The service node reads the number of currently active service nodes in the distributed system from the backend database. Based on the number of service nodes, the service node determines its service number. Based on the sequence number of the current task and the service number, the service node determines whether to schedule the current task on its own service node.
[0008] Fourthly, embodiments of this application also provide an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program, when executed by the processor, implements the steps of the method described in the first aspect.
[0009] In a sixth aspect, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.
[0010] The above-mentioned at least one technical solution adopted in the embodiments of this application, on the one hand, realizes the distributed scheduling of target tasks through distributed service nodes, and there is no single point of failure in the service; on the other hand, each service node will determine whether the current task is scheduled on its own node in real time based on the sequence number of the current task and the number of service nodes that are alive in the distributed system. Therefore, it can achieve the purpose of evenly distributing the target task to each alive service node and achieve the effect of distributed and equal scheduling of the target task. Attached Figure Description
[0011] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart illustrating a task scheduling method provided in one embodiment of this application.
[0012] Figure 2 This is a flowchart illustrating a task scheduling method provided in another embodiment of this application.
[0013] Figure 3 This is a flowchart illustrating a task scheduling method provided in another embodiment of this application.
[0014] Figure 4 This is a flowchart illustrating a task scheduling method provided in an embodiment of this application in a practical application.
[0015] Figure 5 This is a schematic diagram of the structure of a task scheduling device provided in one embodiment of this application.
[0016] Figure 6 This is a schematic diagram of the structure of a task scheduling device provided in another embodiment of this application.
[0017] Figure 7 This is a schematic diagram of the structure of a task scheduling device provided in another embodiment of this application.
[0018] Figure 8 This is a schematic diagram of the structure of a task scheduling system provided in an embodiment of this application.
[0019] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0020] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0021] In related technologies, a single script (archiving service) deployed on multiple servers is used to handle the corresponding tasks, and the tasks are allocated to different servers according to a fixed ratio. However, this task scheduling method not only has drawbacks such as uneven task distribution and single point of failure of servers, but also suffers from the following shortcomings when the number of tasks is huge: it cannot be managed as a whole, the management complexity is high, the number of target services that the task request initiating server can be configured with is limited, it is not easy to expand, and the disaster recovery capability is poor.
[0022] To address at least one of the aforementioned technical problems, embodiments of this application provide a task scheduling method and apparatus, as well as a distributed system. The method and apparatus can be applied to service nodes in a distributed system, where target services for consuming target tasks are deployed. It should be noted that the service node in the distributed system can be a physical server or a virtual server.
[0023] The following describes a task scheduling method provided in an embodiment of this application.
[0024] like Figure 1 As shown, an embodiment of this application provides a task scheduling method that may include: Step 101: Read the current task to be consumed and the sequence number of the current task from the backend database.
[0025] The backend database stores the target tasks added by each service node. Each target task is assigned a unique sequence number. The current task is any unconsumed target task in the backend database.
[0026] The target task can be any task that can be scheduled using the task scheduling method provided in the embodiments of this application. The target task may differ in different application scenarios. For example, in the scenario of data archiving in a database, the target task is the data archiving task. For the sake of brevity, the following examples will primarily use the data archiving task in a database as an example.
[0027] The backend database may include, but is not limited to, at least one of the databases with service governance functions such as MySQL, Zookeeper, and Consul.
[0028] Of course, the backend database can also be a device with service governance capabilities.
[0029] Step 102: Read the number of currently active service nodes in the distributed system from the backend database.
[0030] The backend database can obtain the survival status (alive or not alive) of each service node in the distributed system according to a preset method, and feed back the survival status of each service node to each service node through methods such as subscription. Each service node obtains the number of currently alive service nodes in the distributed system by counting its own survival status and that of other service nodes. The preset method may include heartbeat monitoring, etc.
[0031] Step 103: Determine the service number of this service node based on the number of service nodes.
[0032] This step involves dynamically determining the service ID of each surviving service node based on the number of currently surviving service nodes in the distributed system. In other words, in this embodiment, the service ID of each service node may change dynamically rather than being unique and constant. This dynamic change allows for dynamic and balanced scheduling of the target task.
[0033] As an example, step 103 may include: determining the service number of this service node based on the number of service nodes and the preset information of the surviving service nodes in the distributed system, wherein the preset information may include, but is not limited to, at least one of IP address, hostname, ASK code and ID.
[0034] Specifically, the currently surviving service nodes in the distributed system can first be sorted according to preset information of the surviving service nodes in the distributed system, for example, sorted by IP address; then, based on the sorting, the currently surviving service nodes in the distributed system can be numbered in a forward (or backward) order, with the number value between 1 and N, where N represents the number of currently surviving service nodes in the distributed system; finally, each service node can find its own service number by corresponding to its own IP address.
[0035] Step 104: Based on the sequence number of the current task and the service number, determine whether to schedule the current task at this service node.
[0036] In one example, step 104 may include: if the sequence number of the current task is less than the number of service nodes, determining whether the sequence number of the current task is equal to the service number of the service node. If so, then the current task will be scheduled at this service node; If not, then the current task will not be scheduled on this service node.
[0037] In another example, step 104 may include: if the sequence number of the current task is greater than the number of service nodes, determining whether the remainder of the current task's sequence number divided by the number of service nodes plus one is equal to the service number of this service node. If so, then the current task will be scheduled at this service node; If not, then the current task will not be scheduled on this service node.
[0038] Furthermore, if it is determined that the current task is scheduled at this service node, then the current task can be scheduled and consumed to complete the processing of the current task.
[0039] As mentioned earlier, assuming the number of currently active service nodes in the distributed system is N, the sequence number of the current task is M, and the service number of this service node is X, where M, N, and X are positive integers, then if M is less than N, it is further determined whether M is equal to X. If they are equal, the current task is scheduled on this service node; otherwise, the current task is not scheduled on this service node. If M is greater than N, it is further determined whether the remainder Y of M divided by N plus one is equal to X. If they are equal, the current task is scheduled on this service node; otherwise, the current task is not scheduled on this service node.
[0040] The scheduling relationship between tasks and service nodes determined by the two examples above can be represented by Table 1.
[0041] Table 1. Scheduling Relationship between Tasks and Service Nodes
[0042] Of course, if the sequence number of the current task is greater than the number of service nodes, other methods can be used to determine whether to schedule the current task on this service node. For example, directly determine whether the remainder of the sequence number of the current task divided by the number of service nodes is equal to the service number of this service node. If yes, then determine whether to schedule the current task on this service node; otherwise, determine whether to schedule the current task on this service node. Alternatively, determine whether the last digit of the sequence number of the current task is equal to the last digit of the service number of this service node. If yes, then determine whether to schedule the current task on this service node; otherwise, determine whether to schedule the current task on this service node, and so on.
[0043] It is understandable that by dynamically determining whether the current task should be scheduled on this service node based on the current task's sequence number and the service number of this service node, the goal of dynamically and evenly distributing target tasks to various service nodes can be achieved.
[0044] The task scheduling method provided in this application embodiment achieves distributed scheduling of target tasks through distributed service nodes, eliminating single points of failure in the service. On the other hand, each service node determines whether the current task should be scheduled on its node in real time based on the sequence number of the current task and the number of surviving service nodes in the distributed system. Therefore, it can achieve the goal of evenly distributing target tasks to each surviving service node and achieve the effect of distributed and equal scheduling of target tasks.
[0045] Furthermore, due to the idempotency of the target task's scheduling, it can be considered a stateless service. By implementing the task scheduling strategy described above, distributed scheduling of the target task can be achieved. Moreover, when the number of service nodes changes (e.g., a new node is added), a new service number will be calculated during the next task scheduling, thus providing service disaster recovery capabilities.
[0046] Furthermore, the task scheduling scheme provided in this application is an equal scheduling strategy that does not require human intervention, and it relies on few elements (the sequence number of the target task and the number of the service node), with few conflicts between the elements, so it is easy to implement and has high efficiency.
[0047] Optional, such as Figure 2 As shown, an embodiment of this application provides a task scheduling method that, in addition to steps 101 to 104 described above, may further include: Step 105: Add the target task created by this service node to the backend database so that the backend database stores the target task and assigns a unique sequence number to the target task.
[0048] When a service node receives a target task processing request from a parent node, the service node creates the target task and adds it to the backend database. The backend database maintains a list of target tasks; each new target task is added as a new record, and a unique sequence number is assigned to it.
[0049] The sequence numbers of target tasks stored in the backend database increment sequentially according to the order in which the target tasks are added to the backend database. A sequence number for a target task can be a positive integer, and the increment step can be a positive integer greater than or equal to 1.
[0050] It is understandable that assigning sequence numbers to target tasks in the above manner is simple, easy, and efficient.
[0051] Optional, such as Figure 3 As shown, an embodiment of this application provides a task scheduling method that, in addition to steps 101 to 104 described above, may further include: Step 106: When the target service in this service node starts, a heartbeat registration request carrying the unique identifier of this service node is sent to the backend database so that the backend database can monitor the heartbeat information of this service node. The heartbeat information is used to determine whether this service node is alive.
[0052] The backend database can maintain a table that maps unique identifiers of service nodes to their heartbeat information.
[0053] Based on this, step 106 may include: reading the heartbeat information of each service node in the distributed system from the backend database; and determining the number of currently alive service nodes in the distributed system based on the heartbeat information of each service node in the distributed system.
[0054] It is understandable that by registering heartbeat monitoring requests with the backend database, service nodes in a distributed system can enable the backend database to keep track of the number of live service nodes in the distributed system in real time. This allows each service node to read and use the data, thereby achieving dynamic and balanced scheduling of target tasks and avoiding single points of failure in the service.
[0055] Figure 4 The illustration shows a flowchart of a task scheduling method provided in this application in a practical application. In this practical application scenario, the task to be scheduled is a data archiving task in a database (hereinafter referred to as an archiving task), and the target service deployed in the service node of the distributed system is an archiving service, which can consume the archiving task to realize data archiving.
[0056] like Figure 4As shown, in the application scenario of data archiving in a database, the task scheduling method provided in this application embodiment may include: ① Service nodes 411 in the distributed system 41 sequentially add archiving tasks to the backend database 42, so that the backend database 42 stores these archiving tasks and assigns them unique sequence numbers in sequence; ② When the archiving service deployed in the service node 411 starts for the first time, it sends a heartbeat registration request carrying the unique identifier of the service node to the backend database 42, so that the backend database monitors the heartbeat information of the service node, and the heartbeat information is used to determine whether the service node is alive; ③ The archiving service deployed in the service node 411 reads the number of currently alive service nodes in the distributed system 41 from the backend database 42, and determines the service number of the service node based on the number of service nodes; ④ The archiving service deployed in service node 411 reads the current archiving task to be consumed and the sequence number of the current archiving task from the backend database 42, and determines whether to schedule the current archiving task in this service node based on the sequence number of the current archiving task and the service number. If yes, the data corresponding to the current archiving task is archived to the archiving pool 43. Otherwise, step ③ is executed according to the preset cycle to judge the next task.
[0057] The task scheduling method provided in this application embodiment achieves distributed scheduling of archiving tasks through distributed service nodes, eliminating single points of failure. On the other hand, each service node determines whether to schedule the current task on its own node based on the sequence number of the current task and the number of surviving service nodes in the distributed system in real time. Therefore, it can achieve the goal of evenly distributing archiving tasks to each surviving service node and achieve the effect of distributed and equal scheduling of archiving tasks.
[0058] Furthermore, due to the idempotency of the archiving task scheduling itself, it can be considered a stateless service. By implementing the task scheduling strategy described above, distributed scheduling of archiving tasks can be achieved. Moreover, when the number of service nodes changes (e.g., a new node is added), a new service number will be calculated during the next task scheduling, thus providing service disaster recovery capabilities.
[0059] Furthermore, the task scheduling scheme provided in this application is an equal scheduling strategy that does not require human intervention, and it depends on few elements (the sequence number of the archived task and the number of the service node), and there are few conflicts between the elements, so it is easy to implement and has high efficiency.
[0060] The above describes a task scheduling method provided by embodiments of this application. Corresponding to the above method embodiments, embodiments of this application also provide a task scheduling apparatus, which will be described below.
[0061] like Figure 5As shown in the embodiment of this application, a task scheduling device 500 is provided. The device may include: a first reading module 501, a second reading module 502, a number determination module 503, and a scheduling determination module 504.
[0062] The first reading module 501 is used to read the current task to be consumed and the sequence number of the current task from the backend database.
[0063] The backend database stores the target tasks added by each service node. Each target task is assigned a unique sequence number. The current task is any unconsumed target task in the backend database.
[0064] The target task can be any task that can be scheduled using the task scheduling method provided in the embodiments of this application. The target task may differ in different application scenarios. For example, in the scenario of data archiving in a database, the target task is the data archiving task. For the sake of brevity, the following examples will primarily use the data archiving task in a database as an example.
[0065] The backend database may include, but is not limited to, at least one of the databases with service governance functions such as MySQL, Zookeeper, and Consul.
[0066] Of course, the backend database can also be a device with service governance capabilities.
[0067] The second reading module 502 is used to read the number of currently active service nodes in the distributed system from the backend database.
[0068] The backend database can obtain the survival status (alive or not alive) of each service node in the distributed system according to a preset method, and feed back the survival status of each service node to each service node through methods such as subscription. Each service node obtains the number of currently alive service nodes in the distributed system by counting its own survival status and that of other service nodes. The preset method may include heartbeat monitoring, etc.
[0069] The number determination module 503 is used to determine the service number of this service node based on the number of service nodes.
[0070] This step involves dynamically determining the service ID of each surviving service node based on the number of currently surviving service nodes in the distributed system. In other words, in this embodiment, the service ID of each service node may change dynamically rather than being unique and constant. This dynamic change allows for dynamic and balanced scheduling of the target task.
[0071] As an example, the number determination module 503 can be used to: determine the service number of this service node based on the number of service nodes and the preset information of the surviving service nodes in the distributed system, wherein the preset information may include, but is not limited to, at least one of IP address, hostname, ASK code and ID.
[0072] Specifically, the currently surviving service nodes in the distributed system can first be sorted according to preset information of the surviving service nodes in the distributed system, for example, sorted by ASK code; then, based on the sorting, the currently surviving service nodes in the distributed system can be numbered in a forward (or backward) order, with the number value between 1 and N, where N represents the number of currently surviving service nodes in the distributed system; finally, the service node can find its own service number through its own ASK code.
[0073] The scheduling determination module 504 is used to determine whether to schedule the current task at this service node based on the sequence number of the current task and the service number.
[0074] In one example, the scheduling determination module 504 can be used to: determine whether the sequence number of the current task is equal to the service number of the current service node when the sequence number of the current task is less than the number of service nodes; If so, then the current task will be scheduled at this service node; If not, then the current task will not be scheduled on this service node.
[0075] In another example, the scheduling determination module 504 can be used to: determine whether the remainder of the current task's sequence number divided by the number of service nodes plus one equals the service number of the current service node when the current task's sequence number is greater than the number of service nodes. If so, then the current task will be scheduled at this service node; If not, then the current task will not be scheduled on this service node.
[0076] Furthermore, if it is determined that the current task is scheduled at this service node, then the current task can be scheduled and consumed to complete the processing of the current task.
[0077] As mentioned earlier, assuming the number of currently active service nodes in the distributed system is N, the sequence number of the current task is M, and the service number of this service node is X, where M, N, and X are positive integers, then if M is less than N, it is further determined whether M is equal to X. If they are equal, the current task is scheduled on this service node; otherwise, the current task is not scheduled on this service node. If M is greater than N, it is further determined whether the remainder Y of M divided by N plus one is equal to X. If they are equal, the current task is scheduled on this service node; otherwise, the current task is not scheduled on this service node.
[0078] Of course, if the sequence number of the current task is greater than the number of service nodes, other methods can be used to determine whether to schedule the current task on this service node. For example, directly determine whether the remainder of the sequence number of the current task divided by the number of service nodes is equal to the service number of this service node. If yes, then determine whether to schedule the current task on this service node; otherwise, determine whether to schedule the current task on this service node. Alternatively, determine whether the last digit of the sequence number of the current task is equal to the last digit of the service number of this service node. If yes, then determine whether to schedule the current task on this service node; otherwise, determine whether to schedule the current task on this service node, and so on.
[0079] It is understandable that by dynamically determining whether the current task should be scheduled on this service node based on the current task's sequence number and the service number of this service node, the goal of dynamically and evenly distributing target tasks to various service nodes can be achieved.
[0080] The task scheduling device 500 provided in this application embodiment achieves distributed scheduling of target tasks through distributed service nodes, eliminating single points of failure in the service. On the other hand, each service node determines whether the current task should be scheduled on its node in real time based on the sequence number of the current task and the number of surviving service nodes in the distributed system. Therefore, it can achieve the goal of evenly distributing target tasks to each surviving service node and achieve the effect of distributed and equal scheduling of target tasks.
[0081] Furthermore, due to the idempotency of the target task's scheduling, it can be considered a stateless service. By implementing the task scheduling strategy described above, distributed scheduling of the target task can be achieved. Moreover, when the number of service nodes changes (e.g., a new node is added), a new service number will be calculated during the next task scheduling, thus providing service disaster recovery capabilities.
[0082] Furthermore, the task scheduling scheme provided in this application is an equal scheduling strategy that does not require human intervention, and it relies on few elements (the sequence number of the target task and the number of the service node), with few conflicts between the elements, so it is easy to implement and has high efficiency.
[0083] Optional, such as Figure 6 As shown, an embodiment of this application provides a task scheduling device 500, which, in addition to including a first reading module 501, a second reading module 502, a number determination module 503, and a scheduling determination module 504, may also include a task adding module 505.
[0084] The task adding module 505 is used to add the target task created by this service node to the backend database, so that the backend database stores the target task and assigns a unique sequence number to the target task.
[0085] When a service node receives a target task processing request from a parent node, the service node creates the target task and adds it to the backend database. The backend database maintains a list of target tasks; each new target task is added as a new record, and a unique sequence number is assigned to it.
[0086] The sequence numbers of target tasks stored in the backend database increment sequentially according to the order in which the target tasks are added to the backend database. A sequence number for a target task can be a positive integer, and the increment step can be a positive integer greater than or equal to 1.
[0087] It is understandable that assigning sequence numbers to target tasks in the above manner is simple, easy, and efficient.
[0088] Optional, such as Figure 7 As shown, an embodiment of this application provides a task scheduling device 500, which, in addition to including a first reading module 501, a second reading module 502, a number determination module 503, and a scheduling determination module 504, may also include a heartbeat registration module 506.
[0089] The heartbeat registration module 506 is used to send a heartbeat registration request carrying the unique identifier of the service node to the backend database when the target service in this service node starts, so that the backend database can monitor the heartbeat information of this service node. The heartbeat information is used to determine whether the service node is alive.
[0090] The backend database can maintain a table that maps unique identifiers of service nodes to their heartbeat information.
[0091] Based on this, the heartbeat registration module 506 can be used to: read the heartbeat information of each service node in the distributed system from the backend database; and determine the number of currently alive service nodes in the distributed system based on the heartbeat information of each service node in the distributed system.
[0092] It is understandable that by registering heartbeat monitoring requests with the backend database, service nodes in a distributed system can enable the backend database to keep track of the number of live service nodes in the distributed system in real time. This allows each service node to read and use the data, thereby achieving dynamic and balanced scheduling of target tasks and avoiding single points of failure in the service.
[0093] The task scheduling device provided in this application embodiment is used in the task scheduling method provided in this application embodiment and can achieve the same technical effect. The relevant parts can be referred to each other.
[0094] like Figure 8 As shown in the embodiment of this application, a distributed system 80 is also provided. The distributed system 80 may include: multiple service nodes 801, and the service nodes 801 are equipped with target services for consuming target tasks.
[0095] Service node 801 is used to read the current task to be consumed and the sequence number of the current task from the backend database 81. The backend database 81 stores the target tasks added by each service node. Each target task is assigned a unique sequence number. The current task is any unconsumed target task in the backend database 81. Service node 801 reads the number of currently active service nodes in the distributed system from the backend database 81. Service node 801 determines its service number based on the number of service nodes. Service node 801 determines whether to schedule the current task on its service node based on the sequence number and the service number of the current task.
[0096] The distributed system provided in this application uses the task scheduling method provided in this application, and therefore can achieve the same technical effect as the task scheduling method provided in this application. The relevant parts can be referred to each other, and will not be described again.
[0097] Figure 9 The diagram shown is a structural schematic of an electronic device provided in an embodiment of this application. Please refer to it. Figure 9 At the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and memory. The memory may include main memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for other business operations.
[0098] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 9 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.
[0099] Memory is used to store programs. Specifically, programs may include program code, which includes computer operation instructions. Memory may include main memory and non-volatile memory, and provides instructions and data to the processor.
[0100] The processor retrieves the corresponding computer program from non-volatile memory into main memory and then runs it, forming a task scheduling device at the logical level. The processor executes the program stored in memory and specifically performs the task scheduling method provided in the embodiments of this application.
[0101] The above is as stated in this application. Figures 5 to 7The method executed by the task scheduling device disclosed in any embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the field, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor obtains information from the memory and, in conjunction with its hardware, completes the steps of the above method.
[0102] This application also proposes a computer-readable storage medium that stores one or more programs, the programs including instructions that, when executed by an electronic device including multiple applications, enable the electronic device to perform... Figures 5 to 7 The method executed by the task scheduling device in any embodiment is specifically used to execute the task scheduling method provided in the embodiments of this application.
[0103] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0104] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0105] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0106] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0107] It should be noted that all embodiments in this application are described in a related manner, and the same or similar parts between the embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments.
[0108] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0109] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.
Claims
1. A task scheduling method, characterized in that, A service node in a distributed system, wherein the service node is deployed with a target service for consuming a target task, the method includes: Read the current task to be consumed and the sequence number of the current task from the backend database. The backend database stores the target tasks added by each of the service nodes. Each target task is assigned a unique sequence number. The current task is any unconsumed target task in the backend database. Read the number of currently active service nodes in the distributed system from the backend database; The service number of this service node is determined based on the number of service nodes. Based on the sequence number of the current task and the service number, determine whether to schedule the current task at this service node.
2. The method according to claim 1, characterized in that, The method further includes: Add the target task created by this service node to the backend database so that the backend database stores the target task and assigns a unique sequence number to the target task.
3. The method according to claim 2, characterized in that, The sequence number of the target task stored in the backend database increases progressively according to the order in which the target task is added to the backend database.
4. The method according to claim 1, characterized in that, The method further includes: When the target service in this service node starts, it sends a heartbeat registration request carrying the unique identifier of this service node to the backend database so that the backend database can monitor the heartbeat information of this service node. The heartbeat information is used to determine whether this service node is alive.
5. The method according to claim 4, characterized in that, The step of reading the number of currently active service nodes in the distributed system from the backend database includes: Read the heartbeat information of each service node in the distributed system from the backend database; Based on the heartbeat information of each service node in the distributed system, the number of currently alive service nodes in the distributed system is determined.
6. The method according to claim 1, characterized in that, Determining the service number of this service node based on the number of service nodes includes: Based on the number of service nodes and the preset information of the surviving service nodes in the distributed system, the service number of this service node is determined, wherein the preset information includes at least one of IP address, hostname, ASK code and ID.
7. The method according to claim 1, characterized in that, Determining whether to schedule the current task on this service node based on the sequence number and service number of the current task includes: If the sequence number of the current task is less than the number of service nodes, determine whether the sequence number of the current task is equal to the service number. If so, then the current task will be scheduled at this service node; If not, then the current task will not be scheduled on this service node.
8. The method according to claim 1, characterized in that, Determining whether to schedule the current task on this service node based on the sequence number and service number of the current task includes: If the sequence number of the current task is greater than the number of service nodes, determine whether the remainder obtained by dividing the sequence number of the current task by the number of service nodes plus one is equal to the service number. If so, then the current task will be scheduled at this service node; If not, then the current task will not be scheduled on this service node.
9. The method according to any one of claims 1-8, characterized in that, The backend database includes at least one of MySQL, Zookeeper, and Consul.
10. A task scheduling device, characterized in that, A service node used in a distributed system, wherein the service node is deployed with a target service for consuming a target task, the device comprising: The first reading module is used to read the current task to be consumed and the sequence number of the current task from the backend database. The backend database stores the target tasks added by each of the service nodes. Each target task is assigned a unique sequence number. The current task is any unconsumed target task in the backend database. The second reading module is used to read the number of currently alive service nodes in the distributed system from the backend database. The number determination module is used to determine the service number of this service node based on the number of service nodes. The scheduling determination module is used to determine whether to schedule the current task on this service node based on the sequence number of the current task and the service number.