CN111488373B - Method and system for processing request - Google Patents
Method and system for processing request Download PDFInfo
- Publication number
- CN111488373B CN111488373B CN202010212616.0A CN202010212616A CN111488373B CN 111488373 B CN111488373 B CN 111488373B CN 202010212616 A CN202010212616 A CN 202010212616A CN 111488373 B CN111488373 B CN 111488373B
- Authority
- CN
- China
- Prior art keywords
- business logic
- request
- processing
- server
- client
- 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.)
- Active
Links
- 238000012545 processing Methods 0.000 title claims abstract description 167
- 238000000034 method Methods 0.000 title claims abstract description 108
- 230000008569 process Effects 0.000 claims abstract description 37
- 230000004044 response Effects 0.000 claims abstract description 21
- 238000012544 monitoring process Methods 0.000 claims description 31
- 230000001360 synchronised effect Effects 0.000 claims description 20
- 230000002159 abnormal effect Effects 0.000 claims description 6
- 239000003550 marker Substances 0.000 claims description 6
- 230000006870 function Effects 0.000 description 21
- 230000001965 increasing effect Effects 0.000 description 5
- 230000008859 change Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 238000004091 panning Methods 0.000 description 2
- 238000012954 risk control Methods 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Finance (AREA)
- General Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Accounting & Taxation (AREA)
- Development Economics (AREA)
- Computing Systems (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- General Business, Economics & Management (AREA)
- Computational Linguistics (AREA)
- Computer And Data Communications (AREA)
Abstract
The application relates to a method performed at a server for processing a request from a client, the server comprising a plurality of business logic that are invoked in sequence for processing the request, the method comprising: receiving a request from the client; invoking the plurality of business logic in sequence to process the request; and in processing the request, if it is determined that one or more of the plurality of business logic is marked as asynchronous, performing asynchronous processing on the request, wherein performing asynchronous processing on the request comprises: returning an indication to the client that the request is to be asynchronously processed; and storing the processing result after the processing of the request is completed, so that the client can inquire or push the processing result to the client. The application also relates to a corresponding method performed at a client, and an associated system and computer readable storage medium. The application can improve the response speed of the request and reduce the occupation of server resources.
Description
Technical Field
The present specification relates to a method and system for processing requests from clients by a server.
Background
In existing systems, particularly distributed systems, a service request from a user's client is often completed through invocation of multiple service logics in one or more servers. For example, to process a transaction request, user authentication logic, payment logic, inventory processing logic, settlement logic, risk control logic, and the like may need to be invoked by the business framework. Business logic may need to be invoked in sequence many times. For example, in the above example, the user authentication logic may need to be invoked before the payment logic, the payment logic may need to be invoked before the settlement logic, and so on.
As more and more service logic is needed to complete the service request of the client, the call link is longer and longer. Some business logic may require long processing times, such as being relatively busy. For example, payment logic may encounter longer latencies in accessing databases associated with payments. Therefore, in the case where the call link is longer, the time taken for the call link and the response time become longer, resulting in a degradation of the client experience. Further, the server may allocate connection handles for the clients, and during the entire call link being processed, the allocation handles cannot be released, which may result in a large number of handles of the server being taken up and not being able to handle new requests. At the same time, this may also cause the link time occupied by the connection resources to become long, directly causing the system throughput to decrease.
Therefore, a solution for improving the response speed of the request and reducing the occupation of resources is needed.
Disclosure of Invention
In order to solve the above-mentioned problems and other problems, the present specification provides a technical solution that can be used to increase the response speed of a request.
The embodiments of the present specification achieve the above objects by the following technical means.
In one aspect, a method performed at a server for processing a request from a client is disclosed, the server comprising a plurality of business logic that are invoked in sequence for processing the request, the method comprising:
receiving a request from the client;
invoking the plurality of business logic in sequence to process the request; and
in processing the request, if it is determined that one or more of the plurality of business logic is marked as asynchronous, performing asynchronous processing on the request, wherein performing asynchronous processing on the request comprises:
returning an indication to the client that the request is to be asynchronously processed; and
and storing the processing result after the processing of the request is completed, so that the client can inquire or push the processing result to the client.
Preferably, performing asynchronous processing on the request includes further including: and returning a function for querying the processing result of the request to the client so that the client can query the processing result by using the function.
Preferably, the method further comprises assigning a connection handle to the client after receiving the request from the client, and performing asynchronous processing on the request further comprises releasing the connection handle after returning an indication to the client that the request is to be asynchronously processed.
Preferably, the method further comprises: the execution time of each business logic of the plurality of business logic is monitored.
Preferably, a business logic is marked as asynchronous if its execution time exceeds a threshold set for the business logic; and marking a business logic as synchronized if the execution time of the business logic does not exceed a threshold set for the business logic.
Preferably, if business logic is being executed in multiple threads, the execution time of the business logic in each thread is monitored.
Preferably, the business logic is marked as asynchronous if the execution time of the business logic in any one or more threads exceeds a threshold; and marking the business logic as synchronized if the execution time of the business logic in all threads does not exceed a threshold.
Preferably, monitoring the execution time of each of the plurality of business logic comprises:
determining the execution starting time of business logic;
determining the execution ending time of the business logic; and
the execution start time is subtracted from the execution end time of the business logic to obtain the execution time of the business logic.
Preferably, whether the business logic is synchronous or asynchronous is marked with an execution mode marker, and the execution mode marker of each business logic is thread safe.
Preferably, if the business logic is marked asynchronous and throws an exception when executed, the exception handling results are stored and a retry strategy is enabled.
Preferably, the retry strategy comprises:
if the business logic throws an exception when executing, determining retry execution time;
executing the retry at the determined retry execution time; and
if a normal processing result is obtained, the normal processing result is stored in place of the abnormal processing result.
Preferably, the querying or pushing of the processing results is performed over a secure connection.
Preferably, when the server receives a plurality of requests and the plurality of requests are asynchronously processed, a scheduling algorithm is employed to process the plurality of requests.
In another aspect, a method performed at a client is disclosed, the method comprising:
transmitting a request to a server to process a service, the server comprising a plurality of service logic to process the request;
receiving a response from the server, wherein the response includes a result of processing the request or an indication that the request is to be asynchronously processed; and
if the response is an indication that the request is to be asynchronously processed, the server is queried for processing results at a later time.
Preferably, querying the server for the processing results later includes querying the processing results periodically.
Preferably, querying the server for the processing results later includes querying the server for the processing results with a default query function.
Preferably, the method further comprises:
receiving a function from the server for querying the processing result of the request; and
the processing results are queried using the function.
Preferably, the method further comprises:
determining whether the queried processing result is an abnormal processing result; and
if the queried processing result is an exception processing result, the processing result is queried again later.
In yet another aspect, a computer-readable storage medium storing instructions that, when executed by a computer, cause the computer to perform the above-described method is disclosed.
In yet another aspect, a system is disclosed that includes means for performing the above method.
Compared with the prior art, the embodiment of the specification can have the following beneficial effects:
according to the embodiment of the specification, the busy business logic is marked as asynchronous and returned in advance when the response time is too long, so that the occupation of resources is saved, the system efficiency is improved, and the response speed to the request of the client is improved.
Embodiments of the present disclosure may further improve the efficiency and accuracy of processing requests by retrying when business logic performs exceptions in an asynchronous execution mode.
Of course, it is not necessary for any of the above technical solutions to be practiced simultaneously.
Drawings
The foregoing summary of the application, as well as the following detailed description of the application, will be better understood when read in conjunction with the accompanying drawings. It is to be noted that the drawings are merely examples of the claimed application. In the drawings, like reference numbers indicate identical or similar elements.
Fig. 1 shows a schematic diagram of a prior art process for responding to a request by a client.
Fig. 2 shows a schematic diagram of a process for responding to a request of a client according to an embodiment of the present description.
Fig. 3 shows a flow chart of a method performed at a server for processing a request from a client.
Fig. 4 shows a flow chart of a method performed at a server for processing a request from a client.
Detailed Description
The detailed features and advantages of the embodiments of the present disclosure are described in detail in the detailed description, which is sufficient to enable those skilled in the art to understand and practice the technical disclosure of the embodiments, and the related objects and advantages of the embodiments of the present disclosure are readily understood by those skilled in the art from the description, claims and drawings disclosed herein.
To increase the response speed to requests from clients, the present specification embodiments disclose methods, systems, computer-readable media, and apparatuses for increasing the response speed to requests from clients and increasing server efficiency.
Schematic of the prior art
Referring to fig. 1, there is shown a schematic diagram of a process 100 for responding to a request by a client according to the prior art.
As shown in fig. 1, a client 102 may transmit a request to a server 104. The request is typically a request to handle a service. The request may be, for example, a transaction request, or any other type of request. The client 102 may be any computing device including, but not limited to, a smart phone, a laptop computer, a desktop computer, a smart watch or smart bracelet, a media player, a gaming machine, a personal digital assistant, and the like. An application (not shown) for transmitting a request, such as a panning application, etc., may be installed on the client 102. The user may use an application on the client 102 to transmit requests to the server 104, receive responses from the server 104, view results of processing the requests, and so forth.
After the server 104 receives the request from the client 102, the request will be processed. The server 104 may be any type of server including, but not limited to, a mini-machine, mainframe, server cluster, cloud server, etc. The server 104 may also be any other type of computing device, such as a personal computer.
The server 104 may include a plurality of business logic. By business logic is meant a logic module for performing a particular business. For example, business logic may correspond to a function. Business logic may be invoked by a business framework (e.g., top-level framework) in server 104.
For example, to process a transaction request, user authentication logic, payment logic, inventory processing logic, settlement logic, risk control logic, and the like may need to be invoked by the business framework. Business logic may need to be invoked in sequence many times. For example, in the above example, the user authentication logic may need to be invoked before the payment logic, the payment logic may need to be invoked before the settlement logic, and so on. That is, to process the request, multiple business logic may be executed synchronously. For example, the plurality of business logic may be executed in the same thread. For example, in one embodiment, to respond to a request from a client 102, the business framework will first invoke business logic A106, after business logic A106 processes the invocation and returns an intermediate result, the business framework will invoke business logic B108 to continue processing the request with the intermediate result returned by business logic A. Similarly, after business logic B108 finishes processing the call and returns an intermediate result, the business framework will call business logic C110 to continue processing the request with the intermediate result returned by business logic B and obtain the final processing result to return to client 102.
It should be appreciated that although three business logic are shown in the figures, more or fewer business logic may be present.
As shown in fig. 1, in some cases business logic B108 may be executed for a longer period of time. For example, business logic B108 may need to access a database (e.g., the transaction module may access a database associated with the transaction) where access to the database may be slower. This may be due to, for example, poor connection quality to the database, downtime of the cloud database, bottlenecks in database I/O, etc.
In this case, in conventional schemes, the business framework typically still needs to call business logic B108 and wait for intermediate results returned by business logic B108, then continue to execute business logic C110, and return the final results to client 102 after business logic C110 obtains the final results. Since business logic B108 takes a long time to execute to return, client 102 takes a long time to get a response and present the final result to the user, which results in a poor user experience.
On the other hand, during this time, the connection handle assigned by the server 104 to the client 102 will be maintained throughout the process, thereby occupying the handle resources of the server 104. In the event that there are a large number of requests to the server 104, the handle resources of the server 104 may be exhausted. In this case, the server 104 may not be able to handle more requests. At the same time, this may also cause the link time occupied by the connection resources to become long, directly causing the system throughput to decrease.
In the conventional scheme, in order to solve the above-described problems, a typical method is to increase the number of servers. Increasing the number of servers is generally costly and requires a long time to purchase and configure. Furthermore, increasing the number of servers does not solve this problem, for example, in the case where there is a bottleneck not due to the servers themselves, but rather, for example, to the databases accessed by business logic B108.
To solve the above problems, the present application provides a method for marking one or more business logic as asynchronous when its execution mode is long and response is slow.
In particular, as shown in FIG. 2, a schematic diagram of a process 200 for responding to a request of a client is shown, according to an embodiment of the application.
As shown in fig. 2, similar to fig. 1, a client 102 may transmit a request to a server 104.
Server 104 may receive requests from clients 102 and process the requests. Likewise, server 104 may include a plurality of business logic for processing the request, such as business logic A106, business logic B108, and business logic C110 in FIG. 2. Preferably, the plurality of business logic may be invoked sequentially. For example, as shown in FIG. 2, the top-level framework may call business logic A104, and call business logic B108 after business logic A106 returns, and call business logic C110 after business logic B108 returns. For example, to process the request, multiple business logic may be executed synchronously. Preferably, the plurality of business logic (e.g., business logic A106, business logic B108, and business logic C110) may be executed in the same thread.
Server 104 may also include other business logic (not shown) for processing the request, which may not be invoked in sequence, and the embodiments described herein do not need to monitor or make changes to their behavior.
In an embodiment of the present description, the server 104 may include a monitoring module 202. The monitoring module 202 may be part of the top-level framework or a stand alone module. The monitoring module 202 may monitor the current state of each business logic in the server 104. For example, the monitoring module 202 may determine the execution time of each business logic. The execution time is determined, for example, in the following manner.
The monitoring module 202 may determine the execution start time of a business logic (e.g., business logic B108). For example, the monitoring module 202 may record the execution start time of the business logic. Alternatively, the monitoring module 202 may obtain the execution start time of the business logic from the log service of the server. Still alternatively, the monitoring module 202 may determine the execution start time based on a timestamp associated with the business logic.
The monitoring module 202 may determine an execution end time for the business logic. Typically, the execution end time is the time at which the business logic returns. Likewise, the monitoring module 202 may determine the execution end time in any manner, for example, the monitoring module 202 may record the execution end time itself, obtain the execution end time from a log service of a server, or determine the execution start time based on a timestamp associated with the business logic.
The monitoring module 202 may then subtract the execution start time from the execution end time of the business logic to obtain an execution time of the business logic.
In some examples, there may be situations where business logic is invoked in multiple threads. For example, for user authentication logic, it may be invoked in multiple threads executing to process transaction requests for multiple users, or for other reasons (e.g., to process balance inquiry requests, etc.).
In this case, the monitoring module 202 may monitor the execution time of the business logic in each thread. For example, the monitoring module 202 may determine the execution start time and execution end time of the business logic in each thread in any manner as described above. The monitoring module 202 may then subtract the execution start time from the execution end time of the business logic in a thread to obtain the execution time of the business logic in the thread.
In addition, the monitoring module 202 may also determine whether to mark the execution mode of the business logic as synchronous or asynchronous based on whether the execution time of the business logic exceeds a threshold. For example, a business logic is marked as asynchronous if its execution time exceeds a threshold set for the business logic. If the execution time of a business logic does not exceed the threshold set for the business logic, the business logic is marked as synchronized.
In the case where business logic is being invoked in multiple threads, it may be determined how to mark business logic as asynchronous or synchronous depending on the actual situation.
In a preferred embodiment, if the execution time of the business logic in all threads does not exceed a threshold, then the business logic is marked as synchronized; otherwise, if the execution time of the business logic in any one or more threads exceeds a threshold, the business logic is marked as asynchronous.
Other means may be employed. For example, it may be specified that business logic is marked as synchronized if its execution time in any one or more threads does not exceed a threshold; otherwise, if the execution time of the business logic in all threads exceeds a threshold, the business logic is marked as asynchronous.
For another example, it may be specified that if the number of threads whose execution time exceeds a threshold exceeds a thread number threshold or a thread proportion threshold, the business logic may be marked as asynchronous; otherwise the business logic may be marked as synchronized. For example, for a particular business logic (e.g., business logic B), assume that the business logic is being executed in 8 threads (e.g., the server is now processing 8 requests). At this time, the execution time of the 8 threads may be monitored and the execution time of each thread may be compared with a threshold value, and the number of threads whose execution time exceeds the threshold value may be counted. For example, a thread count threshold of 4 may be specified, where the business logic (e.g., business logic B) is marked as asynchronous when the number of threads whose execution time exceeds the threshold is greater than 4. For another example, a thread proportion threshold value may be specified as 50%, at which time the business logic (e.g., business logic B) may be marked as asynchronous when the proportion of the number of threads that have been executed for a time exceeding the threshold value to the total number of threads (e.g., 8) that the business logic is executing in is greater than 50%. Otherwise, the business logic may be marked as synchronized.
Preferably, a threshold value may be assigned to each business logic separately. For example, in the example of a server processing a transaction request, the threshold of user authentication logic (e.g., 1 second) may be less than the threshold of payment logic (e.g., 3 seconds). Such differences may reflect the execution complexity of the different business logic as well as other circumstances, such as whether access to a database is required, whether network delays are to be accounted for, etc.
Alternatively, each business logic may be assigned the same threshold, for example 1 second.
Preferably, the threshold of business logic may be specified by the developer of the business framework.
Preferably, the threshold of business logic may be set to a global variable so that each thread of the server may access the variable.
Preferably, the monitoring module 202 may continuously monitor the current state of the business logic and change the marking of the business logic based on whether the execution time of the business logic exceeds a threshold. For example, the monitoring module 202 may periodically (e.g., every 100 milliseconds, 500 milliseconds, 1 second, 3 seconds, etc.) determine the current state of each business logic and change the tags to the business logic as necessary.
The monitoring module 202 may employ an execution mode marker to mark whether each business logic is in a synchronous execution mode or an asynchronous execution mode, for example. For example, the monitoring module 202 may maintain a data table or other type of data record that includes an execution mode flag for each business logic. When the monitoring module 202 is to change the tag of the execution mode of the business logic, the monitoring module 202 may access the data table or data record to change the execution mode tag of the business logic.
Preferably, the execution mode indicator of each business logic is thread safe. For example, a thread or other thread in which business logic is executing would not be able to perform modifications to the monitoring module 202 other than the monitoring module 202 (and/or top-level framework). In this way, the correctness of the marking of the execution mode can be ensured.
Server 104 may determine that one or more of the plurality of business logic is marked as asynchronous in the process of sequentially invoking the plurality of business logic to process the request from client 102. If it is determined that all of the business logic of the server 104 is marked as synchronized, the server 104 may perform processing on the request in a conventional manner. For example, the server 104 may sequentially invoke the plurality of business logic to process the request, obtain the processing results, and return the processing results to the client 102. For specific procedures reference is made to the procedure described above with reference to fig. 1.
If it is determined that one or more business logic of server 104 (e.g., business logic B108) is marked as asynchronous, monitoring module 202 may perform asynchronous processing on the request. The asynchronous processing of the request is described in more detail as follows:
the server 104 may transmit an indication to the client 102 that the request is to be executed asynchronously. The indication may inform the client 102 that the request is to be executed asynchronously. The client 102 may be configured to receive and interpret the indication. For example, an application (e.g., a panning application, etc.) installed on the client 102 may be configured to receive the indication and understand that the indication indicates that the request is to be executed asynchronously.
For example, the indication may be a pre-agreed message. For example, server 104 may transmit a { type: "async" } message to client 102 to inform client 102 that server 104 is asynchronous with respect to the execution mode of the current request. By transmitting an indication to the client 102 that the request is to be executed asynchronously, the client 102 may receive a response from the server 104 faster, thereby enhancing the user experience.
In a preferred example, the client 102 may inform the user that the request is to be executed asynchronously. For example, the client 102 may display (e.g., via the application) a message to the user: "the server is processing your request, will later query the processing results automatically-! "or" the server is processing your request, please query the processing result later-! "
In another example, the client 102 may not inform the user that the request is to be executed asynchronously, but rather automatically query the processing results later and display the processing results to the user after the query is made.
Preferably, one or more business logic of server 104 (whether its execution mode is marked as synchronous or asynchronous) may be executed in the original manner until a processing result is obtained. For example, assuming that business logic A106 is marked as synchronous and business logic B108 and business logic C110 are marked as asynchronous, as shown in FIG. 2, server 104, upon receiving a request from client 102, may invoke business logic A106 to process, after business logic A106 processes the invocation and returns an intermediate result, the business framework will invoke business logic B108 to continue processing the request with the intermediate result returned by business logic A106; subsequently, after business logic B108 finishes processing the call and returns an intermediate result, the business framework will call business logic C110 to continue processing the request with the intermediate result returned by business logic B and obtain the final processing result.
In some examples, when marked asynchronous, the server may process the outstanding requests according to the scheduling rules. Taking the above transaction request as an example, assuming that the server includes user authentication logic, payment logic, and settlement logic for processing the transaction request, and the payment logic is marked as asynchronous and the user authentication logic and settlement logic are marked as synchronous, the transaction requests from the three clients X, Y and Z will be processed asynchronously, and an indication that the transaction requests will be processed asynchronously has been sent to both the three clients X, Y and Z. The server 104 may then process the three transaction requests according to the scheduling rules. For example, the server 104 may process the transaction requests sequentially in the order in which the transaction requests were received. For another example, the server 104 may process the transaction requests in order of priority from high to low in order of priority of the three transaction requests. Processing of the transaction request may also be scheduled according to other rules (e.g., according to transaction amount, according to standard, etc.).
At this point, the user will become less sensitive to the return time of the transaction request, since the client has been instructed to return and the user has been notified, making it possible to process the transaction request according to the scheduling rules.
After obtaining the processing results, the server 104 may save the processing results for querying or pushing to the client 102 by the client 102, as described in more detail below. For example, the processing results may be stored with the request identifier of the request for querying by the client 102.
The server 104 may store the processing results in the memory 204 of the server, or may store the processing results at other servers, such as the cloud.
Server 104 may also preferably transmit a function to client 102 that is used to query the results of the requested processing. For example, the server 104 may inform the client 102 of the functions and related parameters used to access the database of the processing results of the request. For example, the function may include an address of the processing result to be queried.
Alternatively, the client 102 is preconfigured with a query function, and queries the server 104 for the processing result using the default query function.
Preferably, the server 104 may also be configured to include a result return function for processing queries from the client 102 and providing processing results to the client 102. The result return function corresponds to a query function. For example, when the client 102 queries the processing results using the received query function or a default query function, the server 104 may return the processing results to the client 102 for employing the result return function. Alternatively, the server 104 does not include a specialized result return function, but rather the client 102 directly queries a data table or other data record that includes the processing results. The client 102 may query the processing results periodically or at other query policies. For example, the client 102 may be configured to query the processing results every 1 minute. The client 102 may query the processing results at other periods (e.g., every 2 minutes, every 10 minutes, every hour, etc.), depending on the particular application.
Preferably, to increase security, both the transmission of queries by the client 102 to the server 104 and the processing of results transmitted by the server 104 to the client 102 are performed using a secure connection. Preferably, one or both of the query and the processing results may be encrypted.
Alternatively, instead of the client 102 querying the server 104 for the processing results, the server 104 pushes the processing results to the client 102. Preferably, the pushing is performed over a secure connection. Preferably, the pushed processing results are encrypted.
Accordingly, after the client 102 has queried the processing results or pushed the processing results to the client 102, the server 104 may discard the corresponding processing results to save storage resources. Alternatively, the server 104 may hold the processing results for a longer period of time.
Preferably, upon returning an indication to the client that the request is to be asynchronously processed, the server 104 may release the connection handle associated with the client. By releasing the connection handle, the handle resources of the server 104 can be saved, so that the processing efficiency of the server 104 can be improved, and the throughput of the server 104 can be increased.
In the prior art, if the business logic of the server 104 throws an exception when processing a request, the client 102 would receive the exception and send the request again, causing the server 104 to retry in order to obtain the normal processing results. However, in embodiments of the present description, since the client 102 has been returned an indication that the transaction is to be asynchronously processed, the client 102 will not receive the exception and initiate a retry. Thus, in some preferred embodiments of the present description, a retry strategy is also included that performs a retry when an exception occurs to the processing of the business logic.
For example, suppose business logic B108 encounters an exception during execution. For example, business logic B108 may need to communicate with other systems (such as databases or other third party systems) over a network connection, and if the network connection is abnormal or the other systems are down, business logic B108 may throw the abnormality during execution. In this case, the server 104 may store the exception handling results. For example, server 104 may store exception handling results in a database.
In this case, the server 104 may enable a retry strategy. For example, server 104 may re-execute business logic (e.g., business logic B108) that thrown the exception at a later time. Preferably, server 104 may execute the business logic to throw exceptions after a predetermined time. For example, the server 104 may calculate (e.g., via the monitoring module 202) a retry execution time. For example, a specified length of time (e.g., 5 seconds) may be added to the current execution time as the retry execution time. For example, in 2018.12.13.12: 46:39 current execution throws out the exception, the retry execution time may be calculated as 2018.12.13: 46:44. service logic B108 may be re-executed at the retry execution time. This step may be repeated until a normal processing result is obtained, or a threshold number of executions is reached. The problems noted above may be solved by retry when executing an exception in an asynchronous execution mode.
In this case, the server 104 may store the exception processing result after obtaining the normal processing result. For example, server 104 may store normal processing results in a database in memory 204 in place of previously stored exception processing results.
Preferably, when querying the processing results, the client 102 will determine whether the queried processing results are exception processing results. If the queried processing result is an exception processing result, the client 102 may re-query the processing result at another time (e.g., periodically) until a normal processing result is queried or a threshold number of executions is reached.
Referring to fig. 3, a flow chart of a method 300 performed at a server for processing a request from a client is shown. The server includes a plurality of business logic that are invoked in sequence to process the request.
The method 300 may include: in step 302, a request from the client is received.
The method 300 may further include: at step 304, the plurality of business logic is invoked in sequence to process the request.
The method 300 may further include: at step 306, it is determined whether one or more of the plurality of business logic is marked as asynchronous. Wherein it is determined whether each business logic is marked asynchronous based on monitoring the execution time of the business logic. If the execution time of a business logic exceeds a threshold set for the business logic, the business logic is marked as asynchronous, and if the execution time of a business logic does not exceed the threshold set for the business logic, the business logic is marked as synchronous. If the business logic is being executed in multiple threads, the execution time of the business logic in each thread is monitored, wherein if the execution time of the business logic in any one or more threads exceeds a threshold, the business logic is marked as asynchronous, and if the execution time of the business logic in all threads does not exceed the threshold, the business logic is marked as synchronous. The execution mode of the business logic may be marked with an execution mode marker. Preferably, the execution mode indicator of each business logic is thread safe.
Wherein monitoring the execution time of each business logic of the plurality of business logic comprises: determining the execution starting time of business logic; determining the execution ending time of the business logic; and subtracting the execution start time from the execution end time of the business logic to obtain the execution time of the business logic.
The method 300 may further include: if one or more of the plurality of business logic is marked as asynchronous, then asynchronous processing is performed on the request at step 308. Otherwise, in step 310, the request is processed in a conventional manner, for example, the processing result is returned to the client after the processing of the request is waited for.
Wherein step 308 may comprise: at step 312, an indication is returned to the client that the request is to be asynchronously processed. Wherein upon returning an indication to the client that the request is to be asynchronously processed, a connection handle assigned for the client may be released.
In addition, step 308 may further include: at step 314, the processing results are saved for querying or pushing to the client when processing of the request is completed. Preferably, the querying or pushing of the processing results is performed over a secure connection.
Preferably, when the server receives a plurality of requests and the plurality of requests are asynchronously processed, a scheduling algorithm is employed to process the plurality of requests. For example, the plurality of requests may be processed according to their priority.
The method 300 may further include: preferably, the business logic is marked asynchronous and throws an exception when executed, stores the exception handling results, and enables a retry strategy. For example, the retry strategy may include: if the business logic throws an exception when executing, determining retry execution time; executing the retry at the determined retry execution time; if a normal processing result is obtained, the normal processing result is stored in place of the abnormal processing result.
For details of method 300, reference is made to the description above with respect to FIG. 2.
Method executed at a client
Referring to fig. 4, a flow chart of a method 400 performed at a client according to an embodiment of the present description is shown. The server includes a plurality of business logic.
The method 400 may include: at step 402, a request to process a service is transmitted to a server that includes a plurality of service logic for processing the request.
The method 400 may include: at step 404, a response is received from the server, wherein the response includes a result of processing the request or an indication that the request is to be asynchronously processed.
The method 400 may include: if the response is an indication that the request is to be asynchronously processed, the server is queried for processing results at a later time, step 406. For example, the processing results may be queried periodically. Preferably, a function for querying the processing result of the request may be received from the server, and the processing result may be queried using the function. Alternatively, a default query function may be employed to query the server for processing results.
Preferably, the method 400 may further comprise: it is determined whether the queried processing result is an exception processing result. If the queried processing result is an exception processing result, the processing result is queried again later.
Details of method 400 may also be referred to the description above with respect to fig. 2.
It should be noted that although only a single server is described herein, it should be understood that the single server may be a plurality or cluster of servers. Similarly, although memory and databases in the server are described herein, it should be understood that the memory may be, for example, cloud memory, distributed databases, and the like.
Furthermore, a computer-readable storage medium comprising computer-executable instructions stored thereon, which when executed by a processor, cause the processor to perform the methods of the embodiments described herein, is also disclosed.
Furthermore, a system is disclosed, comprising means for implementing the methods of the embodiments described herein.
It is to be understood that methods according to embodiments of the present description may be implemented in software, firmware, or a combination thereof.
It should be understood that the specific order or hierarchy of steps in the methods disclosed are illustrations of exemplary processes. Based on design preferences, it is understood that the specific order or hierarchy of steps in the methods may be rearranged. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented, unless specifically recited herein.
It should be understood that elements described herein in the singular or shown in the drawings are not intended to limit the number of elements to one. Furthermore, modules or elements described or illustrated herein as separate may be combined into a single module or element, and modules or elements described or illustrated herein as a single may be split into multiple modules or elements.
It is also to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting. The use of these terms and expressions is not meant to exclude any equivalents of the features shown and described (or portions thereof), and it is recognized that various modifications are possible and are intended to be included within the scope of the claims. Other modifications, variations, and alternatives are also possible. Accordingly, the claims should be looked to in order to cover all such equivalents.
Also, it should be noted that while the present application has been described with reference to the particular embodiments presently, it will be appreciated by those skilled in the art that the above embodiments are provided for illustration only and that various equivalent changes or substitutions may be made without departing from the spirit of the application, and therefore, the changes and modifications to the above embodiments shall fall within the scope of the claims of the present application as long as they are within the true spirit of the application.
Claims (20)
1. A method performed at a server for processing a request from a client, the server comprising a plurality of business logic that are invoked in sequence for processing the request, the method comprising:
receiving a request from the client;
invoking the plurality of business logic in sequence to process the request; and
in processing the request, if it is determined that one or more of the plurality of business logic is marked as asynchronous, performing asynchronous processing on the request, wherein performing asynchronous processing on the request comprises:
returning an indication to the client that the request is to be asynchronously processed; and
storing a processing result after the request is processed, so that the client can inquire or push the processing result to the client;
the method further comprises the steps of: monitoring the execution time of each business logic in the plurality of business logic, and marking the business logic as asynchronous if the execution time of one business logic exceeds a threshold value set for the business logic; or,
if the business logic is being executed in a plurality of threads, the execution time of the business logic in each thread is monitored, and if the execution time of the business logic in any one or more threads exceeds a threshold value, the business logic is marked as asynchronous, and each business logic corresponds to a specified threshold value respectively.
2. The method of claim 1, wherein performing asynchronous processing on the request comprises further comprising: and returning a function for querying the processing result of the request to the client so that the client can query the processing result by using the function.
3. The method of claim 1, wherein the method further comprises assigning a connection handle to the client after receiving the request from the client, and performing asynchronous processing on the request further comprises releasing the connection handle after returning an indication to the client that the request is to be asynchronously processed.
4. The method of claim 1, wherein the method further comprises:
if the execution time of a business logic does not exceed the threshold set for the business logic, the business logic is marked as synchronized.
5. The method of claim 1, wherein the method further comprises:
if the execution time of the business logic in all threads does not exceed the threshold, the business logic is marked as synchronized.
6. The method of claim 1, wherein monitoring execution time of each business logic of the plurality of business logic comprises:
determining the execution starting time of business logic;
determining the execution ending time of the business logic; and
the execution start time is subtracted from the execution end time of the business logic to obtain the execution time of the business logic.
7. The method of claim 1, wherein whether the business logic is synchronous or asynchronous is marked with an execution mode marker, and wherein the execution mode marker of each business logic is thread safe.
8. The method of claim 1, wherein if the business logic is marked asynchronous and throws an exception when executed, storing exception handling results and enabling a retry strategy.
9. The method of claim 8, wherein the retry strategy comprises:
if the business logic throws an exception when executing, determining retry execution time;
executing the retry at the determined retry execution time; and
if a normal processing result is obtained, the normal processing result is stored in place of the abnormal processing result.
10. The method of claim 1, wherein the querying or pushing of the processing results is performed over a secure connection.
11. The method of claim 1, wherein a scheduling algorithm is employed to process the plurality of requests when the server receives the plurality of requests and when the plurality of requests are asynchronously processed.
12. A method performed at a client, the method comprising:
transmitting a request to a server to process a service, the server comprising a plurality of service logic to process the request;
receiving a response from the server, wherein the response includes a result of processing the request or an indication that the request is to be asynchronously processed, the asynchronous processing characterizing that an execution time of a business logic of the server processing the request exceeds a threshold set for the business logic, or, in the case that the business logic is being invoked in multiple threads, the execution time of a business logic in any one or more threads exceeds a threshold, each business logic in the server corresponding to a specified threshold, respectively; and
if the response is an indication that the request is to be asynchronously processed, the server is queried for processing results at a later time.
13. The method of claim 12, wherein querying the server for the processing results at a later time comprises querying the processing results periodically.
14. The method of claim 12, wherein querying the server for the processing results at a later time comprises querying the server for the processing results with a default query function.
15. The method of claim 12, wherein the method further comprises:
receiving a function from the server for querying the processing result of the request; and
the processing results are queried using the function.
16. The method of claim 12, wherein the method further comprises:
determining whether the queried processing result is an abnormal processing result; and
if the queried processing result is an exception processing result, the processing result is queried again later.
17. A computer readable storage medium storing instructions which, when executed by a computer, cause the computer to perform the method of any one of claims 1-11.
18. A system comprising means for performing the method of any one of claims 1-11.
19. A computer readable storage medium storing instructions which, when executed by a computer, cause the computer to perform the method of any of claims 12-16.
20. A system comprising means for performing the method of any of claims 12-16.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010212616.0A CN111488373B (en) | 2020-03-24 | 2020-03-24 | Method and system for processing request |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010212616.0A CN111488373B (en) | 2020-03-24 | 2020-03-24 | Method and system for processing request |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111488373A CN111488373A (en) | 2020-08-04 |
| CN111488373B true CN111488373B (en) | 2023-09-22 |
Family
ID=71794580
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010212616.0A Active CN111488373B (en) | 2020-03-24 | 2020-03-24 | Method and system for processing request |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111488373B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113596002B (en) * | 2021-07-20 | 2022-11-18 | 中国联合网络通信集团有限公司 | Service providing method and device |
| CN114125479B (en) * | 2021-11-05 | 2023-12-19 | 游艺星际(北京)科技有限公司 | Information processing method, apparatus, electronic device and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105099989A (en) * | 2014-04-24 | 2015-11-25 | 阿里巴巴集团控股有限公司 | Service request processing and service processing result acquiring method, device and system |
| CN105635083A (en) * | 2014-11-14 | 2016-06-01 | 航天信息股份有限公司 | Service processing method and service processing system based on server and client architecture |
| CN107992504A (en) * | 2016-10-26 | 2018-05-04 | 中兴通讯股份有限公司 | A kind of document handling method and device |
| CN109753370A (en) * | 2018-12-28 | 2019-05-14 | 北京东方国信科技股份有限公司 | A kind of low time delay, the high remote procedure calling (PRC) method handled up |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9372722B2 (en) * | 2013-07-01 | 2016-06-21 | International Business Machines Corporation | Reliable asynchronous processing of a synchronous request |
-
2020
- 2020-03-24 CN CN202010212616.0A patent/CN111488373B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105099989A (en) * | 2014-04-24 | 2015-11-25 | 阿里巴巴集团控股有限公司 | Service request processing and service processing result acquiring method, device and system |
| CN105635083A (en) * | 2014-11-14 | 2016-06-01 | 航天信息股份有限公司 | Service processing method and service processing system based on server and client architecture |
| CN107992504A (en) * | 2016-10-26 | 2018-05-04 | 中兴通讯股份有限公司 | A kind of document handling method and device |
| CN109753370A (en) * | 2018-12-28 | 2019-05-14 | 北京东方国信科技股份有限公司 | A kind of low time delay, the high remote procedure calling (PRC) method handled up |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111488373A (en) | 2020-08-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10348809B2 (en) | Naming of distributed business transactions | |
| CN107798108B (en) | Asynchronous task query method and device | |
| CN105357038B (en) | Monitor the method and system of cluster virtual machine | |
| US20200159745A1 (en) | Conditional master election in distributed databases | |
| CN111913818B (en) | Method for determining dependency relationship between services and related device | |
| US9171019B1 (en) | Distributed lock service with external lock information database | |
| JP2019525334A (en) | Risk identification method, client device, and risk identification system | |
| CN111784318B (en) | Data processing method, device, electronic equipment and storage medium | |
| CN111488373B (en) | Method and system for processing request | |
| CN111813868B (en) | Data synchronization method and device | |
| CN110673959A (en) | System, method and apparatus for processing tasks | |
| CN105373563B (en) | Database switching method and device | |
| CN115617527A (en) | Management method, configuration method, management device and configuration device of thread pool | |
| US10223407B2 (en) | Asynchronous processing time metrics | |
| CN107332703B (en) | Method and device for checking multi-application logs | |
| CN113157426A (en) | Task scheduling method, system, equipment and storage medium | |
| US10728323B2 (en) | Method and apparatus for operating infrastructure layer in cloud computing architecture | |
| CN112860746B (en) | Cache reduction-based method, equipment and system | |
| CN115373886A (en) | Service group container shutdown method, device, computer equipment and storage medium | |
| CN115269111A (en) | Task processing method, system and device and readable medium | |
| US20090183172A1 (en) | Middleware Bridge System And Method | |
| US20120296951A1 (en) | System and method to execute steps of an application function asynchronously | |
| CN116233123A (en) | Information processing method and device, processor and electronic equipment | |
| CN114238411A (en) | Transaction data processing method and device, electronic equipment and storage medium | |
| CN111866093A (en) | Service data distribution method and device |
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 | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |