CN112801559A - Service request processing method, device, equipment and storage medium - Google Patents
Service request processing method, device, equipment and storage medium Download PDFInfo
- Publication number
- CN112801559A CN112801559A CN202110381108.XA CN202110381108A CN112801559A CN 112801559 A CN112801559 A CN 112801559A CN 202110381108 A CN202110381108 A CN 202110381108A CN 112801559 A CN112801559 A CN 112801559A
- Authority
- CN
- China
- Prior art keywords
- service request
- thread
- work
- target
- polling
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
- G06Q10/103—Workflow collaboration or project management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Human Resources & Organizations (AREA)
- Strategic Management (AREA)
- Entrepreneurship & Innovation (AREA)
- Economics (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Marketing (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Tourism & Hospitality (AREA)
- Quality & Reliability (AREA)
- Operations Research (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Development Economics (AREA)
- Data Mining & Analysis (AREA)
- Technology Law (AREA)
- Educational Administration (AREA)
- Game Theory and Decision Science (AREA)
- Telephonic Communication Services (AREA)
Abstract
The application provides a service request processing method, a service request processing device, service request processing equipment and a storage medium, which are applied to an electronic transaction system, wherein the system is provided with a plurality of working thread groups with different delay levels, and the service request processing method comprises the following steps: after receiving a service request, determining the delay level of the service request; acquiring a target working thread in the working thread group matched with the delay level; and processing the service request by using the target working thread based on the polling parameters (including the upper limit of the polling times and the polling interval) corresponding to the delay level of the working thread group. The polling times and the polling intervals can control the delay of the service requests processed by the working threads with different delay levels, and the scheme utilizes the working threads matched with the delay levels of the service requests to process the service requests, so that the delay of the processing process can meet the requirements of different service requests.
Description
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a method, an apparatus, a device, and a storage medium for processing a service request.
Background
The electronic transaction system is a system for automatically processing various service requests by using a computer program. In order to process a large number of service requests made by multiple accounts in a system, a multithreading mechanism is often adopted in the current electronic transaction system, that is, multiple working threads are created in advance, each working thread has a corresponding working queue, and the multiple working threads can read and process the service requests from the respective working queues in parallel (generally, written by communication threads).
In order to save computer resources, an event notification mechanism is generally adopted in an existing multithreading mechanism to trigger a working thread to process a service request, that is, a communication thread writes one service request into a certain working queue, and then notifies a corresponding working thread to read the service request through the working thread notification event.
The problem with the event notification mechanism is that there is a long delay (at least 5 mus) in the processing of the service request, especially from the writing of the service request by the communication thread to the reading of the service request by the working thread, whereas there are a large number of different service requests in the electronic transaction system, some of which can accept a long delay and some of which cannot accept a delay of 5 mus. Therefore, the event notification mechanism cannot meet different delay requirements of different service requests in the system.
Disclosure of Invention
Based on the above problems in the prior art, the present application provides a method, an apparatus, a device and a storage medium for processing service requests, so as to meet the delay requirements of different service requests in an electronic transaction system.
A first aspect of the present application provides a method for processing a service request, which is applied to an electronic transaction system, where the electronic transaction system includes work thread groups corresponding to different delay levels, and each work thread group includes at least one work thread, and the method includes:
receiving a service request;
determining the delay level of the service request; the delay level of the service request is related to the acceptable delay of a request account or a transaction object of the service request; the request account refers to an account sending the service request;
taking a working thread contained in a working thread group matched with the delay level of the service request as a target working thread;
processing the service request by utilizing the target working thread based on the polling parameter corresponding to the delay level of the working thread group to which the target working thread belongs; wherein the polling parameters comprise an upper limit of polling times and a polling interval.
Optionally, the processing the service request by using the polling parameter corresponding to the delay level of the target working thread based on the working thread group includes:
inquiring whether the work queue of the target work thread has the service request or not;
when the business request exists in the work queue of the target work thread, reading the business request from the work queue of the target work thread, and processing the business request by utilizing a business processing logic preset by the target work thread;
when the service request does not exist in the work queue of the target work thread, judging whether the query frequency is greater than or equal to the upper limit of the polling frequency corresponding to the delay level of the affiliated work thread group or not, and determining the current sleep time length according to the polling interval corresponding to the delay level of the affiliated work thread group and entering a sleep state when the query frequency is greater than or equal to the upper limit of the polling frequency corresponding to the delay level of the affiliated work thread group; the query times are cleared when the sleep state is entered;
and when the time in the sleep state reaches the current sleep time, quitting the sleep state, and returning to the step of executing the step of inquiring whether the service request exists in the work queue of the target work thread.
Optionally, the determining the current sleep duration according to the polling interval corresponding to the delay level of the working thread group includes:
judging whether the sleep time length when the previous sleep state is entered is greater than or equal to the polling interval corresponding to the delay level of the working thread group;
if the sleep time length when the previous sleep state is entered is greater than or equal to the polling interval corresponding to the delay level of the working thread group, determining the preset initial sleep time length as the current sleep time length;
if the sleep time length when the previous sleep state is entered is smaller than the polling interval corresponding to the delay level of the working thread group, the sleep time length when the previous sleep state is entered is adjusted up according to the preset step length, and the current sleep time length is obtained.
Optionally, the reading the service request from the work queue of the target work thread includes:
reading the data pointers of the service request and the request account from the work queue of the target work thread; wherein the request account refers to an account that sent the service request; the data pointer of the request account and the service request are written into a work queue of the target work thread; the data pointer of the requesting account is used for indicating the storage address of the account data of the requesting account.
Optionally, before the processing the service request by using the target working thread based on the polling parameter corresponding to the delay level of the working thread group, the method further includes:
if the target working thread is not acquired, processing the service request according to a preset service processing logic by using a communication thread;
and if the target working thread is obtained, executing the step of processing the service request by utilizing the polling parameter corresponding to the delay level of the working thread group to which the target working thread belongs.
A second aspect of the present application provides a processing apparatus for service requests, which is applied to an electronic transaction system, where the electronic transaction system includes work thread groups corresponding to different delay levels, each of the work thread groups includes at least one work thread, and the processing apparatus includes:
a receiving unit, configured to receive a service request;
a determining unit, configured to determine a delay level to which the service request belongs; the delay level of the service request is related to the acceptable delay of a request account or a transaction object of the service request; the request account refers to an account sending the service request;
the obtaining unit is used for taking a working thread contained in a working thread group with the matched delay level of the service request as a target working thread;
the processing unit is used for processing the service request by utilizing the polling parameter corresponding to the delay level of the target working thread based on the working thread group; wherein the polling parameters comprise an upper limit of polling times and a polling interval.
Optionally, when the processing unit processes the service request by using the polling parameter corresponding to the delay level of the target working thread based on the working thread group to which the target working thread belongs, the processing unit is specifically configured to:
inquiring whether the work queue of the target work thread has the service request or not;
when the business request exists in the work queue of the target work thread, reading the business request from the work queue of the target work thread, and processing the business request by utilizing a business processing logic preset by the target work thread;
when the service request does not exist in the work queue of the target work thread, judging whether the query frequency is greater than or equal to the upper limit of the polling frequency corresponding to the delay level of the affiliated work thread group or not, and determining the current sleep time length according to the polling interval corresponding to the delay level of the affiliated work thread group and entering a sleep state when the query frequency is greater than or equal to the upper limit of the polling frequency corresponding to the delay level of the affiliated work thread group; the query times are cleared when the sleep state is entered;
and when the time in the sleep state reaches the current sleep time, quitting the sleep state, and returning to the step of executing the step of inquiring whether the service request exists in the work queue of the target work thread.
Optionally, the processing unit determines the current sleep duration according to a polling interval corresponding to the delay level of the working thread group, and is specifically configured to:
judging whether the sleep time length when the previous sleep state is entered is greater than or equal to the polling interval corresponding to the delay level of the working thread group;
if the sleep time length when the previous sleep state is entered is greater than or equal to the polling interval corresponding to the delay level of the working thread group, determining the preset initial sleep time length as the current sleep time length;
if the sleep time length when the previous sleep state is entered is smaller than the polling interval corresponding to the delay level of the working thread group, the sleep time length when the previous sleep state is entered is adjusted up according to the preset step length, and the current sleep time length is obtained.
Optionally, when the processing unit reads the service request from the work queue of the target work thread, the processing unit is specifically configured to:
reading the data pointers of the service request and the request account from the work queue of the target work thread; wherein the request account refers to an account that sent the service request; the data pointer of the request account and the service request are written into a work queue of the target work thread; the data pointer of the requesting account is used for indicating the storage address of the account data of the requesting account.
Optionally, the processing unit is further configured to:
if the target working thread is not acquired, processing the service request according to preset service processing logic;
and if the target working thread is obtained, executing the step of processing the service request by utilizing the polling parameter corresponding to the delay level of the working thread group to which the target working thread belongs.
A third aspect of the present application provides an electronic device comprising a memory and a processor;
the memory is used for storing a computer program;
the processor is configured to execute the computer program, and in particular, is configured to implement the service request processing method provided in any one of the first aspects of the present application.
A fourth aspect of the present application provides a computer storage medium for storing a computer program, where the computer program is specifically configured to implement the method for processing a service request provided in any one of the first aspects of the present application when executed.
The application provides a service request processing method, a service request processing device, service request processing equipment and a storage medium, which are applied to an electronic transaction system, wherein the system is provided with a plurality of working thread groups with different delay levels, and the service request processing method comprises the following steps: after receiving a service request, determining the delay level of the service request; the delay level of the service request represents the acceptable delay upper limit of the service request; acquiring a target working thread in the working thread group matched with the delay level; and processing the service request by using the target working thread based on the polling parameters (including the upper limit of the polling times and the polling interval) corresponding to the delay level of the working thread group. The polling times and the polling intervals can control the delay of the service requests processed by the working threads with different delay levels, and the scheme utilizes the working threads matched with the delay levels of the service requests to process the service requests, so that the delay of the processing process can meet the requirements of different service requests.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the provided drawings without creative efforts.
Fig. 1 is a schematic diagram of an architecture of an electronic transaction system according to an embodiment of the present application;
fig. 2 is a flowchart of a method for processing a service request according to an embodiment of the present application;
fig. 3 is a schematic structural diagram of a service request processing apparatus according to an embodiment of the present application;
fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The processing scheme of the service request provided by the application is mainly applicable to the electronic transaction system, and can be specifically executed by a communication thread in the electronic transaction system.
Referring to fig. 1, an electronic transaction system is generally deployed at a server, and mainly includes a communication thread and a work thread, where each work thread is configured with a corresponding work queue, after any account logs in the electronic transaction system through a client, a service request, such as selling or purchasing a financial product, may be sent to the electronic transaction system, the service request may be received by the communication thread in the electronic transaction system, and then the communication thread writes the service request into a work queue, and simultaneously, each work thread may read the service request one by one from its work queue and process each read service request in real time, so that the electronic transaction system may process the service request of each account.
Based on the electronic transaction system, the present application provides a method for processing a service request, which can be applied to the electronic transaction system, please refer to fig. 2, where the method specifically includes the following steps:
it should be noted that, in the processing method provided by the present application, an execution subject of the processing method may be each communication thread shown in fig. 1, in other words, each communication thread in fig. 1 may write the received service request into a corresponding work queue according to the method provided by the present application.
S201, receiving a service request.
As mentioned above, the service request may be sent by any account while logging in the electronic transaction system, and received by any communication thread in the electronic transaction system.
The service request may specifically carry the following information:
account information of the requested account, such as account number, account level, etc., transaction activities to be performed (such as sale or purchase), and the transaction object to be dealt with. For example, account a requests the electronic trading system to purchase a certain amount of stock B, the sent service request may carry account information of account a and stock code of stock B and indicate that the trading behavior is purchase, for this service request, account a is the requested account of the service request, and stock B is the trading object of the service request.
S202, determining the delay level of the service request.
The delay level to which the service request belongs is related to the acceptable delay of the request account or the transaction object of the service request.
In the electronic transaction system provided by the application, a plurality of delay levels can be preset, each account belongs to one of the delay levels, and for example, three delay levels, namely a high level, a medium level and a low level, can be divided from high to low.
Based on the set multiple delay levels, the service request received by the electronic transaction system can be divided into different delay levels according to the dimension of the transaction object or the dimension of the request account.
If the accounts are divided from the dimension of the request account, the accounts in the electronic transaction system can be divided into different delay levels according to the acceptable delay length, and the lower the delay level of an account is, the longer the delay acceptable by the account is, that is, the lower the requirement of the account on the timeliness of the processing of the service request is.
Generally, in an existing electronic transaction system, a plurality of account levels are usually set according to previous use conditions and consumption conditions of each account, such as a common account, a VIP account, a super VIP account, and the like.
After the accounts in the system are divided into the delay levels set, in step S202, the delay level to which the service request belongs can be determined directly according to the request account of the service request. For example, if a request account of a service request belongs to a medium-level delay level, the delay level to which the service request belongs is also a medium-level delay level, and if a request account of a service request belongs to a low-level delay level, the delay level to which the service request belongs is also a low-level delay level.
That is, when the dimension of the request account is divided, the delay level to which the service request belongs is the delay level to which the request account of the service request belongs.
If the dimension of the transaction object is divided, all financial products related to the electronic transaction system can be divided into different delay levels according to the acceptable delay length. The lower the delay level of a stock, the longer the delay that the stock can accept, i.e., the lower the timeliness of the processing of the business request for the stock.
For example, the electronic trading system may support trading of 100 stocks (i.e., 100 trading objects related to the electronic trading system) by a user, wherein the quotations of some stocks fluctuate sharply and are easy to fluctuate greatly in a short time, the stocks may be classified into a higher delay level, the quotations of some stocks are stable and do not fluctuate greatly, and the stocks may be classified into a lower delay level.
After dividing each transaction object supported by the system into each set delay level, in step S202, the delay level to which the service request belongs may be determined directly according to the transaction object to which the service request is directed. For example, if a stock a requested to be traded by a service request (i.e., the trading object of the service request) belongs to a middle-level delay level, the delay level to which the service request belongs is also a middle-level delay level, and if a stock B requested to be traded by a service request belongs to a lower-level delay level, the delay level to which the service request belongs is also a lower level.
That is, when the transaction object is divided from the dimension, the delay level to which the service request belongs is the delay level to which the transaction object of the service request belongs.
S203, acquiring a working thread contained in the working thread group with the matched delay level of the service request as a target working thread.
In the present application, a plurality of working threads of the electronic trading system are pre-divided into different working thread groups, each working thread group also corresponds to each of the aforementioned delay levels, for example, for high-level, middle-level and low-level delay levels, working thread groups a, B and C can be divided, wherein working thread group a corresponds to a high level in the delay levels, working thread group B corresponds to a middle level, working thread group C corresponds to a low level, working threads of different working thread groups run based on different parameters, and by setting different parameters, working threads of different working thread groups can have delays of different lengths when reading service requests from a working queue.
Accordingly, in step S203, the work thread group corresponding to the delay level to which the service request belongs can be determined from the plurality of work thread groups, and the work thread group is used as the work thread group with the delay level to which the service request belongs.
For example, in step S202, it is determined that the delay level of the currently received service request is high, and in step S203, one worker thread may be selected from the worker thread group a corresponding to the high level as the target thread.
Different work thread groups can be distinguished by alias names, as described in the foregoing a, B, and C, meanwhile, an access interface may be implemented in the system for each work thread group, where the access interface records the thread program number of the work thread included in the work thread group, for example, the work thread group a includes work threads with serial numbers 1 to 5, the work thread group B includes work threads with serial numbers 6 to 10, and the work thread group C includes work threads with serial numbers 11 to 15.
Based on the above configuration, in step S203, the communication thread may first access the access interface corresponding to the work thread group with the delay level matching the service request, such as the access interface of the work thread group a, then select a thread program number from the thread program numbers recorded by the access interface, and determine the work thread identified by the thread program number as the target work thread.
And S204, processing the service request by using the target working thread based on the polling parameter corresponding to the delay level of the working thread group.
Step S204 specifically includes writing, by the communication thread, the service request into the work queue corresponding to the target work thread, and polling, by the target work thread, the work queue corresponding to the polling parameter corresponding to the delay level of the work thread group to which the target work thread belongs, thereby reading, in the work queue, the service request written by the communication thread, and then processing, according to a preset service processing logic, the read service request.
Wherein, the polling parameters comprise an upper limit of the polling times and a polling interval.
Generally, when a work thread processes a service request, account data of the requesting account is usually needed, and the account data may include which financial products the account currently holds, how much credit the account holds, and the like, so for the service request related to financial product transaction, the work thread needs to verify and update the account data of the requesting account during processing, and therefore in step S204, the communication thread may write the service request and the data pointer of the requesting account into the work queue of the target work thread together; the data pointer of the requesting account is used to indicate the storage address of the account data of the requesting account. Therefore, when the work thread processes the service request, the account data of the request account can be read according to the data pointer of the request account.
The data pointer of the request account, the delay level of the service request and the line program number of the target working thread can all be determined by calling a preset service positioning function in the system.
Different polling parameters are configured for the working threads of different working thread groups, and the polling parameters influence the time delay of the working threads for reading the service requests from the working queue, so that when the polling parameters are configured, the polling parameters with shorter time delay can be configured for the corresponding working thread group with higher time delay level, and the polling parameters with longer time delay can be configured for the corresponding working thread group with lower time delay level, so that the working threads of different working thread groups have time delays with different lengths when reading the service requests, and a certain service request is specifically allocated to the working thread of which working thread group and is determined by the time delay level of the service request, therefore, the scheme can adjust the time delay of each service request when being read by the working thread according to the time delay level of each service request, and the service requests with higher timeliness requirements for request accounts or transaction objects, that is, the service request with higher delay level can be allocated to the working thread in the working thread group with shorter delay, and the timeliness requirement for the request account or the transaction object is lower, so that the service request with lower delay level can be allocated to the working thread in the working thread group with longer delay, thereby ensuring that the read delay of each service request can meet the requirements of different service requests.
The following code is an example of the present application that divides different work thread groups and sets different polling parameters:
"WorkThreads":[
{
"Count":2,
"ThreadAlias":"A",
"PollingLoops":1,
"SleepTimeUS":0
},
{
"Count":1,
"ThreadAlias":"B",
"PollingLoops":100,
"SleepTimeUS":2
},
{
"Count":3,
"ThreadAlias":"C",
"PollingLoops":0
}
]
the code is divided into three working thread groups, namely working thread groups A, B and C, wherein Count represents the number of working threads contained in the working thread groups, ThreadAllias represents the alias of the working thread groups, PollongLoops represents the upper limit of the polling times, and SleepTimeUS represents the polling interval and has the unit of microseconds (us).
For example, the worker thread group a, named a, includes 2 worker threads, the upper limit of the polling number is 1, the polling interval is 0us, the worker thread group B, named B, includes 1 worker thread, the upper limit of the polling number is 100, and the polling interval is 2 us.
When the upper limit of the polling times is set to 0, for example, the work thread group C, when this is set to 0, it is described that the work threads of the work thread group do not use the polling mechanism to read the service request from the work queue, but use the event notification mechanism, that is, after the communication thread notifies the work thread by notifying the event, the work thread reads the service request from the work queue. Particularly, when the upper limit of the polling times is set to 0, the working thread does not need to set the polling interval because the working thread does not adopt the polling mechanism to read the service request any more.
That is, if it is determined that the target work thread belongs to the work thread group C, the communication thread sends a notification message to the target work thread through the notification event after writing the service request into the work queue, so as to trigger the target work thread to read the service request from the corresponding work queue, otherwise, for the work thread of the work thread group C, when the notification message is not received, the work queue of the work thread group C is not accessed, that is, the service request is not attempted to be read from the work queue.
In the three working thread groups, the delay grade corresponding to the working thread group A is highest, the delay of the working thread reading service request is shortest, the delay grade corresponding to the working thread group B is lower than A and higher than C, and the delay grade corresponding to the working thread group C is lower than B.
With reference to the foregoing example, in step S204, processing the service request by using the target worker thread based on the polling parameter corresponding to the delay level of the worker thread group to which the target worker thread belongs may specifically include:
inquiring whether a service request exists in a work queue of a target work thread;
when no service request exists in the work queue of the target work thread, judging whether the query frequency is greater than or equal to the upper limit of the polling frequency corresponding to the delay level of the work thread group to which the query frequency belongs; the query times refer to the times of whether a service request in a work queue of a target work thread executes query operation or not.
If the query times are less than the upper limit of the polling times corresponding to the delay level of the working thread group, returning to the step of executing whether the service request exists in the working queue of the query target working thread;
if the query times are greater than or equal to the upper limit of the polling times corresponding to the delay levels of the working thread groups, determining the current sleep duration according to the polling intervals corresponding to the delay levels of the working thread groups, and entering a sleep state; wherein, the query times are cleared when entering a sleep state;
when the time in the sleep state reaches the current sleep time, quitting the sleep state, and returning to the step of executing whether a service request exists in a work queue of the query target work thread;
reading the service request from the work queue of the target work thread when the service request exists in the work queue of the target work thread;
and processing the service request according to the preset service processing logic by using the target working thread.
Further, the determining, by the target working thread, the current sleep duration according to the polling interval corresponding to the delay level of the working thread group to which the target working thread belongs includes:
judging whether the sleep time length when the previous sleep state is entered is greater than or equal to the polling interval corresponding to the delay level of the working thread group;
if the sleep time length when the previous sleep state is entered is greater than or equal to the polling interval corresponding to the delay level of the working thread group, determining the preset initial sleep time length as the current sleep time length;
specifically, if the polling interval corresponding to the delay level of the work thread group is 0, the corresponding initial sleep duration is also 0.
If the sleep time length when the previous sleep state is entered is smaller than the polling interval corresponding to the delay level of the working thread group, the sleep time length when the previous sleep state is entered is adjusted up according to the preset step length, and the current sleep time length is obtained.
For example, if the polling interval is set to 5us, the initial sleep duration is 1us, and the preset step size is 1us, the working thread has a sleep duration of 1us when sleeping for the first time, a sleep duration of 2us when sleeping for the second time, and 3us, 4us, and 5us (sleep duration of the fifth sleep) after that, when the sixth sleep is started, since the sleep duration of the previous time reaches 5us of the polling interval, the sleep duration is initialized, that is, set to 1us again as the initial sleep duration, and then the above process is repeated from the sixth sleep to the tenth sleep.
The polling mechanism is described below by taking the aforementioned work thread groups a and B as examples.
If the target working thread belongs to the working thread group A, after the target working thread is started, whether a service request exists in the working queue is firstly inquired, then the inquiry frequency is increased by 1, at the moment, the inquiry frequency is 1, after the inquiry, if the service request exists, a service request is read and processed, if no service request exists, the inquiry frequency is judged to reach the upper limit of the polling frequency of the belonging working thread group A, then the inquiry frequency is cleared, the current sleep time length is determined, as the polling interval of the working thread group A is 0, the current sleep time length is set to be 0, namely, the sleep is not carried out, then, the target working thread inquires whether the service request exists in the working queue again, and the process is repeated.
It can be seen that, since the polling interval of the work thread group a is 0, the work threads belonging to the work thread group a continuously query the work queue in real time, and read and process the service request if the service request is queried, the time delay of the work thread group a in reading the service request is shortest, and when the service request is allocated to the work thread of the work thread group a, the work thread can read and process the service request from the work queue at the first time after the service request is written.
If the target working thread belongs to the working thread group B, after starting, the target working thread performs one-time query, then the query frequency is increased by 1, if the query frequency is 1 at the moment, after the query, if a service request exists, a service request is read and processed, if no service request exists, the query is continued until the query frequency is accumulated to 100 because the query frequency does not reach the upper limit of the polling frequency of 100.
When the query times are accumulated to 100, namely the upper limit of the polling times of the working thread group B is reached, determining the initial sleep time of 1us as the current sleep time, then resetting the query times, starting sleep, starting the target working thread after the sleep of 1us, repeating the query process until the query times reach the upper limit of the polling times again, then adjusting the current sleep time up according to the preset step length of 1us, namely setting the current sleep time to 2us, then resetting the query times, starting the sleep again after the sleep of 2us and 2us, and repeating the query process.
When the inquiry times reach the upper limit of the polling times for the third time and the third sleep is needed, the sleep time length of the third time is set as the initial sleep time length 1us because the previous sleep time length reaches the polling interval 2 us. The subsequent processes are analogized.
It can be seen that, since the worker threads of the worker thread group B sleep for 1us to 2us, when reading the service request, there may be a delay of 1us to 2us compared to the worker thread group a, and therefore the corresponding delay level is lower than that of the worker thread group a.
Optionally, to avoid a conflict between a process of writing a service request to a work queue by a communication thread and a process of reading a service request by a work thread, when a service request is written to a work queue by a communication thread, the work queue may be locked by a locking operation, and after the writing is completed, the work queue is unlocked.
If the communication thread needs to write a service request into the work queue of the work thread with the polling frequency upper limit of 0, the communication thread may add a mutual exclusion lock to the work queue to lock the work queue, then write the service request into the work queue, and after the writing is completed, remove the mutual exclusion lock of the work queue and notify the work thread through a notification event, so that the work thread reads the service request from the work queue.
If the communication thread needs to write a service request into the work queue of the work thread with the polling frequency upper limit larger than 0, the communication thread may add a spin lock to the work queue to lock the work queue, then write the service request into the work queue, and after the write is completed, remove the spin lock of the work queue, so that the corresponding work thread can query the work queue and read the service request after querying the service request.
Optionally, before step S204, if the communication thread does not acquire the target working thread, the communication thread may directly process the service request according to a preset service processing logic;
and if the target working thread is obtained, executing a step of processing the service request by using the polling parameter corresponding to the delay level of the working thread group to which the target working thread belongs, namely executing the step S204.
When the working thread groups are divided, the number of the working thread groups can be one less than that of the delay levels, for example, four delay levels are divided from high to low, and are sequentially super, high, middle and low.
Based on the above setting, when the communication thread receives the service request belonging to the special level, because no working thread group matched with the special level exists, the target working thread meeting the conditions cannot be obtained naturally, and then the communication thread calls the preset service processing logic to process the service request belonging to the communication thread, so that the flow that the service request is written into the working queue and then read by the working thread is completely cancelled, the time consumed for processing the service request is shortened to the maximum extent, and the requirement of the service request belonging to the special level on timeliness is met.
With reference to fig. 3, the apparatus for processing a service request according to an embodiment of the present application may include the following units:
a receiving unit 301, configured to receive a service request.
A determining unit 302, configured to determine a delay level to which the service request belongs.
The delay level of the service request is related to the acceptable delay of a request account or a transaction object of the service request; a request account refers to an account that sends a service request.
The obtaining unit 303 is configured to obtain a working thread included in the working thread group with the delay level matched with the service request as a target working thread.
And the processing unit 304 is configured to process the service request by using the target worker thread based on the polling parameter corresponding to the delay level of the worker thread group to which the target worker thread belongs.
Wherein, the polling parameters comprise an upper limit of the polling times and a polling interval.
Optionally, the processing unit 304 is further configured to:
if the target working thread is not acquired, processing the service request according to preset service processing logic;
and if the target working thread is obtained, executing the polling parameter processing service request corresponding to the delay level of the working thread group to which the target working thread belongs.
Optionally, when the processing unit 304 processes the service request by using the target working thread based on the polling parameter corresponding to the delay level of the working thread group to which the target working thread belongs, the processing unit is specifically configured to:
inquiring whether a service request exists in a work queue of a target work thread;
when no service request exists in the work queue of the target work thread, judging whether the query frequency is greater than or equal to the upper limit of the polling frequency corresponding to the delay level of the work thread group to which the query frequency belongs;
if the query times are less than the upper limit of the polling times corresponding to the delay level of the working thread group, returning to the step of executing whether the service request exists in the working queue of the query target working thread;
if the query times are greater than or equal to the upper limit of the polling times corresponding to the delay levels of the working thread groups, determining the current sleep duration according to the polling intervals corresponding to the delay levels of the working thread groups, and entering a sleep state; wherein, the query times are cleared when entering a sleep state;
when the time in the sleep state reaches the current sleep time, quitting the sleep state, and returning to the step of executing whether a service request exists in a work queue of the query target work thread;
reading the service request from the work queue of the target work thread when the service request exists in the work queue of the target work thread;
and processing the service request by using the target working thread based on the preset service processing logic.
Optionally, the processing unit 304 determines the current sleep duration according to the polling interval corresponding to the delay level of the working thread group, and is specifically configured to:
judging whether the sleep time length when the previous sleep state is entered is greater than or equal to the polling interval corresponding to the delay level of the working thread group;
if the sleep time length when the previous sleep state is entered is greater than or equal to the polling interval corresponding to the delay level of the working thread group, determining the preset initial sleep time length as the current sleep time length;
if the sleep time length when the previous sleep state is entered is smaller than the polling interval corresponding to the delay level of the working thread group, the sleep time length when the previous sleep state is entered is adjusted up according to the preset step length, and the current sleep time length is obtained.
Optionally, when the processing unit 304 reads the service request from the work queue of the target work thread, the processing unit is specifically configured to:
and reading the data pointer of the service request and the request account from the work queue of the target work thread.
The data pointer of the request account and the service request are written into a work queue of the target work thread; the data pointer of the requesting account is used to indicate the storage address of the account data of the requesting account.
For the processing device of the service request provided in the embodiment of the present application, specific working principles thereof may refer to relevant steps in the processing method of the service request provided in the embodiment of the present application, and details are not described here again.
The application provides a processing device of a business request, apply to the electronic transaction system, the electronic transaction system includes the work thread group corresponding to different time delay grades, each work thread group includes a plurality of work threads, in the processing device, the receiving element 301 receives the business request; the determining unit 302 determines the delay level to which the service request belongs; the obtaining unit 303 obtains a working thread included in a working thread group whose delay level is matched with the service request as a target working thread; the processing unit 304 processes the service request by using the target worker thread based on the polling parameter corresponding to the delay level of the worker thread group, where the polling parameter includes a polling frequency upper limit and a polling interval. The corresponding polling times and intervals are configured for the working threads with different delay levels, and the delay time of the working threads with different delay levels for processing the service request can be controlled, so that when the service request is processed, the service request can be distributed to the working queue of the working thread matched with the delay level according to the delay level to which the service request belongs, and the service request is processed with the delay time to meet the requirement of the service request.
An electronic device is further provided in the embodiments of the present application, please refer to fig. 4, and the electronic device may include a memory 401 and a processor 402.
The memory 401 is used for storing a computer program, among other things.
The processor 402 is configured to execute a computer program, and is specifically configured to implement the service request processing method provided in any embodiment of the present application.
The embodiments of the present application further provide a computer storage medium, which is used to store a computer program, and when the computer program is executed, the computer program is specifically used to implement the service request processing method provided in any embodiment of the present application.
Finally, it should also be noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
It should be noted that the terms "first", "second", and the like in the present invention are only used for distinguishing different devices, modules or units, and are not used for limiting the order or interdependence relationship of the functions performed by the devices, modules or units.
Those skilled in the art can make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (12)
1. A method for processing service requests is applied to an electronic transaction system, the electronic transaction system comprises work thread groups corresponding to different delay levels, each work thread group comprises at least one work thread, and the processing method comprises the following steps:
receiving a service request;
determining the delay level of the service request; the delay level of the service request is related to the acceptable delay of a request account or a transaction object of the service request; the request account refers to an account sending the service request;
taking a working thread contained in a working thread group matched with the delay level of the service request as a target working thread;
processing the service request by utilizing the target working thread based on the polling parameter corresponding to the delay level of the working thread group to which the target working thread belongs; wherein the polling parameters comprise an upper limit of polling times and a polling interval.
2. The processing method according to claim 1, wherein said processing the service request by using the polling parameter corresponding to the delay level of the target worker thread based on the worker thread group comprises:
inquiring whether the work queue of the target work thread has the service request or not;
when the business request exists in the work queue of the target work thread, reading the business request from the work queue of the target work thread, and processing the business request by utilizing a business processing logic preset by the target work thread;
when the service request does not exist in the work queue of the target work thread, judging whether the query frequency is greater than or equal to the upper limit of the polling frequency corresponding to the delay level of the affiliated work thread group or not, and determining the current sleep time length according to the polling interval corresponding to the delay level of the affiliated work thread group and entering a sleep state when the query frequency is greater than or equal to the upper limit of the polling frequency corresponding to the delay level of the affiliated work thread group; the query times are cleared when the sleep state is entered;
and when the time in the sleep state reaches the current sleep time, quitting the sleep state, and returning to the step of executing the step of inquiring whether the service request exists in the work queue of the target work thread.
3. The processing method according to claim 2, wherein the determining the current sleep duration according to the polling interval corresponding to the delay level of the working thread group includes:
judging whether the sleep time length when the previous sleep state is entered is greater than or equal to the polling interval corresponding to the delay level of the working thread group;
if the sleep time length when the previous sleep state is entered is greater than or equal to the polling interval corresponding to the delay level of the working thread group, determining the preset initial sleep time length as the current sleep time length;
if the sleep time length when the previous sleep state is entered is smaller than the polling interval corresponding to the delay level of the working thread group, the sleep time length when the previous sleep state is entered is adjusted up according to the preset step length, and the current sleep time length is obtained.
4. The processing method according to claim 2, wherein said reading the service request from the work queue of the target worker thread comprises:
reading the data pointers of the service request and the request account from the work queue of the target work thread; wherein the request account refers to an account that sent the service request; the data pointer of the request account and the service request are written into a work queue of the target work thread; the data pointer of the requesting account is used for indicating the storage address of the account data of the requesting account.
5. The processing method according to claim 1, wherein before processing the service request by the target worker thread based on the polling parameter corresponding to the latency level of the worker thread group, the method further comprises:
if the target working thread is not acquired, processing the service request according to a preset service processing logic by using a communication thread;
and if the target working thread is obtained, executing the step of processing the service request by utilizing the polling parameter corresponding to the delay level of the working thread group to which the target working thread belongs.
6. A service request processing apparatus, applied to an electronic transaction system, the electronic transaction system including work thread groups corresponding to different delay levels, each of the work thread groups including at least one work thread, the processing apparatus comprising:
a receiving unit, configured to receive a service request;
a determining unit, configured to determine a delay level to which the service request belongs; the delay level of the service request is related to the acceptable delay of a request account or a transaction object of the service request; the request account refers to an account sending the service request;
the obtaining unit is used for taking a working thread contained in a working thread group with the matched delay level of the service request as a target working thread;
the processing unit is used for processing the service request by utilizing the polling parameter corresponding to the delay level of the target working thread based on the working thread group; wherein the polling parameters comprise an upper limit of polling times and a polling interval.
7. The processing apparatus according to claim 6, wherein when the processing unit processes the service request by using the polling parameter corresponding to the delay level of the target worker thread based on the worker thread group to which the target worker thread belongs, the processing unit is specifically configured to:
inquiring whether the work queue of the target work thread has the service request or not;
when the business request exists in the work queue of the target work thread, reading the business request from the work queue of the target work thread, and processing the business request by utilizing a business processing logic preset by the target work thread;
when the service request does not exist in the work queue of the target work thread, judging whether the query frequency is greater than or equal to the upper limit of the polling frequency corresponding to the delay level of the affiliated work thread group or not, and determining the current sleep time length according to the polling interval corresponding to the delay level of the affiliated work thread group and entering a sleep state when the query frequency is greater than or equal to the upper limit of the polling frequency corresponding to the delay level of the affiliated work thread group; the query times are cleared when the sleep state is entered;
and when the time in the sleep state reaches the current sleep time, quitting the sleep state, and returning to the step of executing the step of inquiring whether the service request exists in the work queue of the target work thread.
8. The processing apparatus according to claim 7, wherein the processing unit determines the current sleep duration according to a polling interval corresponding to the delay level of the working thread group, and is specifically configured to:
judging whether the sleep time length when the previous sleep state is entered is greater than or equal to the polling interval corresponding to the delay level of the working thread group;
if the sleep time length when the previous sleep state is entered is greater than or equal to the polling interval corresponding to the delay level of the working thread group, determining the preset initial sleep time length as the current sleep time length;
if the sleep time length when the previous sleep state is entered is smaller than the polling interval corresponding to the delay level of the working thread group, the sleep time length when the previous sleep state is entered is adjusted up according to the preset step length, and the current sleep time length is obtained.
9. The processing apparatus according to claim 7, wherein when the processing unit reads the service request from the work queue of the target work thread, it specifically performs:
reading the data pointers of the service request and the request account from the work queue of the target work thread; wherein the request account refers to an account that sent the service request; the data pointer of the request account and the service request are written into a work queue of the target work thread; the data pointer of the requesting account is used for indicating the storage address of the account data of the requesting account.
10. The processing apparatus as in claim 6, wherein the processing unit is further configured to:
if the target working thread is not acquired, processing the service request according to preset service processing logic;
and if the target working thread is obtained, executing the step of processing the service request by utilizing the polling parameter corresponding to the delay level of the working thread group to which the target working thread belongs.
11. An electronic device comprising a memory and a processor;
the memory is used for storing a computer program;
the processor is configured to execute the computer program, and in particular to implement the method for processing a service request according to any one of claims 1 to 5.
12. A computer storage medium for storing a computer program, which, when executed, is particularly adapted to implement the method of processing a service request according to any of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110381108.XA CN112801559A (en) | 2021-04-09 | 2021-04-09 | Service request processing method, device, equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110381108.XA CN112801559A (en) | 2021-04-09 | 2021-04-09 | Service request processing method, device, equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112801559A true CN112801559A (en) | 2021-05-14 |
Family
ID=75816700
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110381108.XA Pending CN112801559A (en) | 2021-04-09 | 2021-04-09 | Service request processing method, device, equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112801559A (en) |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102541659A (en) * | 2011-12-30 | 2012-07-04 | 重庆新媒农信科技有限公司 | Method and device for processing of server service requests |
| WO2015096656A1 (en) * | 2013-12-26 | 2015-07-02 | 华为技术有限公司 | Thread creation method, service request processing method and related device |
| CN106851796A (en) * | 2016-12-14 | 2017-06-13 | 努比亚技术有限公司 | A kind of data card and its method for realizing Wi Fi focuses |
| CN107491350A (en) * | 2017-09-05 | 2017-12-19 | 武汉斗鱼网络科技有限公司 | Interface task call method and device |
| CN108415759A (en) * | 2017-02-09 | 2018-08-17 | 阿里巴巴集团控股有限公司 | Processing method, device and the electronic equipment of message |
| CN109582455A (en) * | 2018-12-03 | 2019-04-05 | 恒生电子股份有限公司 | Multithreading task processing method, device and storage medium |
| CN111225041A (en) * | 2019-12-26 | 2020-06-02 | 的卢技术有限公司 | Method and system for realizing delay message queue |
| CN111367629A (en) * | 2020-03-30 | 2020-07-03 | 绿盟科技集团股份有限公司 | Delayed task processing method and device |
| CN112148506A (en) * | 2020-09-25 | 2020-12-29 | 北京自如信息科技有限公司 | Message processing method, device, platform and storage medium |
-
2021
- 2021-04-09 CN CN202110381108.XA patent/CN112801559A/en active Pending
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102541659A (en) * | 2011-12-30 | 2012-07-04 | 重庆新媒农信科技有限公司 | Method and device for processing of server service requests |
| WO2015096656A1 (en) * | 2013-12-26 | 2015-07-02 | 华为技术有限公司 | Thread creation method, service request processing method and related device |
| CN106851796A (en) * | 2016-12-14 | 2017-06-13 | 努比亚技术有限公司 | A kind of data card and its method for realizing Wi Fi focuses |
| CN108415759A (en) * | 2017-02-09 | 2018-08-17 | 阿里巴巴集团控股有限公司 | Processing method, device and the electronic equipment of message |
| CN107491350A (en) * | 2017-09-05 | 2017-12-19 | 武汉斗鱼网络科技有限公司 | Interface task call method and device |
| CN109582455A (en) * | 2018-12-03 | 2019-04-05 | 恒生电子股份有限公司 | Multithreading task processing method, device and storage medium |
| CN111225041A (en) * | 2019-12-26 | 2020-06-02 | 的卢技术有限公司 | Method and system for realizing delay message queue |
| CN111367629A (en) * | 2020-03-30 | 2020-07-03 | 绿盟科技集团股份有限公司 | Delayed task processing method and device |
| CN112148506A (en) * | 2020-09-25 | 2020-12-29 | 北京自如信息科技有限公司 | Message processing method, device, platform and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 胡欣杰: "《Oracle 9i数据库管理员指南 v9.0.1》", 30 April 2002, 北京：北京希望电子出版社 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106407190B (en) | Event record query method and device | |
| CN108111554B (en) | Control method and device for access queue | |
| CN110489447A (en) | Data query method, apparatus, computer equipment and storage medium | |
| CN103544153A (en) | Data updating method and system based on database | |
| US20070106669A1 (en) | Ensuring Timely Servicing of Desired Transactions in a Database Server | |
| CN110336859B (en) | Task scheduling system under multi-tenant environment | |
| CN110058940B (en) | Data processing method and device in multi-thread environment | |
| CN108292162A (en) | Software definition fifo buffer for multi-thread access | |
| CN110008041B (en) | Message processing method and device | |
| CN106844721A (en) | Date storage method, device, system, computer-readable recording medium and storage control | |
| CN109189578A (en) | Storage server distribution method, device, management server and storage system | |
| CN111311377A (en) | Order processing method, device and system | |
| CN108629653A (en) | A kind of low delay inventory reduces service system and method | |
| CN111367694B (en) | Event processing method, server and computer storage medium | |
| CN111563115B (en) | Statistical method and device for data distribution information in distributed database | |
| CN112801559A (en) | Service request processing method, device, equipment and storage medium | |
| CN111736975A (en) | Request control method and device, computer equipment and computer readable storage medium | |
| CN111679895A (en) | Execution method, device and equipment of distributed timing task and readable storage medium | |
| CN115858668A (en) | Distributed transaction processing method, device, electronic device and storage medium | |
| US11360702B2 (en) | Controller event queues | |
| US9697049B2 (en) | Job scheduling apparatus and method based on island execution time | |
| CN110543486B (en) | Data change method and device and server | |
| CN113360570A (en) | High-concurrency system inventory module implementation method | |
| CN112818166A (en) | Video information query method and device, electronic equipment and storage medium | |
| CN112202581A (en) | Group joining method and device and electronic equipment |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210514 |