Thread-based task processing method and device, electronic equipment and storage medium

Abstract

The application provides a thread-based task processing method and device, electronic equipment and storage medium, and belongs to the technical field of computers. The method comprises the following steps: dividing a to-be-processed task into multiple subtasks according to a business scenario; determining time allocation information of each subtask according to a business scenario to which each subtask belongs; obtaining information of processing resources, wherein the information of the processing resources is used for reflecting types of the processing resources and quantities of the processing resources; determining thread configuration information of each subtask according to the information of the processing resources and attribute information of each subtask; configuring threads for each subtask according to the time allocation information and the thread configuration information of each subtask, and executing the corresponding subtask through the configured threads. According to the embodiment of the application, the number of threads can be reasonably set, and the resource utilization rate is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a thread-based task processing method and apparatus, electronic device, and storage medium. Background Technology

[0002] Data flow and resource allocation (e.g., list transfer) have become indispensable operations in enterprise operations. Related technologies typically employ either built-in thread pools or dynamic thread pools to handle these tasks. When using built-in thread pools, a fixed number of threads are usually set. When using dynamic thread pools, the number of threads is typically adjusted manually. However, the thread count settings in these methods may be unreasonable, easily leading to low resource utilization. Summary of the Invention

[0003] This application provides a thread-based task processing method, apparatus, electronic device, and storage medium, which can reasonably set the number of threads and improve resource utilization.

[0004] Firstly, this application provides a thread-based task processing method, which includes: dividing a task to be processed into multiple subtasks according to a business scenario; determining time allocation information for each subtask based on the business scenario to which each subtask belongs, wherein the time allocation information is used to characterize the processing time allocated to the subtask under different processing states; obtaining information on processing resources, wherein the information on processing resources is used to reflect the type and quantity of processing resources; determining thread configuration information for each subtask based on the information on processing resources and the attribute information of each subtask, wherein the thread configuration information is used to characterize the thread type and thread quantity configured for the subtask under different processing states; configuring threads for each subtask based on the time allocation information and the thread configuration information, and executing the corresponding subtask through the configured threads.

[0005] Secondly, this application provides a thread-based task processing device, comprising: a partitioning module for dividing a task to be processed into multiple subtasks according to a business scenario; an allocation module for determining time allocation information for each subtask according to the business scenario to which each subtask belongs, wherein the time allocation information is used to characterize the processing time allocated to the subtask under different processing states; an acquisition module for acquiring information on processing resources, wherein the information on processing resources is used to reflect the type and quantity of processing resources; a determination module for determining thread configuration information for each subtask according to the information on processing resources and the attribute information of each subtask, wherein the thread configuration information is used to characterize the thread type and thread quantity configured for the subtask under different processing states; and a configuration module for configuring threads for each subtask according to the time allocation information and the thread configuration information, and executing the corresponding subtask through the configured threads.

[0006] Thirdly, this application provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, and the one or more computer programs are executed by the at least one processor to enable the at least one processor to perform the above-described thread-based task processing method.

[0007] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the above-described thread-based task processing method.

[0008] The embodiments provided in this application firstly, upon receiving a task request, divide the task to be processed corresponding to the task request into multiple subtasks according to the business scenario, facilitating subsequent time-slicing allocation for the corresponding subtasks based on different business scenarios; secondly, based on the business scenario to which each subtask belongs, determine the time allocation information for each subtask, wherein the time allocation information is used to characterize the processing time allocated to the subtask under different processing states, thus clarifying the subtasks to be executed first in different time periods and appropriately allocating processing resources to these subtasks, thereby optimizing the allocation of processing resources; thirdly, obtain the information of processing resources, which reflects the type and quantity of processing resources; and finally, based on the information of processing resources and the attribute information of each subtask, determine the thread of each subtask. The process configuration information, including thread configuration information, is used to characterize the thread type and number configured for each subtask in each processing state. This processing method generates matching thread configuration information for each subtask based on its resource requirements in different processing states, allowing for the configuration of appropriate threads for subtasks in different processing states. Finally, based on the time allocation information and thread configuration information of each subtask, threads are configured for each subtask, and the corresponding subtasks are executed through the configured threads. This process balances time and processing resources, ensuring that subtasks in the target time slice receive relatively more processing resources, while subtasks in non-target time slices maintain a certain processing capacity with fewer processing resources. This optimizes the allocation of processing resources and improves resource utilization.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0010] The accompanying drawings are provided to further illustrate the present application and form part of the specification. They are used together with the embodiments of the present application to explain the application and do not constitute a limitation thereof. The above and other features and advantages will become more apparent to those skilled in the art from the detailed example embodiments described with reference to the accompanying drawings, in which:

[0011] Figure 1 A flowchart illustrating a thread-based task processing method provided in this application embodiment;

[0012] Figure 2 A schematic diagram of a server thread configuration provided in an embodiment of this application;

[0013] Figure 3 A schematic diagram illustrating a thread-based task processing method provided in an embodiment of this application;

[0014] Figure 4 A flowchart illustrating a thread-based task processing method provided in an embodiment of this application;

[0015] Figure 5 A block diagram of a thread-based task processing device provided in an embodiment of this application;

[0016] Figure 6 This is a block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the technical solutions of this application, exemplary embodiments of this application are described below in conjunction with the accompanying drawings, including various details of the embodiments of this application to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0018] Where there is no conflict, the various embodiments of this application and the features thereof may be combined with each other.

[0019] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0020] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0021] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this application, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined herein.

[0022] List processing is a crucial application of data flow and resource allocation, applicable to scenarios such as telemarketing. The prime times for telemarketing are typically 9-11 AM and 1-3 PM; improving list processing efficiency during these periods significantly impacts marketing effectiveness.

[0023] In related technologies, either a fixed number of threads are set for list processing, or the number of threads is manually adjusted and processed using the adjusted threads. Setting a fixed number of threads cannot be flexibly adjusted according to the processing volume of different tasks, which may lead to resource shortages or low resource utilization. On the other hand, manually adjusting the number of threads may result in an unreasonable number of threads, similarly leading to resource shortages or low resource utilization.

[0024] In view of this, embodiments of this application provide a thread-based task processing method and apparatus, electronic device, and storage medium.

[0025] In this embodiment, firstly, upon receiving a task request, the task to be processed corresponding to the task request is divided into multiple subtasks according to the business scenario, facilitating subsequent time-slicing allocation for the corresponding subtasks based on different business scenarios. Secondly, based on the business scenario to which each subtask belongs, the time allocation information for each subtask is determined. This time allocation information characterizes the processing time allocated to the subtask under different processing states, thus clarifying the subtasks to be executed first in different time periods and appropriately allocating processing resources to these subtasks, thereby optimizing the allocation of processing resources. Information on processing resources is obtained, reflecting the type and quantity of processing resources. Furthermore, based on the information on processing resources and the attribute information of each subtask, the thread of each subtask is determined. Configuration information, specifically thread configuration information, characterizes the thread type and number configured for each subtask in each processing state. This process generates matching thread configuration information for each subtask based on its resource requirements in different processing states, allowing for the appropriate thread configuration for subtasks in different states. Finally, based on the time allocation and thread configuration information of each subtask, threads are configured for each subtask, and the configured threads execute the corresponding subtasks. This process balances time and processing resources, ensuring that subtasks in the target time slice receive relatively more processing resources, while subtasks in non-target time slices maintain a certain processing capacity with fewer resources. This optimizes the allocation of processing resources and improves resource utilization.

[0026] The thread-based task processing method according to embodiments of this application can be executed by electronic devices such as terminal devices or servers. Terminal devices can be in-vehicle devices, user equipment (UE), mobile devices, user terminals, terminals, cellular phones, cordless phones, personal digital assistants (PDAs), handheld devices, computing devices, in-vehicle devices, wearable devices, etc. The method can be implemented by a processor calling computer-readable program instructions stored in memory. Alternatively, the method can be executed by a server.

[0027] In a first aspect, embodiments of this application provide a thread-based task processing method.

[0028] Figure 1 A flowchart illustrating a thread-based task processing method provided in an embodiment of this application. (Refer to...) Figure 1 The thread-based task processing method includes:

[0029] In step S11, the task to be processed is divided into multiple sub-tasks according to the business scenario.

[0030] In some optional implementations, business scenarios can be used to analyze business processes or procedures. This primarily focuses on the operational logic of a specific type of business or a set of processes within a particular environment. Based on this, for a task to be processed, it can be divided into sub-tasks corresponding to various business scenarios, depending on changes in the business scenario.

[0031] For example, the task to be processed includes a list processing task, and the business scenario includes at least one of the following: list receiving scenario, list cleaning scenario, list layering scenario, list allocation scenario, list dialing scenario, and list decision scenario. Correspondingly, the sub-tasks include at least one of the following: list receiving sub-task, list cleaning sub-task, list layering sub-task, list allocation sub-task, list dialing sub-task, and list decision sub-task.

[0032] It should be noted that there are certain relationships between the various business scenarios. For example, typically, the list cleaning scenario will only begin after the list receiving scenario is completed; and the list dialing scenario will only begin after the list allocation scenario is completed.

[0033] In step S12, the time allocation information for each subtask is determined based on the business scenario to which each subtask belongs.

[0034] In some optional implementations, time allocation information is used to characterize the processing time allocated to subtasks under different processing states. In other words, in this embodiment, different processing states are set for each subtask, and corresponding processing time is allocated to subtasks in different states. Since the amount and / or type of processing resources required by subtasks may differ under different processing states, associating processing states with processing time ensures that reasonable processing resources are allocated to the corresponding subtasks within the appropriate time, enabling each subtask to be executed in a matching processing state. Compared to the direct sequential execution of subtasks in related technologies, this embodiment makes the allocation of processing resources and processing time more scientific and reasonable, thereby improving resource utilization.

[0035] In some optional implementations, the processing state of a subtask can include an active state and a connected state. When a subtask is active, processing resources are appropriately allocated to it to ensure efficient execution (i.e., execution with high resource configuration). When a subtask is connected, only a small amount of processing resources are allocated (i.e., execution with low resource configuration), just enough to ensure sufficient processing capacity (remaining processing resources can be allocated to subtasks currently in the active state).

[0036] In some alternative implementations, the time allocation information includes target time slices and non-target time slices for each subtask, and the subtask is active in the target time slice and held in the non-target time slice.

[0037] For example, the business scenarios for a list processing task include list receiving, list cleaning, list layering, list allocation, and list dialing. Considering the processing volume of this list processing task, the processing time is determined to be from 02:00 to 18:00. Furthermore, considering the correlation between the business scenarios of each subtask and the optimal time to process each subtask (e.g., the optimal time for dialing is from 09:00 to 18:00), the target time slice for the list receiving subtask is set to 02:00 to 04:00, and the non-target time slice is set to 04:00 to 18:00. During the period from 02:00 to 04:00, the list receiving subtask is in an active state, and during the period from 04:00 to 18:00, the list receiving subtask is in a connected state.

[0038] Similarly, the target time slice for the list cleaning subtask is set to 04:00 to 07:00, with the remaining time being non-target time slices. During the 04:00 to 07:00 period, the list cleaning subtask is active, and during the remaining time, it is connected. The target time slice for the list layering subtask is set to 07:00 to 08:00, with the remaining time being non-target time slices. During the 07:00 to 08:00 period, the list layering subtask is active, and during the remaining time, it is connected. The target time slice for the list allocation subtask is set to 08:00 to 09:00, with the remaining time being a non-target time slice. During the period from 08:00 to 09:00, the list allocation subtask is in an active state, and during the remaining time, the list allocation subtask is in a connected state. The target time slice for the list dialing subtask is set to 09:00 to 18:00, with the remaining time being a non-target time slice. During the period from 09:00 to 18:00, the list dialing subtask is in an active state, and during the remaining time, the list dialing subtask is in a connected state.

[0039] In some alternative implementations, the processing state of a subtask may also include a guaranteed state. When a guaranteed state is used to process a subtask, the required processing resources are less than those required in the active state, but greater than those required in the connected state.

[0040] For example, if a subtask is executed in an active state within a target time slice corresponding to a subtask, and a preset condition is detected, the subtask is adjusted from the active state to the guaranteed state, and the corresponding processing resources are adaptively adjusted.

[0041] For example, if, between 08:00 and 09:00, a first processing resource (assuming the quantity of the first processing resource is x1) is allocated to the list allocation subtask in an active state, and the list allocation subtask is executed based on the allocated first processing resource. When a preset condition is detected, a second processing resource (assuming the quantity of the second processing resource is x2, and x2 is less than x1) is allocated to the list allocation subtask in a guaranteed state, and the list allocation subtask continues to be executed based on the allocated second processing resource.

[0042] In summary, for any subtask, its processing state can include three types: active state, connected state, and guaranteed state. The active state and guaranteed state correspond to the target time slice of the subtask, while the connected state corresponds to the non-target time slice of the subtask. The amount of processing resources required for each processing state decreases in the order of active state, guaranteed state, and connected state.

[0043] In step S13, information about the processing resources is obtained.

[0044] In some alternative implementations, the information about the processing resources is used to reflect the type and quantity of the processing resources.

[0045] For example, processing resources are a general term for resources that provide task processing capabilities, which may include computing-type processing resources (i.e., computing resources), storage-type processing resources (i.e., storage resources), and network-type storage resources (i.e., network resources), etc., and this application embodiment does not limit this. Among them, computing resources are related to the number of central processing units (CPUs), the number of cores, etc.; storage resources can be further subdivided into cache, memory, external storage (e.g., hard disks), etc., and the quantity of storage resources is related to the size of their storage space; the quantity of network resources is related to the network type (e.g., wireless communication, wired communication), network bandwidth, etc.

[0046] It should be noted that the above examples of resource processing are merely illustrative and are not intended to limit the scope of this application.

[0047] In step S14, the thread configuration information of each subtask is determined based on the information of the processing resources and the attribute information of each subtask.

[0048] In some optional implementations, thread configuration information is used to characterize the thread type and number of threads configured for subtasks under different processing states.

[0049] For example, thread types include core threads and available threads, where available threads can be considered as the number of threads that can be used, which should be greater than or equal to the number of core threads.

[0050] For example, if the number of core threads is coreSize, the maximum number of threads (which can be considered as available threads) is maxSize, and the number of waiting queues is queueSize, where coreSize ≤ maxSize, then during task processing, if the number of tasks is less than the number of core threads, the core threads are used directly to process the tasks. If the number of tasks is between coreSize and maxSize, new threads are created until the sum of the number of newly created threads and the number of core threads equals the maximum number of threads. If the number of tasks is greater than the maximum number of threads, the excess tasks are placed in the waiting queue, where the number of waiting queues is less than or equal to queueSize.

[0051] In some optional implementations, the processing state of the subtask includes an active state, and the thread configuration information includes at least the number of first core threads, which is the number of core threads configured when the subtask is in an active state.

[0052] Accordingly, in some optional implementations, based on the information about the processing resources and the attribute information of each subtask, the number of first core threads in the thread configuration information of each subtask is determined, including:

[0053] Based on the information about the processing resources, determine the preset indicators for load testing of the processing resources and the adjustment ratio for adjusting the load test extreme values ​​of the preset indicators; perform load testing on the processing resources and determine the load test extreme values ​​of the preset indicators; based on the attribute information of each subtask, determine the number of transactions per data item in each subtask; based on the number of transactions per data item in each subtask and the load test extreme values ​​of the preset indicators, determine the processing time per data item in each subtask; based on the processing time per data item in each subtask, the load test extreme values ​​of the preset indicators, and the adjustment ratio, determine the number of first core threads.

[0054] In other words, on the one hand, stress testing is performed on processing resources to obtain the extreme values ​​of various preset indicators; on the other hand, the number of transactions per data item in each subtask is determined, and based on this, the processing time per data item in each subtask is determined. Finally, based on the processing time per data item in each subtask, the extreme values ​​of the preset indicators, and the adjustment ratio, the number of first core threads is determined. Since the number of first core threads is obtained through stress testing, the overhead of processing resources is high when processing subtasks based on the first core threads. Therefore, the first core threads are set as the number of core threads in the active state.

[0055] It should be noted that a single data entry can be data determined based on experience, statistical data, and the content of the task to be processed, which facilitates the quantification of the processing volume of each sub-task. It can be a single data record or a data table, and this application embodiment does not impose any restrictions on this. For example, in a list processing task, a single data entry can be a list record.

[0056] In the above processing, to facilitate determining the time required for each subtask to process a single piece of data (i.e., the processing time for a single piece of data), the workload of each subtask in processing a single piece of data is quantified as the number of transactions. Typically, a transaction can include multiple operations, which can be considered a complete logical processing unit. Furthermore, for ease of comparison, in this embodiment, when determining or dividing transactions, efforts are made to ensure a relatively balanced number and complexity of operations across transactions, thereby making the processing times of each transaction more similar.

[0057] For example, for the list receiving subtask, a transaction for a single list record can include a receive transaction (which may include multiple operations) and a store transaction. Therefore, the number of transactions for a single data record in the list receiving subtask can be determined to be 2. The number of transactions for other subtasks can be determined in a similar way, which will not be described further here.

[0058] In some optional implementations, the number of first core threads is determined based on the processing time of a single data item for each subtask, the stress test extreme values ​​of preset metrics, and the adjustment ratio, including:

[0059] Based on the stress test extreme values ​​and adjustment ratios of the preset indicators, determine the allowable thresholds of the preset indicators; initialize the number of test core threads; adjust the number of test core threads to meet the preset threshold allowable conditions, and determine the number of first core threads based on the current number of test core threads; wherein, the threshold allowable conditions are that the actual values ​​of each preset indicator are less than or equal to the allowable thresholds, and the amount of data processed per unit time reaches the maximum value.

[0060] For example, after initializing the number of test core threads, the number of test core threads can be gradually increased so that the number of data processed per unit time reaches the maximum value when the test core threads execute subtasks based on the processing time of a single piece of data and the actual values ​​of each preset indicator are less than or equal to the allowable threshold; the number of test core threads corresponding to the maximum value is determined as the first core thread number.

[0061] For example, the stress test extreme value of the preset index is y. max If the adjustment ratio is r (0 < r < 1), then the allowable threshold of the preset indicator is determined as thr = r × y. max First, the number of test core threads is initialized, and the initial number of test core threads is determined to be k1 (k1≥1). Through these k1 test core threads, subtasks are executed with a single data processing time to obtain the actual value y1 of the preset indicator and the number of data processed per unit time q1.

[0062] If the actual value y1 is less than the allowable error thr, the number of test core threads will be increased from k1 to k2. Then, through these k2 test core threads, subtasks will be executed with a single data processing time to obtain the actual value y2 of the preset indicator and the number of data processed per unit time q2.

[0063] If the actual value y2 is less than the tolerance error thr, the number of test core threads is increased from k2 to k3. This continues until the number of test core threads is increased to kt. Using these kt test core threads, subtasks are executed with a single data processing time to obtain the actual value yt of the preset indicator and the number of data processed per unit time qt, where yt is less than or equal to the tolerance error thr. When the number of test core threads is increased to k(t+1), the actual value y(t+1) of the preset indicator and the number of data processed per unit time q(t+1) are obtained, and y(t+1) is greater than the tolerance error thr. Therefore, it can be determined that when the number of test cores is kt and the actual value of the preset indicator is less than or equal to the tolerance threshold, the number of data processed per unit time reaches its maximum value. Thus, kt is determined as the first number of core threads.

[0064] It's important to note that thread configuration information can include not only the number of core threads, but also the number of maximum threads and the number of threads in the first waiting queue. The maximum number of threads should be greater than or equal to the number of core threads, while the number of threads in the first waiting queue can be set based on experience, statistical data, or processing efficiency. Core threads, maximum threads, and waiting queues can be implemented using thread pool technology. Thread pools can schedule and reuse one or more threads in a unified way, avoiding the overhead caused by too many threads, reducing resource consumption, improving response speed, and enhancing thread manageability.

[0065] For example, the thread configuration information for a certain subtask includes: in each instance, the number of first core threads = 12, the number of first maximum threads = 12, and the number of first waiting queues = 6. An instance can be considered a physical machine or a virtual processor configured within a physical machine with relatively independent processing capabilities; this embodiment does not impose such limitations. Further, if the processing time for a single piece of data in the subtask is determined to be 100ms, then for this subtask, the number of data processed per unit time (taking 1 second as an example, 1s = 1000ms) is: number of first core threads × (1000ms / 100ms) × number of instances.

[0066] In some optional implementations, the processing state of the subtask also includes the connection state, and the thread configuration information also includes the number of second core threads, which is the number of core threads configured when the subtask is in the connection state.

[0067] Accordingly, in some optional implementations, the number of second core threads included in the thread configuration information of each subtask is determined based on the information of the processing resources and the attribute information of each subtask, including:

[0068] Based on the information about the processing resources, determine the maximum number of threads, where the maximum number of threads is the maximum number of threads that the processing resources can support. Based on the maximum number of threads and the number of first core threads for each subtask, determine the remaining number of core threads. Based on the remaining number of core threads, determine the number of second core threads for each subtask.

[0069] In other words, after determining the maximum number of threads and the first number of core threads to allocate to subtasks within the target time slice, the difference between the two is the remaining number of core threads. Then, based on the remaining number of core threads, the second number of core threads that can be allocated to subtasks outside the target time slice can be determined.

[0070] For example, if the task to be processed includes subtask 1, subtask 2, and subtask 3, and the maximum number of threads is p max (p max ≥1), the number of core threads in the first core slice of subtask 1 at its target time is p1, the number of core threads in the first core slice of subtask 2 at its target time is p2, and the number of core threads in the first core slice of subtask 3 at its target time is p3. Therefore, for subtask 1, the remaining number of core threads is p. re 1 = p max -p1, therefore, the number of second cores that can be allocated to subtasks 2 and 3 respectively is |p re 1 / 2|, where || represents the floor function. In other words, within the target time slice corresponding to subtask 1, subtask 1 occupies p1 core threads, while subtask 2 and subtask 3 each occupy |p re 1 / 2 | Core threads.

[0071] Similarly, for subtask 2, the number of remaining core threads is p. re 2 = p max -p2, therefore, the number of second cores that can be allocated to subtask 1 and subtask 3 respectively is |p re 2 / 2|. In other words, within the target time slice corresponding to subtask 2, subtask 2 occupies p2 core threads, while subtask 1 and subtask 3 each occupy |p re 2 / 2 | Core threads.

[0072] Furthermore, for subtask 3, the remaining number of core threads is p. re 3 = p max -p3, therefore, the number of second cores that can be allocated to subtask 1 and subtask 2 respectively is |p re 3 / 2|. In other words, within the target time slice corresponding to subtask 3, subtask 3 occupies p3 core threads, while subtask 1 and subtask 2 each occupy |pre 3 / 2 | Core threads.

[0073] In some alternative implementations, the number of second core threads can be set based on experience, statistical data, simulation data, etc. For example, based on experience, the number of second core threads can be set to 1.

[0074] It should be noted that the thread configuration information may include not only the number of second core threads, but also the number of second maximum threads and the number of second waiting queues. The number of second maximum threads should be greater than or equal to the number of second core threads, and the number of second waiting queues can be set based on experience, statistical data, or processing efficiency.

[0075] For example, the thread configuration information for a certain subtask includes: in each instance, the number of second core threads is 1, the number of second maximum threads is 1, and the number of second waiting queues is 0.

[0076] The above content discloses how thread configuration information is determined for subtasks in the active and connected states. In some optional implementations, the processing state of a subtask also includes a guaranteed state. Correspondingly, the thread configuration information includes the number of third core threads, which is the number of core threads configured for the subtask in the guaranteed state. The attribute information of each subtask includes its expected processing volume and expected processing time. The resource overhead required for the guaranteed state is between that of the active and connected states.

[0077] In some optional implementations, the number of third-core threads, including those in the thread configuration information of each subtask, is determined based on the information about the processing resources and the attribute information of each subtask.

[0078] Based on the processing time of a single data item and the information on processing resources for each subtask, determine the maximum number of core threads that can meet the expected processing volume and expected processing time of each subtask, and set the maximum number as the number of third core threads.

[0079] For example, the information about processing resources also includes the number of instances. For a subtask, the expected processing volume is w, the expected processing time is h, the number of instances corresponding to the processing resources is m, the processing time for a single data item is a (in milliseconds), and the number of third core threads in each instance is n. Then, (1000ms / a)×m×n×h≥w should be satisfied. Therefore, n≥w / {(1000ms / a)×m×h}. Here, (1000ms / a) represents the number of data items (or data entries) that can be processed per second. (1000ms / a)×m×n×h represents the number of data items that m instances can process within h using n core threads. This number must be greater than or equal to the expected processing volume to meet the processing requirements of the subtask. Thus, the number of third core threads can be calculated.

[0080] For example, for the list receiving subtask, the expected processing volume is 1 million records, the expected processing time is 2 hours (7200ms), the processing time per record is 100ms, and the number of instances is 4. Based on this, we can construct a formula for the number of third core threads: (1000 / 100)×4×n×7200≥1000000. Solving this, we know that n>3.5. Further rounding determines that n is 4, thus determining that the number of third core threads for the list receiving subtask is 4. Furthermore, based on experience, we can set the maximum number of third threads to 4, and the number of third waiting queues to 4 as well.

[0081] It should be noted that in some optional implementations, after determining the maximum number as the number of the third core threads, the following are also included:

[0082] The number of threads in the third core is compared with the thread count threshold to obtain the comparison result; the thread count threshold is determined based on the maximum number of threads that the processing resources can support; the comparison result is used to determine whether the amount of processing resources needs to be increased.

[0083] In other words, after determining the number of third core threads, n, it is necessary to ensure that the processing resources have the capacity to create n core threads. Therefore, the amount of processing resources needs to be increased by comparing the number of third core threads with a thread count threshold. For example, if the comparison result shows that the number of third core threads is less than or equal to the thread count threshold, it is determined that no additional processing resources are needed. If the comparison result shows that the number of third core threads is greater than the thread count threshold, it is determined that the current processing resources cannot meet the requirement of creating n core threads, and therefore, the amount of processing resources needs to be increased. The amount of additional processing resources can be determined based on the difference between the number of third core threads and the thread count threshold, and this embodiment does not impose any restrictions on this.

[0084] In step S15, threads are configured for each subtask based on the time allocation information and thread configuration information of each subtask, and the corresponding subtasks are executed through the configured threads.

[0085] In some optional implementations, thread configuration information can characterize the thread type and number of threads configured for subtasks under different processing states. Moreover, since the processing state of a subtask is related to whether it is in the corresponding target time slice, the thread configuration information can be used to determine the corresponding thread type and number of threads for each subtask for its respective target time slice and non-target time slice, and then perform thread configuration processing so that each subtask can perform task processing through the configured threads.

[0086] In some optional implementations, the time allocation information includes the target time slice and non-target time slice for each subtask, with the subtask being active in the target time slice and in a held-down state in the non-target time slice. Correspondingly, based on the time allocation information and thread configuration information of each subtask, threads are configured for each subtask, and the corresponding subtasks are executed through the configured threads, including:

[0087] For each subtask, if the current moment belongs to the target time slice of the subtask based on the subtask's time allocation information, a core thread is configured for the subtask based on the first core thread count, and the subtask is executed through the core thread; if the current moment belongs to the non-target time slice of the subtask based on the subtask's time allocation information, a core thread is configured for the subtask based on the second core thread count, and the subtask is executed through the core thread.

[0088] For example, if the processing time of the task to be processed is T, T is composed of three time periods t1, t2, and t3 in sequence, and the task to be processed includes subtask 1, subtask 2, and subtask 3, the target time slice of subtask 1 is t1 (its non-target time slices include t2 and t3), the target time slice of subtask 2 is t2 (its non-target time slices include t1 and t3), and the target time slice of subtask 1 is t3 (its non-target time slices include t1 and t2).

[0089] Furthermore, for subtask 1, the first core thread count in its target time slice t1 is p11, and the second core thread count in non-target time slices (including t2 and t3) is p12; for subtask 2, the first core thread count in its target time slice t2 is p21, and the second core thread count in non-target time slices (including t1 and t3) is p22; for subtask 3, the first core thread count in its target time slice t3 is p31, and the second core thread count in non-target time slices (including t1 and t2) is p32. Here, p12 can be set empirically and remains the same in t2 and t3, while p22 and p32 are similar.

[0090] Therefore, during time period t1, p11 first core threads are configured for subtask 1, and subtask 1 is executed through p11 first core threads; at the same time, p22 second core threads are configured for subtask 2, and subtask 2 is executed through p22 second core threads; p32 second core threads are configured for subtask 3, and subtask 3 is executed through p32 second core threads.

[0091] Similarly, during time period t2, p21 first core threads are configured for subtask 2, and subtask 2 is executed through p21 first core threads; at the same time, p12 second core threads are configured for subtask 1, and subtask 1 is executed through p12 second core threads; p32 second core threads are configured for subtask 3, and subtask 3 is executed through p32 second core threads.

[0092] During time period t3, configure p31 first core threads for subtask 3 and execute subtask 3 through p31 first core threads; at the same time, configure p12 second core threads for subtask 1 and execute subtask 1 through p12 second core threads; configure p22 second core threads for subtask 2 and execute subtask 2 through p22 second core threads.

[0093] For subtasks 1 to 3, in some optional implementations, the number of core threads in the first core thread of subtask 1 in its target time slice t1 can be determined as p11, the number of core threads in the second core thread of the non-target time slice t2 is p122, and the number of core threads in the second core thread of the non-target time slice t3 is p123; the number of core threads in the first core thread of subtask 2 in its target time slice t2 is p21, the number of core threads in the second core thread of the non-target time slice t1 is p221, and the number of core threads in the second core thread of the non-target time slice t3 is p223; the number of core threads in the first core thread of subtask 3 in its target time slice t3 is p31, the number of core threads in the second core thread of the non-target time slice t1 is p321, and the number of core threads in the second core thread of the non-target time slice t2 is p322.

[0094] Correspondingly, during the time period t1, p11 first core threads are configured for subtask 1, and subtask 1 is executed through p11 first core threads; at the same time, p221 second core threads are configured for subtask 2, and subtask 2 is executed through p221 second core threads; p321 second core threads are configured for subtask 3, and subtask 3 is executed through p321 second core threads.

[0095] During time period t2, configure p21 first core threads for subtask 2 and execute subtask 2 through p21 first core threads; at the same time, configure p122 second core threads for subtask 1 and execute subtask 1 through p122 second core threads; configure p322 second core threads for subtask 3 and execute subtask 3 through p322 second core threads.

[0096] During time period t3, configure p31 first core threads for subtask 3 and execute subtask 3 through p31 first core threads; at the same time, configure p123 second core threads for subtask 1 and execute subtask 1 through p123 second core threads; configure p223 second core threads for subtask 2 and execute subtask 2 through p223 second core threads.

[0097] In some optional implementations, after determining the target time slice of the subtask based on its time allocation information, and configuring core threads for the subtask according to the first core thread count, and executing the subtask through the core threads, the following steps are also included:

[0098] If the preset conditions are met, the number of core threads for the subtask is adjusted according to the number of third core threads. The preset conditions include the occurrence of resource exceptions. The subtask is then executed using the adjusted core threads.

[0099] In other words, if processing resources malfunction, it may be impossible to provide the required number of core threads for an active subtask. Therefore, the number of core threads for that subtask is reduced from the first to the third core thread count. Furthermore, since the third core thread count is determined based on the subtask's expected processing volume and duration, configuring threads and executing the subtask based on this third core thread count ensures its completion within the expected processing time, thus guaranteeing successful task execution. It should be noted that if the processing resource failure rate is high and cannot support the third core thread count, new processing resources can be requested, or the number of core threads can be further reduced.

[0100] For example, for the tasks to be processed mentioned above, the number of third core threads for subtask 1 is determined to be p13, the number of third core threads for subtask 2 is p23, and the number of third core threads for subtask 3 is p33. Based on this, if a preset condition is detected within the time period t1, the number of first core threads configured for subtask 1 will be adjusted to p13 third core threads, and subtask 1 will be executed through these p13 third core threads. It should be noted that "first" and "third" are only used to identify the number of core threads, not to limit the number of core threads. In other words, when p11 = 6 and p13 = 4, the above process can be: within the time period t1 (i.e., the target time slice of subtask 1), if a preset condition is detected, the number of core threads configured for subtask 1 will be reduced from 6 to 4, and subtask 1 will be executed through these 4 core threads.

[0101] Similarly, within the time period t2 (i.e. the target time slice of subtask 2), if the preset conditions are met, the configuration of p21 first core threads for subtask 2 will be adjusted to p23 third core threads, and subtask 2 will be executed through p23 third core threads.

[0102] Within the t3 time period (i.e., the target time slice of subtask 3), if the preset conditions are met, the p31 first core threads configured for subtask 3 will be adjusted to p33 third core threads, and subtask 3 will be executed through p33 third core threads.

[0103] In this embodiment, firstly, upon receiving a task request, the task to be processed corresponding to the task request is divided into multiple subtasks according to the business scenario, facilitating subsequent time-slicing allocation for the corresponding subtasks based on different business scenarios. Secondly, based on the business scenario to which each subtask belongs, the time allocation information for each subtask is determined. This time allocation information characterizes the processing time allocated to the subtask under different processing states, thus clarifying the subtasks to be executed first in different time periods and appropriately allocating processing resources to these subtasks, thereby optimizing the allocation of processing resources. Information on processing resources is obtained, reflecting the type and quantity of processing resources. Furthermore, based on the information on processing resources and the attribute information of each subtask, the thread of each subtask is determined. Configuration information, specifically thread configuration information, characterizes the thread type and number configured for each subtask in each processing state. This process generates matching thread configuration information for each subtask based on its resource requirements in different processing states, allowing for the appropriate thread configuration for subtasks in different states. Finally, based on the time allocation and thread configuration information of each subtask, threads are configured for each subtask, and the configured threads execute the corresponding subtasks. This process balances time and processing resources, ensuring that subtasks in the target time slice receive relatively more processing resources, while subtasks in non-target time slices maintain a certain processing capacity with fewer resources. This optimizes the allocation of processing resources and improves resource utilization.

[0104] The following is combined with Figure 2 and Figure 4 The thread-based task processing method of this application embodiment will be described in detail.

[0105] Figure 2 This is a schematic diagram illustrating a server thread configuration according to an embodiment of this application. (Refer to...) Figure 2 The server is configured with d thread pools (d≥1), including: thread pool 1, thread pool 2, ..., thread pool d. Thread pool 1 has z1 threads (thread 11, thread 12, ..., thread 1z1), thread pool 2 has z2 threads (thread 21, thread 22, ..., thread 2z2), ..., thread pool d has zd threads (thread d1, thread d2, ..., thread dzd), where z1 to zd are integers greater than or equal to 1.

[0106] In some optional implementations, different thread pools correspond to different business scenarios (which can also be understood as different thread pools corresponding to different subtasks). For example, for a task to be processed, which includes d subtasks, each subtask corresponding to a different business scenario, the first subtask can be processed by a thread pool, the second subtask by a second thread pool, and so on, until the dth subtask is processed by the dth thread pool. When the ith subtask (1≤i≤d) is processed by the ith thread pool, the thread type and number of threads in the ith thread pool can be determined according to any thread-based task processing method of any embodiment of this application, and will not be described further here.

[0107] Figure 3 This is a schematic diagram illustrating a thread-based task processing method provided in an embodiment of this application. (Refer to...) Figure 3 The task to be processed is the task that needs to be processed. It can be a list processing task or other processing tasks. This application embodiment does not limit this.

[0108] Processing resources are various resources provided for executing tasks, including instances, databases, and middleware. Instances are configured with one or more cores and can provide at least computing resources; databases provide data storage and analysis functions; and middleware manages computing resources and network communication, enabling interoperability. These processing resources provide the resource foundation for executing tasks.

[0109] In some alternative implementations, in order to efficiently manage and effectively configure processing resources, information about processing resources can be obtained through processing resource detection, and processing resource decisions can be made based on this information to obtain decision results. Then, processing resource configuration can be dynamically performed for the tasks to be processed based on the decision results.

[0110] like Figure 3 As shown, the task to be processed is divided into s subtasks based on the business scenario: subtask 1, subtask 2, ..., subtask s. The processing time for the task to be processed is determined to be the time interval from t1 to t2. Based on the business scenario to which each subtask belongs, the time interval from t1 to t2 is divided into s time slices (including time slice 1, time slice 2, ..., time slice s). Time slice 1 is the target time slice for subtask 1, time slice 2 is the target time slice for subtask 2, ..., time slice s is the target time slice for subtask s. Furthermore, typically, each subtask is active within its respective target time slice and connected within non-target time slices.

[0111] Accordingly, for subtask 1, the number of first core threads p11, the number of second core threads p12, ..., the number of second core threads p1s for subtask s can be determined. By processing resource configuration, within time slice 1, p11 core threads are configured for subtask 1 to execute subtask 1, p12 core threads are configured for subtask 2 to execute subtask 2, ..., and p1s core threads are configured for subtask s to execute subtask s.

[0112] For subtask 2, we can determine the number of second core threads p22 (p22 is usually less than p11) corresponding to subtask 1, the number of first core threads p21 (p21 is usually greater than p12) for subtask 2, ..., the number of second core threads p2s for subtask s. By processing resource configuration, within time slice 2, we configure p22 core threads for subtask 1 to execute subtask 1, p21 core threads for subtask 2 to execute subtask 2, ..., and p2s core threads for subtask s to execute subtask s.

[0113] Similarly, for subtask s, we can determine the number of second core threads ps2 (ps2 is usually less than p11) for subtask 1, the number of second core threads ps2 (ps2 is usually less than p21) for subtask 2, ..., and the number of first core threads ps1 (ps1 is usually greater than p1s and p2s) for subtask s. By processing resource configuration, within time slice s, we configure ps2 core threads for subtask 1 to execute subtask 1, ps2 core threads for subtask 2 to execute subtask 2, ..., and ps1 core threads for subtask s to execute subtask s.

[0114] It should be noted that during the execution of pending tasks, if the preset conditions are met through processing resource detection, the processing resources will be re-determined and reconfigured to match the current processing resource situation.

[0115] For example, in addition to the active state and the connected state, the processing status of each subtask also includes a guaranteed state. When a subtask is in the guaranteed state, the number of core threads configured for it is the third core thread count. The third core thread count can be determined based on information about processing resources (e.g., the number of instances, the number of cores of the instances, etc.) and attribute information of the subtask (e.g., the expected processing volume and expected processing time of the subtask, etc.). The determination process can be found in the relevant content of the embodiments of this application, and will not be described in detail here.

[0116] For example, determine the number of third core threads p13 for subtask 1, the number of third core threads p23 for subtask 2, ..., and the number of second core threads ps3 for subtask s.

[0117] Within time slice 1, if a preset condition is met, then by processing resource configuration, p13 core threads are configured for subtask 1 to execute subtask 1 (equivalent to reducing the number of core threads executing subtask 1 from p11 to p13).

[0118] Within time slice 2, if a preset condition is detected, then by processing resource configuration, p23 core threads are configured for subtask 2 to execute subtask 2 (equivalent to reducing the number of core threads executing subtask 2 from p21 to p23).

[0119] Similarly, within time slice s, if a preset condition is detected, then by processing resource configuration, ps3 core threads are configured for subtask s to execute subtask s (equivalent to reducing the number of core threads executing subtask s from ps1 to ps3).

[0120] Figure 4 This is a flowchart illustrating a thread-based task processing method provided in an embodiment of this application.

[0121] Step S401: Obtain the task to be processed.

[0122] Step S402: Divide the task to be processed into multiple sub-tasks according to the business scenario.

[0123] Step S403: Determine the target time slice and non-target time slice for each subtask based on the business scenario to which each subtask belongs.

[0124] Step S404: Obtain information about the processing resources, and determine the preset indicators for stress testing the processing resources and the adjustment ratio for adjusting the stress test extreme values ​​of the preset indicators.

[0125] Step S405: Perform stress testing on the processing resources and determine the stress test extreme values ​​of the preset indicators.

[0126] For example, for databases, the preset metrics can be defined as Queries Per Second (QPS) and Transactions Per Second (TPS). Through load testing, the QPS and TPS values ​​at which the database is on the verge of collapse are recorded and used as the extreme values ​​for QPS and TPS during load testing. The load testing process for other processing resources is similar and will not be described in detail here.

[0127] Step S406: Determine the number of transactions for a single piece of data in each subtask based on the attribute information of each subtask.

[0128] Step S407: Determine the processing time for each data item in each subtask based on the number of transactions for each data item in each subtask and the stress test extreme value of the preset indicators.

[0129] Step S408: Determine the number of first core threads based on the processing time of a single data item for each subtask, the stress test extreme value of the preset indicator, and the adjustment ratio.

[0130] Step S409: Determine the maximum number of threads based on the information about the processing resources.

[0131] Step S410: Determine the remaining number of core threads based on the maximum number of threads and the number of first core threads for each subtask.

[0132] Step S411: Determine the number of second core threads for each subtask based on the remaining number of core threads.

[0133] Step S412: Based on the processing time of a single data item and the information on processing resources for each subtask, determine the maximum number of core threads that can meet the expected processing volume and expected processing time of each subtask, and set the maximum number as the number of third core threads.

[0134] Step S412 can be executed after step S407 has been completed and the processing time of each subtask for a single data item has been obtained.

[0135] Step S413: Based on the target time slice of each subtask, determine the subtask corresponding to the current time, configure a core thread for the subtask according to the first core thread count of the subtask, and execute the subtask through the configured core thread. For the remaining subtasks, configure a core thread for each of the remaining subtasks according to the second core thread count of each subtask, and execute the remaining subtasks through the configured core thread.

[0136] Step S414: If the preset conditions are met, adjust the number of core threads of the subtask in the target time slice according to the number of third core threads, and execute the subtask through the adjusted core threads.

[0137] In some optional implementations, during the initialization phase of executing the tasks to be processed, one core thread can be allocated to each subtask (equivalent to having one second core thread), so that each subtask processes tasks in a connected state; then, the target time slice corresponding to the current moment and the subtask g(i) corresponding to the target time slice are determined, and the number of core threads of subtask g(i) is increased to the number of first core threads p(i) corresponding to subtask g(i), thereby switching the processing state of subtask g(i) to the active state (other subtasks still process tasks in a connected state). During execution, a detection method can be used to determine whether to enter the target time slice of the next subtask g(i+1). After entering the target time slice of the next subtask g(i+1), the number of core threads of subtask g(i) is reduced from p1 to 1, thereby switching the processing state of subtask g(i) to the connected state. The number of core threads of subtask g(i+1) is then increased to the first core thread count p(i+1) corresponding to subtask g(i+1), thus switching the processing state of subtask g(i+1) to the active state. This process continues until all subtasks are executed, yielding the final task processing result.

[0138] It should be noted that during the above processing, if a preset condition is met, the number of core threads for the subtask currently in an active state will be reduced from the first core thread count to the third core thread count. This ensures the task can be completed while reducing resource consumption. If the preset condition is not met, the number of core threads for the subtask can be readjusted from the third core thread count back to the first core thread count to speed up task processing.

[0139] It is understood that the various method embodiments mentioned above in this application can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this application will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.

[0140] Secondly, embodiments of this application provide a thread-based task processing device.

[0141] Figure 5 This is a block diagram of a thread-based task processing device provided in an embodiment of this application.

[0142] Reference Figure 5 This application provides a thread-based task processing device 500, which includes:

[0143] The partitioning module 501 is used to divide the task to be processed into multiple subtasks according to the business scenario.

[0144] The allocation module 502 is used to determine the time allocation information of each subtask according to the business scenario to which each subtask belongs. The time allocation information is used to characterize the processing time allocated to the subtask under different processing states.

[0145] The acquisition module 503 is used to acquire information about the processing resources, which reflects the type and quantity of the processing resources.

[0146] The determination module 504 is used to determine the thread configuration information of each subtask based on the information of the processing resources and the attribute information of each subtask. The thread configuration information is used to characterize the thread type and thread number configured in the subtask under different processing states (that is, the thread configuration information can characterize the thread type and thread number configured in each subtask under each processing state).

[0147] The configuration module 505 is used to configure threads for each subtask based on the time allocation information and thread configuration information of each subtask, and to execute the corresponding subtask through the configured threads.

[0148] In some optional implementations, the processing state of the subtask includes an active state, and the thread configuration information includes at least the number of first core threads, which is the number of core threads configured when the subtask is in an active state.

[0149] When determining the number of first core threads in the thread configuration information of each subtask based on the information of the processing resources and the attribute information of each subtask, module 504 performs the following steps:

[0150] Based on the information of the processing resources, determine the preset indicators for stress testing the processing resources and the adjustment ratio for adjusting the stress test extreme values ​​of the preset indicators;

[0151] Perform stress tests on the processing resources to determine the stress test extreme values ​​of the preset indicators;

[0152] Based on the attribute information of each subtask, determine the number of transactions for a single piece of data in each subtask;

[0153] The processing time for a single data item in each subtask is determined based on the number of transactions for a single data item in each subtask and the stress test extreme values ​​of preset indicators.

[0154] The number of first core threads is determined based on the processing time of a single data item for each subtask, the stress test extreme values ​​of preset indicators, and the adjustment ratio.

[0155] In some optional implementations, the number of first core threads is determined based on the processing time of a single data item for each subtask, the stress test extreme values ​​of preset metrics, and the adjustment ratio, including:

[0156] Based on the stress test extreme value and adjustment ratio of the preset index, determine the allowable threshold of the preset index;

[0157] Initialize the number of core test threads;

[0158] After adjusting the number of test core threads to meet the preset threshold allowable conditions, the number of the first core threads is determined based on the current number of test core threads; wherein, the threshold allowable conditions are that the actual value of each preset indicator is less than or equal to the allowable threshold, and the amount of data processed per unit time reaches the maximum value.

[0159] In some optional implementations, the processing state of the subtask also includes the connection state, and the thread configuration information also includes the number of second core threads, which is the number of core threads configured when the subtask is in the connection state.

[0160] When module 504 determines the number of second core threads included in the thread configuration information of each subtask based on the information of the processing resources and the attribute information of each subtask, it performs the following steps:

[0161] Based on the information about the processing resources, determine the maximum number of threads, where the maximum number of threads is the maximum number of threads that the processing resources can support.

[0162] The remaining number of core threads is determined based on the maximum number of threads and the number of the first core threads in each subtask.

[0163] Determine the number of second core threads for each subtask based on the number of remaining core threads.

[0164] In some optional implementations, the processing status of the subtask also includes a guaranteed state, and the thread configuration information also includes the number of third core threads, which is the number of core threads configured when the subtask is in a guaranteed state. The attribute information of each subtask includes the expected processing volume and expected processing time of each subtask.

[0165] When determining the number of third-core threads in the thread configuration information of each subtask based on the information of the processing resources and the attribute information of each subtask, module 504 performs the following steps:

[0166] Based on the processing time of a single data item and the information on processing resources for each subtask, determine the maximum number of core threads that can meet the expected processing volume and expected processing time of each subtask, and set the maximum number as the number of third core threads.

[0167] In some alternative implementations, after determining the maximum number as the number of third core threads, module 504 also performs the following steps:

[0168] The number of threads in the third core is compared with the thread count threshold to obtain the comparison results; the thread count threshold is determined based on the maximum number of threads that can be created based on the processing resources.

[0169] Based on the comparison results, determine whether it is necessary to increase the amount of processing resources.

[0170] In some optional implementations, the time allocation information includes the target time slice and non-target time slice for each subtask, and the subtask is in an active state in the target time slice and in a hold state in the non-target time slice.

[0171] When the configuration module 505 configures threads for each subtask based on the time allocation information and thread configuration information of each subtask, and executes the corresponding subtask through the configured threads, it performs the following steps:

[0172] For each subtask, if the current moment belongs to the target time slice of the subtask based on the subtask's time allocation information, a core thread is configured for the subtask based on the first core thread count, and the subtask is executed through the core thread; if the current moment belongs to the non-target time slice of the subtask based on the subtask's time allocation information, a core thread is configured for the subtask based on the second core thread count, and the subtask is executed through the core thread.

[0173] In some optional implementations, after determining that the current moment belongs to the target time slice of the subtask based on the subtask's time allocation information, the configuration module 505 configures core threads for the subtask according to the number of first core threads, and executes the subtask through the core threads, it also performs the following steps:

[0174] If preset conditions are met, the number of core threads of the subtask is adjusted according to the number of third core threads. Preset conditions include abnormal processing resources.

[0175] Subtasks are executed using the adjusted core thread.

[0176] In some optional implementations, the tasks to be processed include list processing tasks, and the business scenarios include at least one of the following: list receiving scenario, list cleaning scenario, list layering scenario, list allocation scenario, list dialing scenario, and list decision-making scenario.

[0177] The embodiments provided in this application firstly, upon receiving a task request, the partitioning module divides the task to be processed corresponding to the task request into multiple subtasks according to the business scenario, facilitating subsequent time-slicing allocation for the corresponding subtasks based on different business scenarios. Secondly, the allocation module determines the time allocation information for each subtask based on the business scenario to which each subtask belongs. This time allocation information characterizes the processing time allocated to the subtask under different processing states, thus clarifying the subtasks to be executed first in different time periods and appropriately allocating processing resources to these subtasks, thereby optimizing the allocation of processing resources. The acquisition module obtains information about processing resources, which reflects the type and quantity of processing resources. Furthermore, the determination module determines the processing resource information and the attribute information of each subtask. The thread configuration information for each subtask is determined. This information represents the thread type and number configured for each subtask in each processing state. This process generates matching thread configuration information for each subtask based on its resource requirements in different processing states, allowing for the appropriate thread configuration for each subtask in different states. Finally, the configuration module configures threads for each subtask based on its time allocation and thread configuration information, and executes the corresponding subtasks using the configured threads. This process balances time and processing resources, ensuring that subtasks in the target time slice receive relatively more processing resources, while subtasks in non-target time slices maintain a certain processing capacity with fewer resources. This optimizes the allocation of processing resources and improves resource utilization.

[0178] In addition, this application also provides electronic devices and computer-readable storage media, all of which can be used to implement any of the thread-based task processing methods provided in this application. The corresponding technical solutions and descriptions are described in the corresponding records in the method section and will not be repeated here.

[0179] Figure 6 This is a block diagram of an electronic device provided in an embodiment of this application.

[0180] Reference Figure 6 This application provides an electronic device, which includes: at least one processor 601; at least one memory 602; and one or more I / O interfaces 603 connected between the processor 601 and the memory 602; wherein the memory 602 stores one or more computer programs that can be executed by at least one processor 601, and the one or more computer programs are executed by at least one processor 601 to enable at least one processor 601 to perform the above-described thread-based task processing method.

[0181] This application also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the above-described thread-based task processing method. The computer-readable storage medium can be volatile or non-volatile.

[0182] This application also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described thread-based task processing method.

[0183] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0184] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable program instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0185] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0186] The computer program instructions used to perform the operations of this application may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), are personalized by utilizing state information from the computer-readable program instructions. These electronic circuits can execute the computer-readable program instructions to implement various aspects of this application.

[0187] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0188] Various aspects of this application are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should 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-readable program instructions.

[0189] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0190] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0191] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0192] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for general illustrative purposes only and should not be construed as limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of this application as set forth by the appended claims.

Claims

1. A thread-based task processing method, characterized in that, include: Divide the tasks to be processed into multiple sub-tasks according to the business scenario; Based on the business scenario to which each subtask belongs, determine the time allocation information for each subtask, wherein the time allocation information is used to characterize the processing time allocated to the subtask under different processing states; Acquire information about processing resources, which reflects the type and quantity of processing resources; Based on the information of the processing resources and the attribute information of each subtask, the thread configuration information of each subtask is determined. The thread configuration information is used to characterize the thread type and number of threads configured in different processing states of the subtask. Based on the time allocation information and thread configuration information of each subtask, a thread is configured for each subtask, and the corresponding subtask is executed through the configured thread.

2. The method according to claim 1, characterized in that, The processing state of the subtask includes an active state, and the thread configuration information includes at least a first core thread count, which is the number of core threads configured when the subtask is in an active state. Based on the information of the processing resources and the attribute information of each subtask, the number of the first core threads included in the thread configuration information of each subtask is determined, including: Based on the information of the processing resources, a preset index for stress testing the processing resources and an adjustment ratio for adjusting the stress test extreme values ​​of the preset index are determined. The processing resources are subjected to stress testing to determine the stress test extreme values ​​of the preset indicators; Based on the attribute information of each subtask, determine the number of transactions for a single piece of data in each subtask; The processing time for a single data item in each subtask is determined based on the number of transactions for a single data item in each subtask and the stress test extreme value of the preset index. The number of the first core threads is determined based on the processing time of each data item in each subtask, the stress test extreme value of the preset indicator, and the adjustment ratio.

3. The method according to claim 2, characterized in that, The step of determining the number of the first core threads based on the single data processing time of each subtask, the stress test extreme value of the preset indicator, and the adjustment ratio includes: Based on the stress test extreme value of the preset index and the adjustment ratio, the allowable threshold of the preset index is determined; Initialize the number of core test threads; When the number of test core threads is adjusted to meet the preset threshold allowable condition, the number of the first core threads is determined according to the current number of test core threads; wherein, the threshold allowable condition is that the actual value of each preset indicator is less than or equal to the allowable threshold, and the amount of data processed per unit time reaches the maximum value.

4. The method according to claim 2, characterized in that, The processing status of the subtask also includes the connection status, and the thread configuration information also includes the second core thread count, which is the number of core threads configured when the subtask is in the connection status. Based on the information of the processing resources and the attribute information of each subtask, the number of the second core threads, including the thread configuration information of each subtask, is determined, including: Based on the information of the processing resources, the maximum number of threads is determined, wherein the maximum number of threads is the maximum number of threads that the processing resources support. The remaining number of core threads is determined based on the maximum number of threads and the number of the first core threads for each subtask. The number of second core threads for each subtask is determined based on the number of remaining core threads.

5. The method according to claim 4, characterized in that, The processing status of the subtask also includes a guaranteed status. The thread configuration information also includes the number of third core threads, which is the number of core threads configured for the subtask when it is in the guaranteed status. The attribute information of each subtask includes the expected processing volume and expected processing time of each subtask. Based on the information of the processing resources and the attribute information of each subtask, the number of the third core threads included in the thread configuration information of each subtask is determined, including: Based on the processing time of a single data item for each subtask and the information of the processing resources, determine the maximum number of core threads that can satisfy the expected processing volume and expected processing time for each subtask, and define the maximum number as the number of the third core threads.

6. The method according to claim 5, characterized in that, After determining the maximum number as the number of the third core threads, the method further includes: The number of third core threads and the thread number threshold are compared to obtain a comparison result; wherein, the thread number threshold is determined based on the maximum number of threads that the processing resources can support. Based on the comparison results, determine whether it is necessary to increase the amount of processing resources.

7. The method according to claim 5, characterized in that, The time allocation information includes target time slices and non-target time slices for each subtask, and the subtask is in an active state in the target time slice and in a connected state in the non-target time slice. The step of configuring threads for each subtask based on the time allocation information and thread configuration information, and executing the corresponding subtasks through the configured threads, includes: For each of the subtasks, if it is determined that the current time belongs to the target time slice of the subtask based on the time allocation information of the subtask, core threads are configured for the subtask according to the first number of core threads, and the subtask is executed by the core threads. If the current time is determined to be a non-target time slice of the subtask based on the time allocation information of the subtask, core threads are configured for the subtask according to the second number of core threads, and the subtask is executed through the core threads.

8. A thread-based task processing device, characterized in that, include: The partitioning module is used to divide the task to be processed into multiple subtasks according to the business scenario; The allocation module is used to determine the time allocation information of each subtask according to the business scenario to which each subtask belongs, wherein the time allocation information is used to characterize the processing time allocated to the subtask under different processing states; The acquisition module is used to acquire information about the processing resources, which reflects the type and quantity of the processing resources. The determining module is used to determine the thread configuration information of each subtask based on the information of the processing resources and the attribute information of each subtask. The thread configuration information is used to characterize the thread type and number of threads configured in different processing states of the subtask. The configuration module is used to configure threads for each subtask based on the time allocation information and thread configuration information of each subtask, and to execute the corresponding subtask through the configured threads.

9. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores one or more computer programs that can be executed by the at least one processor, the one or more computer programs being executed by the at least one processor to enable the at least one processor to perform the thread-based task processing method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the thread-based task processing method as described in any one of claims 1-7.

Images