A task processing method and device

Abstract

An embodiment of the present invention provides a task processing method and device, the method comprising: a processing server obtains tasks generated by a production server from a middleware; the processing server determines the working state of a thread pool used to process each task; if the processing server determines that the working state is a non-high-pressure state, a permission acquisition request is generated according to the processing rate requirement of the task, and the permission acquisition request is sent to a current limiting server, the current limiting server is used to determine the corresponding permission indication according to the processing rate requirement in each permission acquisition request; wherein different processing rate requirements correspond to different permission allocation mechanisms; when the permission indication is included in the received permission acquisition response, the processing server processes the task through a thread in the thread pool. The above method is used to implement constant-speed processing for different tasks, reduce task processing delays, and improve the success rate of task processing.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a task processing method and device. Background Art

[0002] With the development of computer technology, more and more technologies are applied in the financial field or IT technology, but due to the security and real-time requirements of various industries, higher requirements are also placed on technology. Take the example of financial institutions sending promotional messages and repayment reminder messages to users.

[0003] The prior art generally determines the user group of promotional messages and the user group of repayment reminder messages through an institutional system. A corresponding batch promotional message is generated for the number of users in the user group of the promotional message, and a corresponding batch repayment reminder message is generated for the number of users in the user group of the repayment reminder message, and the batch promotional message and the batch repayment reminder message are sent to the Kafka server. When the processing server monitors that there is a message cached in the queue of the Kafka server, it obtains the message from the Kafka server and sends it for processing. However, in this method, if the promotional message in the queue of the Kafka server is before the repayment reminder message, the processing server will process the batch promotion message before processing the batch repayment reminder message, which will cause a delay in sending the repayment reminder message. And if the number of batch promotion messages and batch repayment reminder messages is large, it is very likely that the processing server will be overloaded with concurrent processing pressure, resulting in failure to send messages.

[0004] Therefore, there is an urgent need for a task processing method and device for implementing constant-speed processing for different tasks, reducing task processing delays, and improving task processing success rates. Summary of the invention

[0005] The embodiment of the present invention provides a task processing method and device, which are used to implement constant speed processing for different tasks, reduce task processing delay, and improve task processing success rate.

[0006] In a first aspect, an embodiment of the present invention provides a task processing method, the method comprising:

[0007] The processing server obtains the tasks generated by the production server from the middleware;

[0008] The processing server determines the working status of the thread pool used to process each task;

[0009] If the processing server determines that the working state is a non-high-pressure state, it generates a permission acquisition request according to the processing rate requirement of the task, and sends the permission acquisition request to the current limiting server, and the current limiting server is used to determine the corresponding permission indication according to the processing rate requirement in each permission acquisition request; wherein different processing rate requirements correspond to different permission allocation mechanisms;

[0010] When the received permission acquisition response includes a permission indication, the processing server processes the task through a thread in the thread pool.

[0011] In the above method, the current limiting server is used to determine the corresponding permission indication according to the processing rate requirement. In this way, different tasks can be processed according to different permissions, the delay of task processing can be reduced, and the success rate of task processing can be improved. The processing server determines that the working state of the thread pool is a non-high-pressure state, and then generates a permission acquisition request according to the processing rate requirement of the task, and sends the permission acquisition request to the current limiting server. In this way, it is considered that different tasks have different processing rate requirements for task processing and the corresponding task processing emergencies are different, and the working state of the thread pool in the processing server is taken into account to improve the success rate of task processing. For example, in one case, if the task is a message to be processed, the processing rate requirement can be a message channel rate requirement, and the current limiting server is used to limit the message processing speed according to the message channel rate. In this way, it is possible to implement fixed-speed processing for messages with different message channel rate requirements, and reduce the message sending delay. The processing server determines whether to generate a permission acquisition request according to the thread pool working state and the message channel rate of the message. In this way, it is considered that the message sending emergency corresponding to the message sending channel rate requirements of different messages is taken into account, and the working state of the thread pool in the processing server is taken into account to improve the message sending success rate.

[0012] Optionally, it also includes: if the processing server determines that the working state is a high-pressure state, putting the task back to the middleware.

[0013] In the above method, when the thread pool is in a high-pressure processing state, the task can be returned to the middleware and wait for the concurrent pressure of the processing server to decrease before processing the task, effectively reducing the situation of task loss and task processing failure caused by excessive concurrent pressure on the processing server.

[0014] Optionally, if the processing server determines that the working state is a non-high-pressure state, generating a permission acquisition request according to the processing rate requirement of the task includes:

[0015] The processing server determines that the working state is an ultra-low pressure state, or the working state is a low pressure state and the processing rate requirement is high speed, then generates a first permission acquisition request according to the processing rate requirement of the task; the first permission acquisition request is used to obtain a permission indication and an acquisition indication at the next moment.

[0016] In the above method, the thread pool working state is an ultra-low pressure processing state, or the thread pool working state is a low pressure processing state and the processing rate requirement of the task corresponds to the high-speed processing rate requirement. That is to say, when the thread pool working state is an ultra-low pressure state, the concurrent pressure of the thread pool of the processing server is extremely small. If the task cannot obtain the permission indication, there are enough thread resources to wait for the generation time of the next permission indication, and when the next permission indication generation time arrives, the permission indication is immediately obtained to complete the task processing. In this way, the timeliness of task processing is guaranteed. When the thread pool working state is a low pressure state and the processing rate requirement of the task corresponds to the high-speed processing rate requirement, the concurrent pressure of the thread pool of the processing server is small, and the processing rate requirement of the task corresponds to the high-speed processing rate requirement, that is, the task is in an emergency state. If the task cannot obtain the permission indication, in order to ensure the timely processing of the task, the generation time of the next permission indication can be waited for, and when the generation time of the next permission indication arrives, the permission indication is immediately obtained to complete the processing. In this way, the timeliness of task processing is also guaranteed.

[0017] Optionally, the method further includes: when the received permission acquisition response does not include the permission indication but includes an acquisition indication at the next moment,

[0018] The processing server sends the permission acquisition request to the current limiting server again according to the time of obtaining the indication.

[0019] In the above method, when the permission acquisition response does not contain the permission indication and contains the acquisition indication at the next moment, wait for the generation time of the next permission indication, and when the generation time of the next permission indication arrives, immediately obtain the permission indication to complete the task processing. In this way, the timeliness of task processing is ensured.

[0020] Optionally, if the processing server determines that the working state is a non-high-pressure state, generating a permission acquisition request according to the processing rate requirement of the task includes:

[0021] The processing server determines that the working state is a medium-pressure state, or the working state is a low-pressure state and the processing rate requirement is non-high speed, and then generates a second permission acquisition request according to the processing rate requirement of the task; the second permission acquisition request is used to obtain a permission indication;

[0022] The method further comprises:

[0023] When the received permission acquisition response does not include the permission indication, the processing server returns the task to the middleware.

[0024] In the above method, the thread pool working state is a medium-pressure state, or the thread pool working state is a low-pressure state and the processing rate requirement of the task corresponds to a non-high-speed processing rate requirement. That is to say, when the thread pool working state is a medium-pressure state, the concurrent pressure of the thread pool of the processing server is relatively large. If the task cannot obtain a permission indication, the task is returned to the middleware and waits for the next processing. When the thread pool working state is a low-pressure state and the processing rate requirement of the task corresponds to a non-high-speed processing rate requirement, the concurrent pressure of the thread pool of the processing server is general, and the task is in a non-urgent state. If the task cannot obtain a permission indication, the task is returned to the middleware and waits for the next processing. In this way, the resources in the processing server are guaranteed to maintain the best operating state.

[0025] Optionally, before generating the permission acquisition request according to the processing rate requirement of the task, the method further includes:

[0026] The processing server generates a clock acquisition request, and sends the clock acquisition request to the current limiting server;

[0027] The processing server obtains the clock information returned by the current limiting server; and the permission acquisition request includes the clock information.

[0028] In the above method, the processing server obtains the clock information returned by the current limiting server through the clock acquisition request. In this way, the time dimension of the processing server cluster is guaranteed to be consistent, and whether the permission allocation mechanism corresponding to the task contains an available permission indication or the next permission instruction generation time can be determined based on the clock information. For example, the clock information is that the current clock is 11:00, the current limiting server determines that the earliest time to generate the currently available permission instruction is 10:59, and the permission instruction generation speed is 1 / min, then it is determined that the number of currently available permission instructions is greater than 0, and the permission instruction is returned. If there is no permission instruction, the current limiting server determines that the earliest time to generate the currently available permission instruction is 11:01, 11:00<11:01, then the next permission instruction generation time 11:01 is returned.

[0029] Optionally, after the processing server obtains the task generated by the production server from the middleware, it also includes:

[0030] The processing server sends the permission algorithm to the current limiting server, and obtains the algorithm number determined by the current limiting server according to the permission algorithm, wherein the permission algorithm is used to generate a permission allocation mechanism;

[0031] Generate a permission acquisition request according to the processing rate requirement of the task, including:

[0032] The processing server generates a permission acquisition request according to the processing rate requirement of the task and the algorithm number, and the algorithm number is used by the current limiting server to determine the permission algorithm of the application according to the algorithm number.

[0033] In the above method, the processing server sends the permission algorithm to the current limiting server. Ensure that the permission algorithm exists in the current limiting server, generate a permission allocation mechanism based on the permission algorithm, and use it to determine the corresponding permission algorithm according to the algorithm number in the permission acquisition request of the processing server, and determine the permission allocation mechanism according to the processing rate requirement of the task in the permission acquisition request. Realize the processing of different tasks according to different permissions.

[0034] Optionally, the task is a message sending task; the middleware is a message middleware; the authority indication is a token; and different processing rate requirements correspond to different token buckets.

[0035] In the above method, the task is a message sending task, then the message sending processing task is sent with limited flow according to the above method in the first aspect, and the message is sent according to the message channel rate requirement, that is, the message is sent in an emergency situation to ensure the timeliness of the message and reduce the failure rate of message sending.

[0036] In a second aspect, an embodiment of the present invention provides a task processing system, wherein the task processing system includes a production server cluster, middleware, a processing server cluster, and a current limiting server cluster; the system includes:

[0037] Any production server in the production server cluster is used for production tasks;

[0038] The middleware is used to store tasks in a queue manner;

[0039] Any processing server in the processing server cluster is used to execute any method as described in the first aspect;

[0040] Any current limiting server in the current limiting server cluster is used to limit the task processing speed according to the authority algorithm and the processing rate requirement.

[0041] In a third aspect, an embodiment of the present invention provides a task processing device, the device comprising:

[0042] The acquisition module is used to obtain the tasks generated by the production server from the middleware;

[0043] A processing module, used to determine the working state of the thread pool used to process each task; if it is determined that the working state is a non-high-pressure state, a permission acquisition request is generated according to the processing rate requirement of the task, and the permission acquisition request is sent to a current limiting server, and the current limiting server is used to determine a corresponding permission indication according to the processing rate requirement in each permission acquisition request; wherein different processing rate requirements correspond to different permission allocation mechanisms;

[0044] The acquisition module is further configured to process the task through a thread in the thread pool of the processing module when the received permission acquisition response includes a permission indication.

[0045] In a fourth aspect, an embodiment of the present invention further provides a computing device, comprising: a memory for storing programs; a processor for calling the programs stored in the memory, and executing the methods described in the various possible designs of the first aspect according to the obtained programs.

[0046] In a fifth aspect, an embodiment of the present invention further provides a computer-readable non-volatile storage medium, comprising a computer-readable program. When a computer reads and executes the computer-readable program, the computer executes the method described in the various possible designs of the first aspect.

[0047] These implementations or other implementations of the present invention will be more concise and understandable in the description of the following embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0049] Figure 1 A schematic diagram of a system architecture for task processing provided by an embodiment of the present invention;

[0050] Figure 2 A schematic diagram of a system architecture for task processing provided by an embodiment of the present invention;

[0051] Figure 3 A flowchart of a task processing method provided by an embodiment of the present invention;

[0052] Figure 4 A flowchart of a method for determining an available authority indication provided by an embodiment of the present invention;

[0053] Figure 5 A flowchart of a task processing method provided by an embodiment of the present invention;

[0054] Figure 6 A schematic diagram of a task processing device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0055] In order to make the purpose, technical scheme and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0056] Figure 1 In a task processing system architecture provided by an embodiment of the present invention, a production server 101 is used to produce tasks and store the tasks in a middleware 102. A processing server 103 monitors the storage of tasks in the middleware 102. When the processing server 103 determines that there are tasks stored in the middleware 102, the processing server 103 obtains the tasks from the middleware 102. After obtaining the tasks, the processing server 103 determines the working status of the thread pool.

[0057] If the processing server 103 determines that the working state of the thread pool is a high-pressure state, the task is returned to the middleware 102 .

[0058] If the processing server 103 determines that the working state of the thread pool is a medium-pressure state in a non-high-pressure state, or a low-pressure state and the processing rate requirement of the task is a non-high-speed processing rate requirement. According to the processing rate requirement of the task and the algorithm number of the corresponding permission algorithm, a permission acquisition request is generated, and the permission acquisition request is sent to the flow limiting server 104. The flow limiting server 104 determines the corresponding permission algorithm according to the algorithm number in the permission acquisition request, and determines the permission allocation mechanism of the corresponding permission algorithm according to the processing rate requirement of the task in the permission acquisition request. If there is an available permission instruction in the permission allocation mechanism, the flow limiting server 104 generates a permission acquisition response according to the permission instruction, returns the permission acquisition response to the processing server 103, and the processing server 103 processes the task according to the permission instruction contained in the permission acquisition response. If there is no available permission instruction in the permission allocation mechanism, the flow limiting server 104 returns the permission acquisition response without the permission instruction to the processing server 103. The processing server 103 puts the task back to the middleware 102.

[0059] If the processing server 103 determines that the working state of the thread pool is an ultra-low pressure state in a non-high pressure state, or a low pressure state and the processing rate requirement of the task is a high-speed processing rate requirement. According to the processing rate requirement of the task and the algorithm number of the corresponding permission algorithm, a permission acquisition request is generated, and the permission acquisition request is sent to the flow limiting server 104. The flow limiting server 104 determines the corresponding permission algorithm according to the algorithm number in the permission acquisition request, and determines the permission allocation mechanism of the corresponding permission algorithm according to the processing rate requirement of the task in the permission acquisition request. If there is an available permission instruction in the permission allocation mechanism, the flow limiting server 104 generates a permission acquisition response according to the permission instruction, and returns the permission acquisition response to the processing server 103. The processing server 103 processes the task according to the permission instruction contained in the permission acquisition response. If there is no available permission instruction in the permission allocation mechanism, the current limiting server 104 generates a permission acquisition response according to the generation time of the next permission instruction, and returns the permission acquisition response to the processing server 103. The processing server 103 waits according to the generation time of the next permission instruction contained in the permission acquisition response. When the generation time of the next permission instruction is reached, the permission acquisition request is generated again to obtain the permission instruction. The current limiting server 104 generates a permission acquisition response according to the generated permission instruction, and returns the permission acquisition response to the processing server 103. The processing server 103 processes the task according to the generated permission instruction contained in the permission acquisition response. In this way, different permissions are set for different tasks for processing, the pertinence of the task processing scheme is increased, and the accuracy and timeliness of task processing are improved. In addition, in the initialization stage of the task processing system, the processing server 103 monitors that there are tasks stored in the middleware 102, and after obtaining the task from the middleware 102, the permission algorithm is sent to the current limiting server 104, and the algorithm number of the permission algorithm returned by the current limiting server 104 is obtained. In this way, it is ensured that the current limiting server 104 includes the permission algorithm, and there is no need to manually install the permission algorithm, thereby improving the installation accuracy, increasing the installation speed of the permission algorithm, and saving costs.

[0060] based on Figure 1 The task processing system architecture in the embodiment of the present invention provides a task processing system architecture, such as Figure 2 As shown; the task processing system includes a production server cluster 201 (including production server 1, production server 2 ... production server m, m ≥ 1, any one or more production servers in the production server cluster 201 can be Figure 1 The production server 101 in the system architecture), middleware 202, processing server cluster 203 (including processing server 1, processing server 2... production server n, n ≥ 1, any one or more processing servers in the processing server cluster 203 can be Figure 1The processing server 103 in the system architecture) and the current limiting server cluster 204 (including the current limiting server 1, the current limiting server 2... the current limiting server k, k ≥ 1, any one or more current limiting servers in the current limiting server cluster 204 can be Figure 1 Current limiting server 104 in the system architecture);

[0061] Any production server in the production server cluster 201 is used for production tasks;

[0062] The middleware 202 is used to store tasks in a queue manner;

[0063] Any processing server in the processing server cluster 203 is used to obtain the permission instruction according to the thread pool working state and the task processing rate requirement, and process the task according to the permission instruction;

[0064] Any current limiting server in the current limiting server cluster 204 is used to limit the task processing speed according to the authority algorithm and the processing rate requirement.

[0065] Based on the above system architecture, an embodiment of the present invention provides a process of a task processing method, such as Figure 3 As shown, including:

[0066] Step 301: The processing server obtains the task generated by the production server from the middleware;

[0067] Here, the task may be a task containing batch messages, and the processing speed requirements corresponding to the batch messages in the task are the same, such as the message channel rate requirements are the same. The task may also be a system transaction, such as a status reporting transaction, an alarm transaction, etc. corresponding to each subsystem of the transaction processing system. The specific object of the task is not limited here, and it is applicable to all objects to which the present invention can be applied. The middleware may be an MQ (Message Queue) message queue middleware, a Kafka distributed message publishing and subscription system, etc., and the most suitable middleware may be applied according to the adaptability of the specific object of the task. The present invention does not limit the middleware for specific applications.

[0068] Step 302: The processing server determines the working status of the thread pool for processing each task;

[0069] Here, the working state of the thread pool can be set by the processing server to set the working state threshold. For example, a thread pool size of 200 is defined in the processing server, that is, the thread pool can process 200 threads concurrently, and the maximum number of concurrent threads of the processing server application will not exceed 200. The working state of the thread pool can be determined according to the number of concurrent threads in the thread pool. For example, in the low-pressure state, the number of concurrent threads is 100, which is within [30%, 50%] of the proportion of concurrent threads in the thread pool, indicating that the number of tasks currently being processed simultaneously is moderate. Medium-pressure state: the number of concurrent threads is 150, which is within (50%, 75%] of the proportion of concurrent threads in the thread pool, indicating that a large number of text messages are currently being sent simultaneously. High-pressure state: the number of concurrent thread pools is 190, which is within (75%, 95%] of the proportion of concurrent threads in the thread pool, indicating that a large number of text messages are currently being sent simultaneously, and the concurrency is very high. It should be noted here that the determination of the above-mentioned thread pool working state is only an example, and can also be divided into ultra-high pressure state, high pressure state, medium pressure state, low pressure state, ultra-low pressure state, etc. The task processing scheme is subsequently determined according to the set thread working state, and the setting of the thread pool working state is not specifically limited here.

[0070] Step 303: If the processing server determines that the working state is a non-high-pressure state, it generates a permission acquisition request according to the processing rate requirement of the task, and sends the permission acquisition request to the current limiting server, and the current limiting server is used to determine the corresponding permission indication according to the processing rate requirement in each permission acquisition request; wherein different processing rate requirements correspond to different permission allocation mechanisms;

[0071] Here, if the task is a message sending task including batch messages, the processing rate requirement may be a message channel rate requirement; if the task is an abnormal alarm task, the processing rate requirement may be the effective time of the abnormal alarm task. The processing rate requirement may be set according to the specific task, and the present invention does not specifically limit it. The current limiting server may be Redis (Remote Dictionary Server), i.e., a remote dictionary service, or other servers that can run permission algorithms. The system or service in the current limiting server is not limited here.

[0072] Step 304: When the received permission acquisition response includes a permission indication, the processing server processes the task through a thread in the thread pool.

[0073] Here, the permission indication may be an indication including a processing scheme, for example, the permission indication corresponding to the alarm type of the abnormal alarm task may be an alarm email to staff members for different personnel roles, etc. The permission indication may also be a token, for example, if the message obtains the token, it may be sent directly for processing. The specific content of the permission indication is not limited here, and can be set according to the needs of the scheme and the task object.

[0074] In the above method, the current limiting server is used to determine the corresponding permission indication according to the processing rate requirement. In this way, different tasks can be processed according to different permissions, the delay of task processing can be reduced, and the success rate of task processing can be improved. The processing server determines that the working state of the thread pool is a non-high-pressure state, and then generates a permission acquisition request according to the processing rate requirement of the task, and sends the permission acquisition request to the current limiting server. In this way, it is considered that different tasks have different processing rate requirements for task processing and the corresponding task processing emergencies are different, and the working state of the thread pool in the processing server is taken into account to improve the success rate of task processing. For example, in one case, if the task is a message to be processed, the processing rate requirement can be a message channel rate requirement, and the current limiting server is used to limit the message processing speed according to the message channel rate. In this way, it is possible to implement fixed-speed processing for messages with different message channel rate requirements, and reduce the message sending delay. The processing server determines whether to generate a permission acquisition request according to the thread pool working state and the message channel rate of the message. In this way, it is considered that the message sending emergency corresponding to the message sending channel rate requirements of different messages is taken into account, and the working state of the thread pool in the processing server is taken into account to improve the message sending success rate.

[0075] The present invention provides a task processing method, further comprising: if the processing server determines that the working state is a high-pressure state, the task is put back into the middleware. In the above example, if the concurrent number of threads is 190, which is within 76%-95% of the concurrent threads in the thread pool, it means that the number of text messages currently being sent simultaneously is very large, and the concurrency is very high. At this time, most of the threads in the thread pool are working, so for the tasks newly taken out from the middleware, they are directly put back to the end of the middleware task queue. In this way, the normal operation of the task processor is guaranteed, and the concurrent pressure in the thread pool is prevented from being too high, resulting in the loss of tasks or task processing failures, thereby improving the success rate of task processing.

[0076] The present invention provides a task processing method, wherein if the processing server determines that the working state is a non-high-pressure state, a permission acquisition request is generated according to the processing rate requirement of the task, including:

[0077] The processing server determines that the working state is an ultra-low pressure state, or the working state is a low pressure state and the processing rate requirement is high speed, then generates a first permission acquisition request according to the processing rate requirement of the task; the first permission acquisition request is used to obtain a permission indication and an acquisition indication at the next moment.

[0078] In the above example, the number of concurrent threads is less than 60, and the proportion of concurrent threads in the thread pool is less than 30%; or, the number of concurrent threads is 61-100, the proportion of concurrent threads in the thread pool is within [30%, 50%] and the task processing rate is required to be high speed, then a first permission acquisition request is generated to obtain a permission indication from the current limiting server, and if the permission indication cannot be obtained, the generation time of the next permission indication is obtained, and when the generation time is reached, the permission indication is obtained from the current limiting server.

[0079] For another example, if the task is a text message, the thread in the thread pool is a text message sending processing thread, the number of concurrent threads is less than 60, and the proportion of concurrent threads in the thread pool is less than 30%; or, the number of concurrent threads is 61-100, the proportion of concurrent threads in the thread pool is within [30%, 50%], and the channel rate requirement of the text message for the text message sending channel provided by the operator is high speed (greater than the set rate threshold, which can be set as needed), then a first permission acquisition request is generated to obtain a token and a waiting time from the current limiting server. If the token cannot be obtained, the next token generation time is obtained, and the current text message sending processing thread sleeps until the generation time is reached, obtains a token from the current limiting server, and performs text message sending processing. If possible, if the generation time is reached and the token still cannot be obtained from the current limiting server, the text message can be put back to the end of the middleware queue.

[0080] The present invention provides a task processing method, further comprising: when the processing server receives a permission acquisition response that does not include the permission indication but includes an acquisition indication at the next moment, the processing server sends the permission acquisition request to the current limiting server again according to the time of the acquisition indication. In other words, different permission allocation mechanisms generate permission instructions at different speeds, such as 1 / s or 1 / min, etc. If there is no available permission instruction in the corresponding permission allocation mechanism, the next permission instruction generation time can be obtained, and the processing server re-acquires the generated permission instruction when the next permission instruction generation time arrives.

[0081] The present invention provides a task processing method, wherein if the processing server determines that the working state is a non-high-pressure state, a permission acquisition request is generated according to the processing rate requirement of the task, including:

[0082] The processing server determines that the working state is a medium-pressure state, or the working state is a low-pressure state and the processing rate requirement is non-high speed, and then generates a second permission acquisition request according to the processing rate requirement of the task; the second permission acquisition request is used to obtain a permission indication;

[0083] The method also includes: when the processing server does not include the permission indication in the received permission acquisition response, the processing server puts the task back to the middleware. In the above example, the low-pressure state: the number of concurrent threads is 61-100, which is within [30%, 50%] of the concurrent thread proportion in the thread pool and the task processing rate requirement is non-high speed, or the number of concurrent threads is 101-150, which is within (50%, 75%] of the concurrent thread proportion in the thread pool. The processing server generates a second permission acquisition request. If the permission indication is obtained from the current limiting server, the task is directly processed according to the permission indication, otherwise the task is put back to the middleware. In this way, it can be ensured that tasks with low-speed requirements for task processing rates will not block the processing of high-rate tasks.

[0084] The present invention provides a task processing method, which, before generating a permission acquisition request according to the processing rate requirement of the task, also includes: the processing server generates a clock acquisition request and sends the clock acquisition request to the current limiting server; the processing server obtains the clock information returned by the current limiting server; the clock information is included in the permission acquisition request. That is to say, before generating the permission acquisition request, the processing server needs to obtain the clock information of the current limiting server. Since the generation speed of the permission indication in the permission allocation mechanism in the current limiting server is based on the clock information in the current limiting server, in order to ensure that the processing server can accurately determine the time to obtain the permission indication, such as when the processing server obtains the next permission indication generation time, the clock information of the processing server itself is synchronized with the clock information in the current limiting server, so that the permission indication can be obtained in time when the next permission indication generation time arrives. And when the processing server cluster performs task processing at the same time, any task processing server in the task processing server cluster obtains the permission indication from the current limiting server or the current limiting server cluster, it is necessary to ensure that all processing servers in the task processing server cluster and all current limiting servers in the current limiting server cluster are in the same time process.

[0085] In addition, the permission acquisition request generated by the processing server includes clock information, and the current limiting server can also determine whether there is an available permission indication according to the clock information. The present invention provides a method flow for determining an available permission indication, such as Figure 4 As shown, including:

[0086] Step 401: The current limiting server obtains a permission acquisition request and obtains a clock in the permission acquisition request.

[0087] Step 402 , determine whether the clock is greater than the earliest generation time corresponding to the available permission indication, if so, execute step 403 , otherwise execute step 404 .

[0088] Step 403: Calculate the number of available permission indications, where the number of permission indications = (clock - earliest generation time corresponding to the available permission indication) / permission indication generation speed.

[0089] Step 404: Check whether the available permission indication quantity is greater than 0. If so, execute step 405; if not, execute step 406.

[0090] Step 405: The current limiting server generates a permission acquisition response according to the available permission indication corresponding to the current earliest generation time and returns it to the processing server.

[0091] Step 406, the current limiting server generates a permission acquisition response based on the next permission indication generation time and returns it to the processing server. Alternatively, a permission acquisition response that does not include an available permission indication and the next permission indication generation time is returned to the processing server. Here, the current limiting server can determine whether to return the next permission indication generation time in the permission acquisition response when there is no available permission indication based on the instruction type in the received permission acquisition request. In one example, if the permission indication is a token and the permission allocation mechanism is a token bucket, the instruction type in the token acquisition request can be acquire or tryAcquire. The acquire instruction is used to acquire a token, but there is no need to obtain the next token out of the bucket time. The tryAcquire instruction directly acquires the token. If the token cannot be acquired, the next token out of the bucket time is acquired.

[0092] It should be noted that the above process is only an example of a method for the current limiting server to determine the authority indication, and does not limit the specific method for determining the authority indication of the present invention.

[0093] The embodiment of the present invention provides a method for a current limiting server to obtain a permission algorithm, after the processing server obtains the task generated by the production server from the middleware, further comprising:

[0094] The processing server sends the permission algorithm to the current limiting server, obtains the algorithm number determined by the current limiting server according to the permission algorithm, and the permission algorithm is used to generate a permission allocation mechanism; generates a permission acquisition request according to the processing rate requirement of the task, including: the processing server generates a permission acquisition request according to the processing rate requirement of the task and the algorithm number, and the algorithm number is used by the current limiting server to determine the permission algorithm to be applied according to the algorithm number. That is to say, before the processing server processes the task for the first time, it is necessary to send the permission algorithm to the current limiting server, let the current limiting server run the algorithm, and return the algorithm number of the algorithm (which can be transmitted through a hash value), so that the algorithm number is included in the subsequent request sent by the processing server, and further enables the current limiting server to accurately obtain the permission algorithm corresponding to the request. In one embodiment, the permission algorithm can be a token bucket algorithm based on delayed calculation implemented by a lua (a lightweight and compact scripting language) script algorithm, and the corresponding permission allocation mechanism can be a token bucket with different token generation speeds.

[0095] An embodiment of the present invention provides a task, wherein the task is a message sending task; the middleware is a message middleware; the authority indication is a token; and different processing rate requirements correspond to different token buckets.

[0096] Based on the above method and process, an embodiment of the present invention provides a process of a task processing method; the task is a task containing batch messages, and the task processing rate requirement is the message channel rate requirement. The message channel rate requirements for all messages in a batch message are the same. The authority allocation mechanism in the current limiting server is a token bucket. Different token buckets have different token generation speeds. Different tasks can correspond to the same or different token buckets to achieve fixed-speed sending of messages in different batches, that is, to achieve current limiting for messages in different batches. Figure 5 As shown, including:

[0097] Step 501: The production server generates a task including batch messages as required. Each message of the task includes parameter information such as message channel rate, task number (different types of batch messages may correspond to different task numbers), and task type.

[0098] Step 502: The production server sends the task to the message middleware.

[0099] Step 503: When the processing server monitors that there is a task in the message middleware, it obtains the message.

[0100] Step 504: The processing server sends the token bucket algorithm script to the current limiting server.

[0101] Step 505: The current limiting server receives and stores the algorithm script, generates an algorithm number based on the algorithm script, and sends it to the processing server. The algorithm number may be a hash value.

[0102] Step 506: After receiving the algorithm number, the processing server stores the algorithm number.

[0103] Step 507: The processing server determines the working state of the current thread pool. If the working state of the current thread pool is high pressure, execute step 508; if the working state of the current thread pool is medium pressure, or low pressure and the message channel rate corresponding to the message is non-high speed, execute steps 509-514. If the working state of the current thread pool is ultra-low pressure, or low pressure and the message channel rate corresponding to the message is high speed, execute steps 515-519.

[0104] Step 508: Send the message to the message middleware.

[0105] Step 509: Generate a clock request and send it to the current limiting server.

[0106] Step 510: After receiving the clock acquisition request, the current limiting server sends the clock information of the current limiting server to the processing server.

[0107] Step 511: After receiving the clock information sent by the current limiting server, the processing server generates a permission acquisition request according to parameters such as the message channel rate, task number, task type, and clock information, and sends it to the current limiting server.

[0108] Step 512: The current limiting server receives the permission acquisition request, determines whether the token can be acquired according to the clock information in the permission acquisition request, generates a permission acquisition response according to the determination result, and returns it to the processing server. In one example, the task is a message, the permission indication is a token, the permission allocation mechanism is a token bucket, the permission acquisition request is a token acquisition request, and the token acquisition request contains an acquire instruction.

[0109] Step 513: The processing server determines whether the message has obtained a token according to the permission acquisition response. If the token has been obtained, step 514 is executed; if the token has not been obtained, step 508 is executed.

[0110] Step 514: The processing server sends the message.

[0111] Step 515: Generate a clock request and send it to the current limiting server.

[0112] Step 516: After receiving the clock acquisition request, the current limiting server sends the clock information of the current limiting server to the processing server.

[0113] Step 517: After receiving the clock information sent by the current limiting server, the processing server generates a permission acquisition request according to parameters such as the message channel rate, task number, task type, and clock information, and sends it to the current limiting server.

[0114] Step 518: The current limiting server receives the permission acquisition request, determines whether the token can be acquired or the time when the next token is released from the bucket according to the clock information in the permission acquisition request, generates a permission acquisition response according to the judgment result and the time when the next token is released from the bucket, and returns it to the processing server. In one example, the task is a message, the permission indication is a token, the permission allocation mechanism is a token bucket, the permission acquisition request is a token acquisition request, and the token acquisition request contains a tryacquire instruction.

[0115] Step 519: The processing server determines whether the message has obtained a token based on the judgment result. If the token has been obtained, the message is sent directly; if the next token bucket time is obtained, the token is obtained and the message is sent when the next token is out of the bucket.

[0116] It should be noted that the above process steps are not unique. For example, steps 504 to 506 are steps that can be executed only once for each task processor when the task processing system is initialized. Among them, the current limiting server can receive the token bucket algorithm script once for each processing server and store it only once, that is, if the current limiting server determines that the token bucket algorithm script included in the current request (the token bucket algorithm script sent by the processing server) is already included, the request will be ignored.

[0117] Based on the same concept, an embodiment of the present invention provides a task processing device. Figure 6 A schematic diagram of a task processing device provided in an embodiment of the present application is shown in FIG. Figure 6 Including:

[0118] An acquisition module 601 is used to acquire tasks generated by a production server from the middleware;

[0119] The processing module 602 is used to determine the working state of the thread pool used to process each task; if the working state is determined to be a non-high-pressure state, a permission acquisition request is generated according to the processing rate requirement of the task, and the permission acquisition request is sent to the current limiting server, and the current limiting server is used to determine the corresponding permission indication according to the processing rate requirement in each permission acquisition request; wherein different processing rate requirements correspond to different permission allocation mechanisms; the acquisition module 601 is also used to process the task through the thread in the thread pool of the processing module 602 when the received permission acquisition response contains a permission indication.

[0120] Optionally, the processing module 602 is further configured to, if it is determined that the working state is a high-pressure state, put the task back into the middleware.

[0121] Optionally, the processing module 602 is specifically used to determine that the working state is an ultra-low pressure state, or, if the working state is a low pressure state and the processing rate requirement is high speed, then generate a first permission acquisition request according to the processing rate requirement of the task; the first permission acquisition request is used to obtain a permission indication and an acquisition indication at the next moment.

[0122] Optionally, the acquisition module 601 is further configured to, when the received permission acquisition response does not include the permission indication but includes an acquisition indication for the next moment, send the permission acquisition request to the current limiting server again according to the time of the acquisition indication.

[0123] Optionally, the processing module 602 is specifically used to determine that the working state is a medium-pressure state, or, if the working state is a low-pressure state and the processing rate requirement is non-high speed, then generate a second permission acquisition request according to the processing rate requirement of the task; the second permission acquisition request is used to obtain a permission indication; the acquisition module 601 is also used to put the task back to the middleware through the processing module 602 when the received permission acquisition response does not include the permission indication.

[0124] Optionally, the processing module 602 is also used to generate a clock acquisition request, and send the clock acquisition request to the current limiting server through the acquisition module 601; the acquisition module 601 is also used to obtain clock information returned by the current limiting server; the permission acquisition request includes the clock information.

[0125] Optionally, the acquisition module 601 is also used to send the permission algorithm to the current limiting server, obtain the algorithm number determined by the current limiting server based on the permission algorithm, and the permission algorithm is used to generate a permission allocation mechanism; the processing module 602 is specifically used to generate a permission acquisition request based on the processing rate requirement of the task and the algorithm number, and the algorithm number is used by the current limiting server to determine the permission algorithm to be applied based on the algorithm number.

[0126] Optionally, the task is a message sending task; the middleware is a message middleware; the authority indication is a token; and different processing rate requirements correspond to different token buckets.

[0127] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0128] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0129] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0130] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0131] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A task processing method, characterized in that: The method comprises: The processing server obtains the tasks generated by the production server from the middleware; The processing server determines the working status of the thread pool used to process each task; The processing server determines that the working state is an ultra-low pressure state, or the working state is a low pressure state and the processing rate requirement is a high speed, then generates a first permission acquisition request according to the processing rate requirement of the task; the first permission acquisition request is used to obtain a permission indication and an acquisition indication at the next moment, and sends the permission acquisition request to the current limiting server, and the current limiting server is used to determine the corresponding permission indication according to the processing rate requirement in each permission acquisition request; wherein different processing rate requirements correspond to different permission allocation mechanisms; When the received permission acquisition response includes a permission indication, the processing server processes the task through a thread in the thread pool.

2. The method according to claim 1, characterized in that Also includes: If the processing server determines that the working state is a high-pressure state, the task is returned to the middleware.

3. The method according to claim 1, characterized in that Also includes: When the received permission acquisition response does not include the permission indication but includes an acquisition indication at the next moment, The processing server sends the permission acquisition request to the current limiting server again according to the time of obtaining the indication.

4. The method according to claim 1, characterized in that If the processing server determines that the working state is a non-high-pressure state, then generating a permission acquisition request according to the processing rate requirement of the task, including: The processing server determines that the working state is a medium-pressure state, or the working state is a low-pressure state and the processing rate requirement is non-high speed, then generates a second permission acquisition request according to the processing rate requirement of the task; the second permission acquisition request is used to obtain a permission indication; The method further comprises: When the received permission acquisition response does not include the permission indication, the processing server returns the task to the middleware.

5. The method according to claim 1, characterized in that Before generating a permission acquisition request according to the processing rate requirement of the task, the method further includes: The processing server generates a clock acquisition request, and sends the clock acquisition request to the current limiting server; The processing server obtains the clock information returned by the current limiting server; and the permission acquisition request includes the clock information.

6. The method according to claim 1, characterized in that After the processing server obtains the tasks generated by the production server from the middleware, it also includes: The processing server sends the permission algorithm to the current limiting server, and obtains the algorithm number determined by the current limiting server according to the permission algorithm, wherein the permission algorithm is used to generate a permission allocation mechanism; Generate a permission acquisition request according to the processing rate requirement of the task, including: The processing server generates a permission acquisition request according to the processing rate requirement of the task and the algorithm number, and the algorithm number is used by the current limiting server to determine the permission algorithm of the application according to the algorithm number.

7. The method according to any one of claims 1 to 6, characterized in that: The task is a message sending task; the middleware is a message middleware; the authority indication is a token; different processing rate requirements correspond to different token buckets.

8. A task processing system, characterized in that: The task processing system includes a production server cluster, middleware, a processing server cluster and a current limiting server cluster; Any production server in the production server cluster is used for production tasks; The middleware is used to store tasks in a queue manner; Any processing server in the processing server cluster is used to execute any method as claimed in claims 1 to 7; Any current limiting server in the current limiting server cluster is used to limit the task processing speed according to the authority algorithm and the processing rate requirement.

9. A task processing device, characterized in that: The device comprises: The acquisition module is used to obtain the tasks generated by the production server from the middleware; A processing module, used to determine the working state of a thread pool used to process each task; if the processing server determines that the working state is an ultra-low pressure state, or the working state is a low pressure state and the processing rate requirement is a high speed, a first permission acquisition request is generated according to the processing rate requirement of the task; the first permission acquisition request is used to obtain a permission indication and an acquisition indication at the next moment, and the permission acquisition request is sent to a current limiting server, and the current limiting server is used to determine a corresponding permission indication according to the processing rate requirement in each permission acquisition request; wherein different processing rate requirements correspond to different permission allocation mechanisms; The acquisition module is further configured to process the task through a thread in the thread pool of the processing module when the received permission acquisition response includes a permission indication.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a program, and when the program is run on a computer, the computer is enabled to implement the method according to any one of claims 1 to 7.

11. A computer device, characterized in that: include: Memory for storing computer programs; A processor is used to call the computer program stored in the memory, and execute the method according to any one of claims 1 to 7 according to the obtained program.

Images