Thread allocation method and apparatus

Abstract

One or more embodiments of the present description relate to the technical field of databases, and provide a thread allocation method and apparatus. The method is applied to a data node in a distributed database, the data node is configured with a thread quantity upper limit, the thread quantity upper limit is used for indicating the upper limit of the quantity of threads in the data node capable of being simultaneously used for executing a target-type task, and each tenant in the data node is respectively configured with a thread allocation weight. The method comprises: on the basis of the thread allocation weight of each tenant, sequentially allocating a thread to the tenants in the data node until the quantity of the threads allocated to the tenants reaches the thread quantity upper limit. The solution provided by the present description can allow some threads to be retained in the data node for executing other types of tasks other than the target-type task. In addition, in the present description, a thread can be sequentially allocated to the tenants on the basis of the thread allocation weights, thereby solving the problem of improper allocation of the threads among the tenants.

Description

Thread allocation method and device Technical Field

[0001] One or more embodiments of this specification relate to the field of database technology, and more particularly, to a thread allocation method and apparatus. Background Art

[0002] A distributed database usually consists of multiple data nodes, and the thread resources in each data node are shared by all tenants in the data node.

[0003] In related technologies, when multiple tenants on the same data node simultaneously request to execute thread-intensive tasks (e.g., dumping or merging), these thread-intensive tasks can preempt a large number of threads on the data node, even fully occupying the node's threads. This can cause other requests on the node to be unable to execute or to execute slowly. Furthermore, threads used to execute these tasks are misallocated among tenants, resulting in some tenants being unable to receive threads.

[0004] Summary of the Invention

[0005] In view of this, one or more embodiments of this specification provide a thread allocation method and apparatus.

[0006] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions.

[0007] According to a first aspect of one or more embodiments of the present specification, a thread allocation method is proposed, which is applied to a data node in a distributed database, wherein the data node is configured with an upper limit on the number of threads, which is used to indicate the upper limit on the number of threads in the data node that can be used to simultaneously execute target type tasks, and each tenant in the data node is respectively configured with a thread allocation weight; the method comprises: allocating threads to each tenant in the data node in turn according to the thread allocation weight of each tenant, until the number of threads allocated to the tenant reaches the upper limit on the number of threads.

[0008] According to a second aspect of one or more embodiments of the present specification, a thread allocation device is proposed, which is applied to a data node in a distributed database, wherein the data node is configured with an upper limit on the number of threads, which is used to indicate the upper limit on the number of threads that can be used simultaneously to execute target type tasks in the data node, and each tenant in the data node is respectively configured with a thread allocation weight; the device includes: an allocation module, which is used to allocate threads to each tenant in the data node in turn according to the thread allocation weight of each tenant, until the number of threads allocated to the tenant reaches the upper limit on the number of threads.

[0009] According to a third aspect of one or more embodiments of this specification, an electronic device is proposed, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements the method of the first aspect by running the executable instructions.

[0010] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided, on which computer instructions are stored. When the instructions are executed by a processor, the steps of the method of the first aspect are implemented.

[0011] The solution provided in this specification configures each data node in a distributed database with an upper limit on the number of threads, so as to limit the number of threads that can be used to execute target type tasks simultaneously in each data node, thereby ensuring that a portion of threads are always reserved in the data node for executing other types of tasks in addition to the target type tasks, thereby preventing the target type tasks from preempting a large number of threads, causing other types of tasks to be unable to execute or to execute slowly. In addition, the embodiment of this specification also configures a thread allocation weight for each tenant in the data node, and allocates threads to each tenant in turn based on the thread allocation weight, thereby solving the problem of improper thread allocation among tenants. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] FIG1 is a flow chart of a thread allocation method provided by an exemplary embodiment.

[0013] FIG2 is a flow chart of another thread allocation method provided by an exemplary embodiment.

[0014] FIG3 is a flow chart of a method for adjusting thread allocation weights provided by an exemplary embodiment.

[0015] FIG4 is a schematic diagram of a complete process of initial thread allocation provided by an exemplary embodiment.

[0016] FIG5 is a schematic diagram of a complete process of thread allocation according to thread allocation weights provided by an exemplary embodiment.

[0017] FIG6 is a schematic structural diagram of a device provided by an exemplary embodiment.

[0018] FIG7 is a schematic structural diagram of a thread allocation device provided by an exemplary embodiment. DETAILED DESCRIPTION

[0019] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of one or more embodiments of this specification, as detailed in the appended claims.

[0020] It should be noted that in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than those described in this specification. In addition, a single step described in this specification may be broken down into multiple steps for description in other embodiments, and multiple steps described in this specification may be combined into a single step for description in other embodiments.

[0021] A tenant is a logical concept in a distributed database and the unit of resource allocation. Each tenant's data and schedulable thread resources are completely isolated on each data node (i.e., a machine in a distributed database). However, during thread allocation on each data node, the allocated thread resources are shared by all tenants on that data node.

[0022] As a result, when multiple tenants on the same data node simultaneously request to execute thread-intensive tasks (e.g., dump or merge), these thread-intensive tasks can preempt a large number of threads on the data node, even fully occupying the node's threads. This can cause other requests on the node to be unable to execute or to execute slowly. Furthermore, threads for these tasks are misallocated among tenants, resulting in some tenants being unable to receive threads.

[0023] In view of this, the solution provided in this specification configures each data node in the distributed database with an upper limit on the number of threads, so as to limit the number of threads that can be used to execute target type tasks simultaneously in each data node, so that a portion of threads can always be reserved in the data node for executing other types of tasks in addition to the target type tasks, thereby avoiding the target type tasks from preempting a large number of threads, causing other types of tasks to be unable to execute or execute slowly. In addition, the embodiment of this specification also configures a thread allocation weight for each tenant in the data node, and allocates threads to each tenant in turn according to the thread allocation weight, thereby solving the problem of improper thread allocation among tenants.

[0024] Next, exemplary embodiments of the present specification will be described in detail.

[0025] First, an embodiment of this specification provides a thread allocation method, which can be executed by any electronic device.

[0026] For example, the thread allocation method provided in this specification can be applied to data nodes in a distributed database. These data nodes are configured with an upper limit on the number of threads, which is used to indicate the upper limit on the number of threads that can be used to execute target type tasks simultaneously in the data node.

[0027] It is understood that the configuration of the thread limit is intended to prevent target-type tasks from preempting a large number of threads in data nodes during execution, thereby affecting the execution of other types of tasks. Therefore, target-type tasks can be thread-intensive tasks in the database, such as dump tasks and merge tasks in an LSM-Tree-based database. Of course, target-type tasks can also be any type of task specified by the tenant, and this embodiment of the specification does not limit this.

[0028] In other words, the upper limit on the number of threads can be used to limit the preemption of target type tasks on thread resources in the data node, so that a portion of threads can always be reserved in the data node to execute other types of tasks.

[0029] In addition, each tenant on these data nodes is assigned a thread allocation weight. This weight is adjusted after each thread allocation based on the number of target tasks the tenant is currently requesting. During initial allocation, a default thread allocation weight can be configured for each tenant based on their actual needs.

[0030] Specifically, FIG1 is a flowchart of a thread allocation method provided by an exemplary embodiment. As shown in FIG1 , the thread allocation method provided by the embodiment of this specification includes the following steps.

[0031] S101 , allocating threads to each tenant in the data node in sequence according to the thread allocation weight of each tenant, until the number of threads allocated to the tenant reaches the upper limit of the number of threads.

[0032] In some embodiments, for each tenant in a data node, the proportion of the tenant's thread allocation weight to the sum of the thread allocation weights of all tenants to be allocated can be calculated, and the product of this proportion and the number of remaining allocatable threads can be used as the number of threads allocated to the tenant. The number of remaining allocatable threads can be understood as the number of threads that can still be freely allocated to tenants without exceeding the upper limit of the number of threads. The number of remaining allocatable threads can be updated in real time as the allocation process progresses.

[0033] For example, suppose there are three tenants in a data node, namely tenant A, tenant B, and tenant C. The thread allocation weights of the three tenants are 10, 50, and 40 respectively, and the initial number of remaining allocatable threads of the data node is 10. In this thread allocation process, threads will be allocated to tenants A, B, and C in turn, and tenant A can be allocated 1 thread. Tenant B can be assigned 5 threads Tenant C can be assigned 4 threads

[0034] It is worth noting that since the number of threads calculated by this method may be a decimal, the number of threads calculated by this method can be understood as the number of threads that the tenant should be allocated under ideal conditions (target number of threads), and is not necessarily the number of threads that the tenant is ultimately allocated.

[0035] Specifically, if the calculated number of threads is a decimal, the thread number value can be rounded up to ensure that the number of threads allocated to a tenant reaches the corresponding target number of threads as much as possible. However, due to the existence of the thread number cap, this may result in tenants with a lower allocation order not receiving enough threads.

[0036] In this case, to ensure fairness in thread allocation, for each tenant in a data node, if the number of threads currently allocated to the tenant is less than the target number of threads currently allocated to the tenant, the tenant will be given priority in thread allocation during the next thread allocation process. The target number of threads currently allocated to the tenant is the number of threads calculated in the above manner, which can be determined by the tenant's current thread allocation weight.

[0037] That is to say, due to the generation of decimals, if the threads allocated to the tenant this time do not meet the number of threads that should be allocated to it, the threads allocated to the tenant can be prioritized to ensure that they meet the number of threads that should be allocated to it during the next allocation, thereby ensuring the fairness of thread allocation as much as possible.

[0038] It is worth noting that in order to avoid tenants from preempting thread resources when executing target type tasks, an upper limit on the number of schedulable threads can be configured for each tenant in the data node. The upper limit on the number of schedulable threads is used to indicate the upper limit on the number of threads that the tenant can use to execute target type tasks at the same time.

[0039] This means that the threads assigned to the tenant are not necessarily schedulable threads, and the number of threads that the tenant can use to execute target type tasks at the same time cannot exceed the upper limit of the schedulable number configured for the tenant.

[0040] In other words, the thread allocation method provided in this specification can be understood as allocating threads used to execute target type tasks to each tenant's private thread pool. When tenants execute target type tasks, they can schedule the allocated threads from their respective private thread pools, but the total number of threads that can be scheduled simultaneously is still subject to the above-mentioned upper limit on the number of threads that can be scheduled.

[0041] That is, when executing a task of the target type, the number of threads that the tenant can actually schedule is the minimum of the number of allocated threads and the upper limit of the schedulable number.

[0042] In this case, if the number of threads allocated to a tenant exceeds the upper limit of the schedulable number, the threads allocated to the tenant will not be effectively utilized. In this case, these idle threads can be evenly distributed to other tenants whose number of allocated threads is less than the upper limit of the schedulable number, so that these idle threads can be effectively utilized.

[0043] In some embodiments, please refer to FIG. 2 , which is a flowchart of another thread allocation method provided by an exemplary embodiment.

[0044] As shown in FIG2 , by repeatedly executing the following steps S201 to S202 , threads in a data node may be allocated multiple times.

[0045] S201 , adjusting the thread allocation weight of each tenant according to the number of target type tasks currently requested to be executed by each tenant.

[0046] The target type task currently requested to be executed may include: a target type task currently being executed and a target type task currently waiting to be executed.

[0047] For ease of understanding, the following will specifically describe the method for adjusting thread allocation weights in conjunction with Figure 3. As shown in Figure 3, the method for adjusting thread allocation weights may include the following steps.

[0048] S301, obtaining the average number of target type tasks currently waiting to be executed by all tenants in the data node.

[0049] S302 : When the average number is greater than a preset number threshold, adjust the thread allocation weight of each tenant according to the relationship between the number of target type tasks currently waiting to be executed by each tenant and the average number.

[0050] It is understandable that when the above average number is small, it means that there are fewer target type tasks waiting to be executed in the data node and the current thread allocation weight is relatively reasonable. Therefore, thread preemption will not occur and the thread allocation weight can be adjusted. Therefore, the embodiments of this specification set a preset number threshold to limit the conditions for adjusting the thread allocation weight, thereby reducing meaningless adjustments to the thread allocation weight.

[0051] For example, when the thread allocation weight of each tenant needs to be adjusted, the following processing may be performed for each tenant in the data node.

[0052] If the number of target type tasks currently waiting to be executed by the tenant is greater than the average number, the thread allocation weight of the tenant is increased.

[0053] If the number of target type tasks currently waiting to be executed by the tenant is less than the average number, the thread allocation weight of the tenant is reduced.

[0054] If the number of target type tasks currently waiting to be executed by the tenant is equal to the average number, the thread allocation weight of the tenant is kept unchanged.

[0055] The number of target type tasks currently waiting to be executed by the tenant reflects the tenant's current demand for threads. Adjusting the thread allocation weight based on this number can obtain a more reasonable adjustment result.

[0056] In some embodiments, for each tenant in a data node, if the tenant is not currently requesting to execute a target type task, the tenant's thread allocation weight may be cleared (e.g., the thread allocation weight is set to 0). Tenants whose thread allocation weights are cleared do not participate in the thread allocation process.

[0057] It's understandable that if a tenant isn't currently requesting to execute a target-type task, it means no threads will be scheduled for that task. Therefore, allocating threads to this tenant is meaningless and would waste thread resources. Therefore, this tenant can be excluded from thread allocation. That is, regardless of how threads are allocated, the number of threads allocated to this tenant is always zero.

[0058] In some embodiments, after the thread allocation weight of each tenant is adjusted, for a tenant whose thread allocation weight has not been reduced during the adjustment process, if the number of target type tasks currently requested to be executed by the tenant is less than the number of threads currently allocated to the tenant, the thread allocation weight of the tenant can be reduced.

[0059] It is understandable that even if a tenant's thread allocation weight is not reduced during the above adjustment process due to some reasons (for example, the preset number threshold is set improperly), if the number of target type tasks currently requested by the tenant is less than the number of threads currently allocated to the tenant, it means that there are idle threads among the threads currently allocated to the tenant and they are not fully utilized. Therefore, the tenant's thread allocation weight can be reduced.

[0060] It's worth noting that even if the thread allocation weights of some tenants are reduced, the target number of threads for other tenants will increase accordingly due to the increase in thread allocation weight. Therefore, each tenant's final adjusted thread allocation weight can be limited to no more than the default thread allocation weight configured during initial allocation, preventing one tenant's thread allocation weight from being too high and preempting thread resources from other tenants.

[0061] Furthermore, in the process of increasing or decreasing thread allocation weights, to ensure fairness in thread allocation and avoid imbalances in thread allocation weights among tenants due to large changes in thread allocation weights, thread allocation weights can be increased or decreased based on a unit ratio of the tenant's current thread allocation weight. For example, the current thread allocation weight can be increased or decreased by 10%.

[0062] For ease of understanding, the unit ratio here can also be configured as the adjustment level of the weight. That is to say, in each adjustment process of the thread allocation weight, the thread allocation weight can be increased by one level, decreased by one level, or remain unchanged. Among them, increasing by one level means increasing the current thread allocation weight according to the unit ratio (for example, 10%), and decreasing by one level means decreasing the current thread allocation weight according to the unit ratio (for example, 10%). Of course, in some extreme cases, such as when the number of threads allocated to a tenant is much smaller or much larger than the number of target type tasks requested to be executed, the thread allocation weight can also be increased or decreased by multiple levels in one adjustment process, and the embodiments of this specification are not limited to this.

[0063] S202 : re-allocate threads to each tenant in the data node in sequence according to the adjusted thread allocation weight, until the number of threads allocated to the tenant reaches the upper limit of the number of threads.

[0064] It should be noted that the allocation process involved in S202 is essentially the same as that in S101, the only difference being that the allocation in S202 is based on the adjusted thread allocation weights, while the allocation in S101 is based on the initially configured default thread allocation weights. Therefore, the specific implementation of S202 can be referred to the above description of S101, and will not be further elaborated in this embodiment of the specification.

[0065] It is understandable that the above S201 to S202 may be repeatedly executed according to a preset time period, or may be executed each time a preset thread allocation condition is triggered, which is not limited in the embodiments of this specification.

[0066] In some embodiments, before allocating threads to each tenant in a data node, an initial thread may be allocated to each tenant to prevent some tenants from being unable to obtain threads during the allocation process. The threads in a data node that can be used to execute tasks of the target type simultaneously include the initial thread. In other words, the initial thread also occupies the maximum thread capacity shown in the thread limit above.

[0067] Specifically, the allocation of the initial thread can be as follows:

[0068] First, if the upper limit of the number of threads is greater than or equal to the number of all tenants in the data node, an initial thread is allocated to each tenant in the data node in turn.

[0069] Secondly, if the upper limit of the number of threads is less than the number of all tenants in the data node, an initial thread will be allocated to some tenants in the data node in turn, and in the next initial thread allocation process, an initial thread will be allocated to tenants who have not been allocated an initial thread this time, thereby ensuring the fairness of initial thread allocation.

[0070] After the initial thread allocation, the above S101 or S202 may be executed, that is, threads are continuously allocated to each tenant according to the thread allocation weight of each tenant until the number of threads allocated to the tenant reaches the thread number upper limit.

[0071] The above describes in detail the allocation principle and implementation details of the thread allocation method provided in this specification in conjunction with Figures 1 to 3. For ease of understanding, the complete allocation process of the thread allocation method provided in this specification will be illustrated below with reference to Figures 4 to 6.

[0072] First, assume that there are five tenants in a data node. The default thread allocation weights configured for the five tenants are 10, 10, 50, 20, and 10, respectively, and the upper limit of the number of threads configured for the data node is 20.

[0073] Please refer to Figure 4, which illustrates the complete initial thread allocation process. As shown in Figure 4, at the beginning of the thread allocation process, one initial thread is allocated to each of the five tenants. Due to the upper limit on the number of threads, the number of remaining allocatable threads decreases during the initial thread allocation process. Furthermore, since the upper limit is greater than the total number of tenants, each tenant is allocated an initial thread after the initial thread allocation is complete, preventing tenants from being unable to obtain threads during subsequent thread allocations.

[0074] Next, please refer to Figure 5, which shows the complete process of thread allocation based on thread allocation weights. After the initial thread allocation is completed, threads will be allocated to each tenant in turn based on the thread allocation weights of each tenant. As shown in Figure 5, after the initial thread allocation shown in Figure 4 is completed, the current number of remaining allocatable threads is 15. At this time, the remaining 15 threads can be allocated to each tenant in turn according to the thread allocation weights until the number of remaining allocatable threads is 0, that is, the number of threads allocated to the tenant reaches the thread limit. At this time, the number of threads allocated to the 5 tenants is 3, 3, 8, 4 and 2, respectively. At this point, a complete thread allocation process is completed.

[0075] It is understandable that when the next thread allocation begins, the thread allocation weight of each tenant should first be adjusted based on the number of target type tasks currently requested by each tenant. The specific implementation method can be referred to the description of the embodiment shown in Figure 3 above, and this embodiment will not be described in detail in this specification.

[0076] FIG6 is a schematic diagram of the structure of a device provided by an exemplary embodiment. Referring to FIG6 , at the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, and a non-volatile memory 610, and may also include hardware required for other functions. One or more embodiments of this specification can be implemented based on software, such as the processor 602 reading the corresponding computer program from the non-volatile memory 610 into the memory 608 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of software and hardware, etc., that is, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0077] Please refer to FIG. 7 , which provides a thread allocation device 700 , which can be applied to the device shown in FIG. 6 to implement the technical solution of this specification.

[0078] Exemplarily, the thread allocation device 700 can be applied to a data node in a distributed database. The data node is configured with an upper limit on the number of threads that can be used simultaneously to execute target type tasks in the data node, and each tenant in the data node is configured with a thread allocation weight. The thread allocation device 700 specifically includes: an allocation module 701 for sequentially allocating threads to each tenant in the data node according to each tenant's thread allocation weight until the number of threads allocated to the tenant reaches the upper limit on the number of threads.

[0079] In some embodiments, the allocation module 701 is also used to repeatedly perform the following steps to allocate threads in the data node multiple times: adjust the thread allocation weight of each tenant based on the number of target type tasks currently requested by each tenant to execute; and reallocate threads to each tenant in the data node in turn based on the adjusted thread allocation weight until the number of threads allocated to the tenant reaches the thread limit.

[0080] In some embodiments, the target type tasks currently requested for execution include: target type tasks currently being executed and target type tasks currently waiting for execution. The allocation module 701 is further configured to obtain the average number of target type tasks currently waiting for execution for all tenants in the data node; if the average number is greater than a preset threshold, adjust the thread allocation weight of each tenant based on the relationship between the number of target type tasks currently waiting for execution for each tenant and the average number.

[0081] In some embodiments, the allocation module 701 is also used to perform the following processing for each tenant in the data node: if the number of target type tasks currently waiting to be executed by the tenant is greater than the average number, the thread allocation weight of the tenant is increased; if the number of target type tasks currently waiting to be executed by the tenant is less than the average number, the thread allocation weight of the tenant is reduced; if the number of target type tasks currently waiting to be executed by the tenant is equal to the average number, the thread allocation weight of the tenant remains unchanged.

[0082] In some embodiments, the allocation module 701 is also used to, for each tenant in the data node, clear the thread allocation weight of the tenant if the tenant currently does not request to execute the target type task; wherein, the tenant whose thread allocation weight is cleared does not participate in the thread allocation process.

[0083] In some embodiments, the allocation module 701 is also used to reduce the thread allocation weight of a tenant whose thread allocation weight has not been reduced during the adjustment process if the number of target type tasks currently requested to be executed by the tenant is less than the number of threads currently allocated to the tenant.

[0084] In some embodiments, the allocation module 701 is also used to, for each tenant in the data node, if the number of threads currently allocated to the tenant is less than the target number of threads currently corresponding to the tenant, then in the next thread allocation process, threads will be allocated to the tenant first; wherein the target number of threads currently corresponding to the tenant is determined by the tenant's current thread allocation weight.

[0085] In some embodiments, the allocation module 701 is also used to allocate an initial thread to each tenant in the data node in turn if the upper limit of the number of threads is greater than or equal to the number of all tenants in the data node, wherein the threads in the data node that can be used simultaneously to execute target type tasks include the initial thread.

[0086] In some embodiments, the allocation module 701 is also used to allocate an initial thread to some tenants in the data node in turn if the upper limit of the number of threads is less than the number of all tenants in the data node, and in the next initial thread allocation process, give priority to allocating an initial thread to the tenants who have not been allocated an initial thread this time, wherein the threads in the data node that can be used simultaneously to execute target type tasks include the initial thread.

[0087] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

[0088] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0089] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0090] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0091] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0092] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0093] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "an," "the," and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0094] It should be understood that although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when..." or "when..." or "in response to determining."

[0095] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of this specification shall be included in the scope of protection of one or more embodiments of this specification.

Claims

1. A thread allocation method is applied to a data node in a distributed database. The data node is configured with an upper limit on the number of threads, which is used to show the upper limit on the number of threads that can be simultaneously used to execute tasks of a target type in the data node. Each tenant in the data node is respectively configured with a thread allocation weight; The method includes: According to the thread allocation weight of each tenant, allocate threads to each tenant in the data node in turn until the number of threads allocated to the tenant reaches the upper limit on the number of threads.

2. According to the method described in claim 1, after allocating threads to each tenant in the data node according to the thread allocation weight of each tenant, the method further includes: Repeat the following steps to allocate threads in the data node multiple times: Adjust the thread allocation weight of each tenant according to the number of tasks of the target type currently requested to be executed by each tenant; According to the adjusted thread allocation weight, re-allocate threads to each tenant in the data node in turn until the number of threads allocated to the tenant reaches the upper limit on the number of threads.

3. The method according to claim 2, wherein the target type tasks to be executed by the current request include: The tasks of the target type that are currently being executed and the tasks of the target type that are currently waiting to be executed; The adjusting the thread allocation weight of each tenant according to the number of tasks of the target type currently requested to be executed by each tenant includes: Obtain the average number of tasks of the target type that are currently waiting to be executed by all tenants in the data node; In the case where the average number is greater than a preset number threshold, adjust the thread allocation weight of each tenant according to the magnitude relationship between the number of tasks of the target type currently waiting to be executed by each tenant and the average number.

4. According to the method described in claim 3, the adjusting the thread allocation weight of each tenant according to the magnitude relationship between the number of tasks of the target type currently waiting to be executed by each tenant and the average number includes: For each tenant in the data node, perform the following processing respectively: If the number of tasks of the target type currently waiting to be executed by this tenant is greater than the average number, increase the thread allocation weight of this tenant; If the number of tasks of the target type currently waiting to be executed by this tenant is less than the average number, decrease the thread allocation weight of this tenant; If the number of tasks of the target type currently waiting to be executed by this tenant is equal to the average number, keep the thread allocation weight of this tenant unchanged.

5. According to the method described in claim 2, the adjusting the thread allocation weight of each tenant according to the number of tasks of the target type currently requested to be executed by each tenant includes: For each tenant in the data node, if this tenant does not currently request to execute tasks of the target type, clear the thread allocation weight of this tenant; Among them, the tenant whose thread allocation weight is cleared does not participate in the thread allocation process.

6. According to the method described in any one of claims 2 to 5, after adjusting the thread allocation weight of each tenant according to the number of tasks of the target type currently requested to be executed by each tenant, the method further includes: For a tenant whose thread allocation weight is not decreased during the adjustment process, if the number of target type tasks currently requested to be executed by the tenant is less than the number of threads currently allocated to the tenant, then decrease the thread allocation weight of the tenant.

7. The method according to claim 1 or 2, the method further comprising: For each tenant in the data node, if the number of threads currently allocated to the tenant is less than the current corresponding target thread number of the tenant, then in the next thread allocation process, preferentially allocate threads to the tenant; wherein, the current corresponding target thread number of the tenant is determined by the current thread allocation weight of the tenant.

8. The method according to claim 1 or 2, before sequentially allocating threads to each tenant in the data node each time, the method further comprising: If the thread number upper limit is greater than or equal to the number of all tenants in the data node, then sequentially allocate an initial thread to each tenant in the data node, wherein, the threads that can be used to execute target type tasks in the data node include the initial threads.

9. The method according to claim 1 or 2, before sequentially allocating threads to each tenant in the data node each time, the method further comprising: If the thread number upper limit is less than the number of all tenants in the data node, then sequentially allocate an initial thread to some tenants in the data node, and in the next initial thread allocation process, preferentially allocate an initial thread to the tenant that was not allocated an initial thread this time, wherein, the threads that can be used to execute target type tasks in the data node include the initial threads.

10. A thread allocation device, applied to a data node in a distributed database, the data node is configured with a thread number upper limit, the thread number upper limit is used to show the upper limit of the number of threads that can be used to execute target type tasks in the data node, and each tenant in the data node is respectively configured with a thread allocation weight; The device includes: An allocation module, configured to sequentially allocate threads to each tenant in the data node according to the thread allocation weight of each tenant until the number of threads allocated to the tenant reaches the thread number upper limit.

11. An electronic device, comprising: A processor; A memory for storing processor-executable instructions; wherein, the processor realizes the method according to any one of claims 1 to 9 by running the executable instructions.

12. A computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method according to any one of claims 1 to 9 are realized.

Images