CN107645476B - Request processing method and device - Google Patents
Request processing method and device Download PDFInfo
- Publication number
- CN107645476B CN107645476B CN201610584728.2A CN201610584728A CN107645476B CN 107645476 B CN107645476 B CN 107645476B CN 201610584728 A CN201610584728 A CN 201610584728A CN 107645476 B CN107645476 B CN 107645476B
- Authority
- CN
- China
- Prior art keywords
- calling
- indication information
- retry
- call
- server
- 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
Images
Landscapes
- Telephonic Communication Services (AREA)
Abstract
The application discloses a request processing method and device. One embodiment of the method comprises: receiving a first call request sent by a client, wherein the first call request comprises: the operation identifier, the callback indication information and the retry indication information of the operation provided by the server side; sending a second calling request containing the operation identifier to the server, and receiving return information returned by the server, wherein the return information comprises: result indication information indicating success or failure of operation calling corresponding to the operation identifier; and according to the result indication information, determining to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information. On one hand, the method and the device configure the call operation according to the requirements of call back, retry and the like in the call operation process, so that the reliability of the call service is guaranteed. On the other hand, the number of the call requests is limited, the problem that the load of the server is increased sharply is avoided, and the processing efficiency of the call requests is improved.
Description
Technical Field
The present application relates to the field of computers, and in particular, to the field of network technologies, and in particular, to a request processing method and apparatus.
Background
During the running process of the internet application, the service of the third-party platform is often required to be called. At present, the commonly used calling method is as follows: and directly sending a calling request for the service to a server side providing the third-party service, and judging whether the calling request needs to be sent again according to a calling result.
However, when the service of the third party platform is called in the above manner, on the one hand, the calling process cannot be systematically managed, and the reliability of calling the service is reduced. On the other hand, when the number of call requests is of a large number of levels, the load on the server that processes the call requests increases rapidly, and the processing efficiency of the call requests decreases.
Disclosure of Invention
The application provides a request processing method and a request processing device, which are used for solving the technical problems existing in the background technology part.
In a first aspect, the present application provides a request processing method, including: receiving a first call request sent by a client, wherein the first call request comprises: the method comprises the steps of providing an operation identifier of an operation by a server, callback indicating information indicating whether to call back when the operation provided by a calling server is successful, and retry indicating information indicating whether to retry when the operation provided by the calling server is failed; sending a second calling request containing the operation identifier to the server, and receiving return information returned by the server, wherein the return information comprises: result indication information indicating success or failure of operation calling corresponding to the operation identifier; and according to the result indication information, determining to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information.
In a second aspect, the present application provides a request processing method, including: receiving a calling instruction corresponding to operation provided by a server; generating a call request, wherein the call request comprises: the operation identification of the operation, callback indicating information indicating whether to perform callback when the operation provided by the calling service end is successful, and retry indicating information indicating whether to perform retry when the operation provided by the calling service end is failed; and sending a calling request to the forwarding end so that the forwarding end sends the calling request containing the operation identifier to the server end to call the operation corresponding to the operation identifier and determines to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information according to the success or failure of the calling.
In a third aspect, the present application provides a request processing method, including: receiving a call request sent by a forwarding terminal, wherein the call request comprises: an operation identifier; generating result indication information indicating success or failure of operation calling corresponding to the operation identifier; and sending the result indication information to the forwarding end so that the forwarding end determines whether to execute the preset operation corresponding to the callback indication information for indicating whether to perform callback when the operation provided by the calling server is successful or whether to execute the preset operation corresponding to the retry indication information for indicating whether to perform retry when the operation provided by the calling server is failed according to the result indication information.
In a fourth aspect, the present application provides a request processing apparatus, comprising: the request receiving unit is configured to receive a first invocation request sent by a client, and the first invocation request includes: the method comprises the steps of providing an operation identifier of an operation by a server, callback indicating information indicating whether to call back when the operation provided by a calling server is successful, and retry indicating information indicating whether to retry when the operation provided by the calling server is failed; the request sending unit is configured to send a second call request containing the operation identifier to the server and receive return information returned by the server, where the return information includes: result indication information indicating success or failure of operation calling corresponding to the operation identifier; and the determining unit is configured to determine to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information according to the result indication information.
In a fifth aspect, the present application provides a request processing apparatus, comprising: the instruction receiving unit is configured to receive a call instruction corresponding to an operation provided by the server; a request generating unit configured to generate a call request, the call request including: the operation identification of the operation, callback indicating information indicating whether to perform callback when the operation provided by the calling service end is successful, and retry indicating information indicating whether to perform retry when the operation provided by the calling service end is failed; and the call request sending unit is configured to send a call request to the forwarding end, so that the forwarding end sends the call request containing the operation identifier to the server end to call the operation corresponding to the operation identifier, and determines to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information according to the call success or failure.
In a sixth aspect, the present application provides a request processing apparatus, comprising: a call request receiving unit configured to receive a call request sent by a forwarding end, where the call request includes: an operation identifier; the information generating unit is configured to generate result indicating information indicating success or failure of operation calling corresponding to the operation identifier; and the information sending unit is configured to send the result indication information to the forwarding end so that the forwarding end determines to execute a preset operation corresponding to callback indication information indicating whether to perform callback when the operation provided by the calling server is successful or to execute a preset operation corresponding to retry indication information indicating whether to perform retry when the operation provided by the calling server is failed according to the result indication information.
According to the request processing method and device provided by the application, a first call request sent by a client is received, and the first call request comprises: the operation identifier, the callback indication information and the retry indication information of the operation provided by the server side; sending a second calling request containing the operation identifier to the server, and receiving return information returned by the server, wherein the return information comprises: result indication information indicating success or failure of operation calling corresponding to the operation identifier; and according to the result indication information, determining to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information. On one hand, the method and the device configure the call operation according to the requirements of call back, retry and the like in the call operation process, so that the reliability of the call service is guaranteed. On the other hand, the number of the call requests is limited, the problem that the load of the server is increased sharply is avoided, and the processing efficiency of the call requests is improved.
Drawings
Other features, objects and advantages of the present application will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:
FIG. 1 illustrates an exemplary system architecture that may be applied to embodiments of the request processing method or apparatus of the present application;
FIG. 2 illustrates a flow diagram according to one embodiment of a request processing method of the present application;
FIG. 3 illustrates a flow diagram of another embodiment of a request processing method according to the present application;
FIG. 4 illustrates a flow diagram of yet another embodiment of a request processing method according to the present application;
FIG. 5 illustrates an exemplary architecture diagram suitable for use in the request processing method of the present application;
FIG. 6 illustrates an exemplary schematic diagram of a request processing method according to the present application;
FIG. 7 illustrates a schematic structural diagram of one embodiment of a request processing apparatus according to the present application;
FIG. 8 shows a schematic block diagram of another embodiment of a request processing device according to the present application;
FIG. 9 shows a schematic block diagram of yet another embodiment of a request processing device according to the present application;
FIG. 10 is a block diagram of a computer system suitable for use in implementing a request processing device according to an embodiment of the present application.
Detailed Description
The present application will be described in further detail with reference to the following drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant invention and not restrictive of the invention. It should be noted that, for convenience of description, only the portions related to the related invention are shown in the drawings.
It should be noted that the embodiments and features of the embodiments in the present application may be combined with each other without conflict. The present application will be described in detail below with reference to the embodiments with reference to the attached drawings.
Fig. 1 illustrates an exemplary system architecture 100 that may be applied to embodiments of the request processing method or apparatus of the present application.
As shown in fig. 1, the system architecture 100 may include a client 101, a forwarding end 102, and a server 103.
Network 104 is used to provide the medium of a transmission link between client 101 and forwarding end 102. The network 104 may include various wired, wireless transmission links. The network 105 is used to provide the medium of a transmission link between the forwarding end 102 and the service end 103. The network 105 may include wired transmission links, such as fiber optic cables.
The server 103 may provide a service, and the client 101 may invoke the service provided by the server 103. The forwarding terminal 102 may receive a call request for a service sent by the client terminal 101, and send the call request to the server terminal 103. The forwarding end 102 may receive a call result generated after the service is called and returned by the server end 103, and send the call result to the client 101.
In the present application, a terminal or a server deployed in the client 101 may invoke a service provided by the server 103. The server cluster deployed at the forwarding end 102 may receive a call request for a service sent by the client 101, and send the call request to the server 103. The services may be provided by a cluster of servers deployed at the server 103.
In the following embodiments of the present application, a service provided by a server may be referred to as a server-provided operation.
Referring to FIG. 2, a flow 200 of one embodiment of a request processing method according to the present application is shown. It should be noted that the request processing method provided in the embodiment of the present application may be executed by the forwarding end 102 in fig. 1, for example, may be executed by a server cluster deployed at the forwarding end 102, and accordingly, the request processing apparatus may be disposed at the forwarding end 102. The method comprises the following steps:
In this embodiment, when the client needs to invoke an operation provided by the server, a first invocation request sent by the client may be received. The first invocation request includes: the operation identification of the operation provided by the server side, callback indicating information indicating whether to call back when the operation provided by the calling server side is successful, and retry indicating information indicating whether to retry when the operation provided by the calling server side is failed.
In this embodiment, the first invocation request sent by the client may include an operation identifier of an operation provided by the server, where the operation identifier may be used to identify an operation of the server that the client needs to invoke.
In this embodiment, the first invocation request sent by the client further includes callback indication information indicating whether a callback is required when the operation provided by the client invocation server is successful. For example, when the client needs to call back the call result generated after the call when the operation provided by the call server is successful, the callback indication information may be indication information indicating that the client calls back the call result when the operation provided by the call server is successful.
In this embodiment, the first invocation request sent by the client further includes retry indication information indicating whether to perform a retry when the operation provided by the invocation server fails. For example, when the client needs to perform a retry when the operation provided by the calling server fails, that is, when the calling request is retransmitted, the retry indication information may be retry indication information indicating that the retry is performed when the operation provided by the calling server fails.
In this embodiment, after receiving the first invocation request sent by the client through step 201, a second invocation request containing the operation identifier may be generated. Then, a second call request may be sent to the server to call an operation corresponding to the operation identifier of the server. After the second operation request is sent to the server, return information returned by the server may be received.
In this embodiment, the return information returned by the server includes: and indicating result indication information indicating success or failure of the operation calling corresponding to the operation identifier.
And 203, determining to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information according to the result indication information.
In this embodiment, it may be determined whether to execute the preset operation corresponding to the callback indication information received in step 201 and determine whether to execute the preset operation corresponding to the retry indication information received in step 201 according to result indication information indicating success or failure of the call corresponding to the indication operation identifier returned by the server in step 202.
In some optional implementation manners of this embodiment, the result indication information indicates that the operation call corresponding to the operation identifier is successful; and according to the result indication information, determining whether to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information comprises: and executing the preset operation corresponding to the callback indication information.
In some optional implementations of this embodiment, the returning information further includes: calling a calling result generated after the operation corresponding to the operation identifier is called, and calling back when the calling back indication information indicates that the operation provided by the calling server is successful; and executing the preset operation corresponding to the callback indication information comprises the following steps: and sending the calling result to the client.
In this embodiment, when the result indication information received in step 202 indicates that the operation corresponding to the operation identifier of the calling server is successfully called, the preset operation corresponding to the callback indication information received in step 201 may be executed.
In this embodiment, when the operation corresponding to the operation identifier of the calling server is successfully called, the return information returned by the server received in step 202 further includes a calling result generated after the operation corresponding to the operation identifier of the calling server. The invocation result may be sent to the client.
In some optional implementation manners of this embodiment, after sending the invocation result to the client, the method further includes: judging whether the client successfully receives the calling result; and when the client does not successfully receive the calling result, the calling result is sent to the client until the client successfully receives the calling result or the sending times corresponding to the calling result are equal to the time threshold.
In this embodiment, after the call result is sent to the client, it may be determined whether the client successfully receives the call result. When the client does not successfully receive the call result, the call result may be sent to the client until the client successfully receives the call result or the number of times of sending corresponding to the call result is equal to the number threshold.
In some optional implementation manners of this embodiment, the result indication information indicates that the operation call corresponding to the operation identifier fails; and according to the result indication information, determining whether to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information comprises: and executing the preset operation corresponding to the retry indication information.
In this embodiment, when the result indication information returned by the server indicates that the operation call corresponding to the operation identifier of the calling server fails through step 202, the preset operation corresponding to the retry indication information received through step 201 may be executed.
In this embodiment, when the retry indication information received in step 201 indicates that a retry is performed when the operation provided by the calling server is failed, a second call request may be sent to the server to call the operation corresponding to the operation identifier on the server until receiving result indication information indicating that the operation call corresponding to the operation identifier returned by the server is successful or the number of times of sending corresponding to the second call request is equal to the threshold number.
In some optional implementations of this embodiment, the method further includes: counting the number of the received first call requests in a preset time period; and when the number is larger than the first number threshold, executing preset current limiting operation to control the number of the second calling requests sent to the server.
In some optional implementations of this embodiment, the method further includes: counting the number of first calling requests received by a server cluster within a preset time period; and when the number is larger than a second number threshold, executing preset server cluster current limiting operation to control the number of second call requests sent by the server cluster to the server.
In the present application, the number of call requests received within a preset time period may be limited. For example, the number of call requests received by a single server may be limited, while the number of call requests received by the entire server cluster on the server side may be limited.
And when the number of the first calling requests received by a single server in a preset time period is smaller than the set JVM single counter number and the total number of the first calling requests received by the server cluster in the preset time period is smaller than the Redis-based server cluster counter number, sending a second calling request to the server side to request the target service. When the total number of the received first call requests in the preset time period reaches the number threshold and the first call requests are received again, the requests fail, and the timing task scanning can be waited to trigger the requests again.
Referring to FIG. 3, a flow 300 of another embodiment of a request processing method according to the present application is shown. It should be noted that the request processing method provided by the embodiment of the present application may be executed by the client 101 in fig. 1, for example, executed by a terminal or a server deployed in the client 101, and accordingly, the request processing apparatus may be disposed in the client 101. The method comprises the following steps:
In this embodiment, before receiving a call instruction corresponding to an operation provided by a server, a call instruction corresponding to an operation provided by a server may be generated first. For example, in the process of using the internet application, a user may click a button corresponding to an operation provided by a server in an interface of the application to generate a call instruction corresponding to the operation provided by the server. At this time, the input call instruction corresponding to the operation provided by the server may be received.
In this embodiment, after receiving a call instruction corresponding to an operation provided by a server through step 301, a call request may be generated. The call request includes: the operation identification of the operation provided by the calling server side is needed to be called, the callback indicating information which indicates whether to call back when the operation provided by the calling server side is successful, and the retry indicating information which indicates whether to retry when the operation provided by the calling server side is failed.
In this embodiment, the configuration may be performed according to the requirements of callback, retry and the like in the process of calling operation. For example, when the client needs to call back the call result generated after the call when the operation provided by the call server is successful, the callback indication information may be indication information indicating that the client calls back the call result when the operation provided by the call server is successful. For another example, when the client needs to retry the operation provided by the calling server when the operation fails, that is, when the calling request is retransmitted, the retry indication information may be retry indication information indicating that the retry is performed when the operation provided by the calling server fails.
In this embodiment, after the invocation request is generated through step 302, the forwarding end may send the invocation request. Therefore, the forwarding end can send the call request to the server end to call the operation corresponding to the operation identifier, and can determine to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information according to the call success or failure.
Referring to FIG. 4, a flow 400 of yet another embodiment of a request processing method according to the present application is shown. It should be noted that the request processing method provided in the embodiment of the present application may be executed by the server 103 in fig. 1, for example, executed by a server cluster deployed in the server 103, and accordingly, the request processing apparatus may be disposed in the server 103. The method comprises the following steps:
In this embodiment, the invocation request includes: and (5) operation identification.
In this embodiment, after receiving the invocation request sent by the forwarding end in step 401, the operation corresponding to the operation identifier in the invocation request may be invoked. Then, according to the call success or failure, result indication information indicating that the operation call corresponding to the operation identifier is successful or failed may be generated.
And step 403, sending the result indication information to the forwarding end.
In this embodiment, the result indication information indicating that the operation call corresponding to the operation identifier is successful or failed is generated in step 402, and the result indication information may be sent to the forwarding end. Therefore, the forwarding end can determine, according to the result indication information, whether to execute the preset operation corresponding to the callback indication information indicating whether to perform callback when the operation provided by the calling server is successful or whether to execute the preset operation corresponding to the retry indication information indicating whether to perform retry when the operation provided by the calling server is failed.
Referring to fig. 5, an exemplary architecture diagram is shown for a request processing method applicable to the present application.
In fig. 5, a client 501, a forwarding end 502, and a server 503 are shown. The client can run a calling process for calling the target service, the forwarding end can run an asynchronous forwarding service, and the server can provide the target service. The client can call the asynchronous forwarding service, then the asynchronous forwarding service asynchronously calls the target service, and after the calling is successful, the asynchronous forwarding service asynchronously returns a calling result to the client.
In the present application, when the invocation of the target service fails, a task in a specific state may be scanned by a timing task created in advance. For example, a task failing to invoke the target service may be scanned by the timing task and then retried, thereby securing reliability of invoking the target service.
In the application, in the process of calling the target service by the asynchronous forwarding service, the number of calls received in a preset time period can be limited. For example, the number of call requests received by a single server of a server cluster deployed on a server is limited, and meanwhile, the number of call requests received by a whole server cluster deployed on the server is limited.
Referring to FIG. 6, an exemplary schematic diagram of a request processing method according to the present application is shown.
In the present application, a task may be established for a call request, and a task at a specific stage may be scanned by a timing task. In the present application, a task may be in the following stages:
an initialization stage: when the calling party calls the asynchronous forwarding intermediate service, the calling request is sent to the asynchronous forwarding intermediate service, the asynchronous forwarding intermediate service can insert a task record in an initial state into a database, and can perform processing in an execution stage according to configuration information or enter the execution stage after waiting for a task in a timing task scanning initialization state.
An execution stage: and asynchronously calling the target service according to the calling request, and if the calling is successful, setting the state of the task to be successfully executed. Then, according to the configuration information, the callback phase is entered or the current flow is ended, and the state of the task is set as the execution end. If the call fails, retry can be carried out according to the configuration information, namely, the call request is sent again, and when the call is not successfully called after a certain retry number is reached, the state of the task can be set as the execution failure, and the current flow is ended.
A callback phase: and entering a callback phase when the target service called by the asynchronous forwarding intermediate service is successful and needs to be called. The asynchronous forwarding intermediate service can send the calling result to the client according to the set callback address. If the sending is successful, the task state can be set as callback success, and the current flow is ended. If the transmission fails, a retry may be performed based on the configuration information. When the sending is still unsuccessful after reaching a certain retry number, the state of the task can be set as a callback failure state, and the current flow is ended.
In the application, a timing task can be created in advance, and the timing task can scan out a task in an initialization state and execute a success state at fixed time and call back a failed task.
In the present application, a retry mechanism is provided that is directed to meeting different requirements. In the retry mechanism, whether or not a retry is required, the number of retries, and the retry interval can be configured. Because some interactions between the client and the server do not need to guarantee reliability, and only the target service is requested to have a limited flow function, in the application, whether retry is needed can be configured. The retry times after call failure can be configured according to the service requirements, and when the retry times are greater than the retry times, the retry can not be performed any more. The interval of retries can be configured according to traffic demands.
Referring to fig. 7, a schematic structural diagram of an embodiment of a request processing device according to the present application is shown. This device embodiment corresponds to the method embodiment shown in fig. 2.
As shown in fig. 7, the request processing apparatus 700 of the present embodiment includes: request receiving section 701, request transmitting section 702, and determining section 703. The request receiving unit 701 is configured to receive a first invocation request sent by a client, where the first invocation request includes: the method comprises the steps of providing an operation identifier of an operation by a server, callback indicating information indicating whether to call back when the operation provided by a calling server is successful, and retry indicating information indicating whether to retry when the operation provided by the calling server is failed; the request sending unit 702 is configured to send a second invocation request containing the operation identifier to the server, and receive return information returned by the server, where the return information includes: result indication information indicating success or failure of operation calling corresponding to the operation identifier; the determining unit 703 is configured to determine, according to the result indicating information, to execute a preset operation corresponding to the callback indicating information or execute a preset operation corresponding to the retry indicating information.
In some optional implementations of this embodiment, the determining unit 703 includes: a first execution subunit (not shown), configured to, when the result indication information indicates that the operation corresponding to the operation identifier is successfully invoked and the callback indication information indicates that the operation provided by the calling server is successful, send, to the client, a calling result generated after the operation corresponding to the calling operation identifier in the return information; and a second execution subunit (not shown), configured to, when the result indication information indicates that the operation call corresponding to the operation identifier fails and the retry indication information indicates that a retry is performed when the operation provided by the calling server fails, send the second call request to the server until receiving the result indication information indicating that the operation call corresponding to the operation identifier succeeds or the number of times of sending corresponding to the second call request returned by the server is equal to the number threshold.
In some optional implementations of this embodiment, the apparatus 700 further includes: a determining unit (not shown) configured to determine whether the client successfully receives the calling result after sending the calling result to the client; and a retry unit (not shown) configured to, when the client does not successfully receive the call result, send the call result to the client until the client successfully receives the call result or a number of times of sending corresponding to the call result is equal to the number threshold.
In some optional implementations of this embodiment, the apparatus 700 further includes: a first statistical unit (not shown) configured to count the number of first call requests received within a preset time period; a current limiting unit (not shown) configured to perform a preset current limiting operation to control the number of the second call requests sent to the server when the number is greater than a first number threshold; a second counting unit (not shown) configured to count the number of the first call requests received by the server cluster within a preset time period; and the cluster current limiting unit (not shown) is configured to execute a preset server cluster current limiting operation to control the number of the second call requests sent by the server cluster to the server when the number is greater than the second number threshold.
Referring to fig. 8, a schematic structural diagram of another embodiment of a request processing device according to the present application is shown. This device embodiment corresponds to the method embodiment shown in fig. 3.
As shown in fig. 8, the request processing apparatus 800 of the present embodiment includes: an instruction receiving unit 801, a request generating unit 802, and a call request transmitting unit 803. The instruction receiving unit 801 is configured to receive a call instruction corresponding to an operation provided by a server; the request generating unit 802 is configured to generate a call request, where the call request includes: the operation identification of the operation, callback indicating information indicating whether to perform callback when the operation provided by the calling service end is successful, and retry indicating information indicating whether to perform retry when the operation provided by the calling service end is failed; the call request sending unit 803 is configured to send a call request to the forwarding end, so that the forwarding end sends the call request including the operation identifier to the server end to call the operation corresponding to the operation identifier, and determines to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information according to success or failure of the call.
Referring to fig. 9, a schematic structural diagram of yet another embodiment of a request processing device according to the present application is shown. This device embodiment corresponds to the method embodiment shown in fig. 4.
As shown in fig. 9, the request processing apparatus 900 of the present embodiment includes: a call request receiving unit 901, an information generating unit 902, and an information transmitting unit 903. The invocation request receiving unit 901 is configured to receive an invocation request sent by a forwarding end, where the invocation request includes: an operation identifier; the information generating unit 902 is configured to generate result indication information indicating success or failure of the operation call corresponding to the operation identifier; the information sending unit 903 is configured to send the result indication information to the forwarding end, so that the forwarding end determines, according to the result indication information, whether to execute a preset operation corresponding to callback indication information indicating whether to perform callback when the operation provided by the calling server is successful or whether to execute a preset operation corresponding to retry indication information indicating whether to perform retry when the operation provided by the calling server is failed.
FIG. 10 illustrates a block diagram of a computer system suitable for use in implementing a request processing device of an embodiment of the present application.
As shown in fig. 10, the computer system 1000 includes a Central Processing Unit (CPU)1001 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)1002 or a program loaded from a storage section 1008 into a Random Access Memory (RAM) 1003. In the RAM1003, various programs and data necessary for the operation of the system 1000 are also stored. The CPU1101, ROM 1002, and RAM1003 are connected to each other by a bus 1004. An input/output (I/O) interface 1005 is also connected to bus 1104.
The following components are connected to the I/O interface 1005: an input section 1006 including a keyboard, a mouse, and the like; an output section 1007 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 1008 including a hard disk and the like; and a communication section 1009 including a network interface card such as a LAN card, a modem, or the like. The communication section 1009 performs communication processing via a network such as the internet. The driver 1010 is also connected to the I/O interface 1005 as necessary. A removable medium 1011 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 1010 as necessary, so that a computer program read out therefrom is mounted into the storage section 1008 as necessary.
In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program tangibly embodied on a machine-readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication part 1009 and/or installed from the removable medium 1011.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
As another aspect, the present application also provides a non-volatile computer storage medium, which may be the non-volatile computer storage medium included in the apparatus in the above-described embodiments; or it may be a non-volatile computer storage medium that exists separately and is not incorporated into the terminal. The non-transitory computer storage medium stores one or more programs that, when executed by a device, cause the device to: receiving a first call request sent by a client, wherein the first call request comprises: the method comprises the steps of providing an operation identifier of an operation by a server, callback indicating information indicating whether to call back when the operation provided by a calling server is successful, and retry indicating information indicating whether to retry when the operation provided by the calling server is failed; sending a second calling request containing the operation identifier to the server, and receiving return information returned by the server, wherein the return information comprises: result indication information indicating success or failure of operation calling corresponding to the operation identifier; and according to the result indication information, determining to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information.
The above description is only a preferred embodiment of the application and is illustrative of the principles of the technology employed. It will be appreciated by a person skilled in the art that the scope of the invention as referred to in the present application is not limited to the embodiments with a specific combination of the above-mentioned features, but also covers other embodiments with any combination of the above-mentioned features or their equivalents without departing from the inventive concept. For example, the above features may be replaced with (but not limited to) features having similar functions disclosed in the present application.
Claims (16)
1. A method for processing a request, the method comprising:
receiving a first call request sent by a client, wherein the first call request comprises: the method comprises the steps that operation identification of operation provided by a server side, callback indicating information for indicating whether callback is carried out when the operation provided by a calling server side is successful, and retry indicating information for indicating whether retry is carried out when the operation provided by the calling server side is failed, wherein the callback indicating information and the retry indicating information are obtained according to requirements of callback and retry in the calling operation process;
sending a second calling request containing the operation identifier to the server, and receiving return information returned by the server, wherein the return information comprises: result indication information indicating success or failure of operation calling corresponding to the operation identifier;
and according to the result indication information, determining to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information.
2. The method according to claim 1, wherein the result indication information indicates that the operation call corresponding to the operation identifier is successful; and
according to the result indication information, determining to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information includes:
and executing the preset operation corresponding to the callback indication information.
3. The method of claim 2, wherein the returning information further comprises: calling a calling result generated after the operation corresponding to the operation identifier is called, wherein the callback indication information indicates that the operation provided by the calling server is successfully called; and
executing the preset operation corresponding to the callback indication information comprises the following steps:
and sending the calling result to the client.
4. The method of claim 3, wherein after sending the invocation result to the client, the method further comprises:
judging whether the client successfully receives the calling result;
and when the client does not successfully receive the calling result, the calling result is sent to the client until the client successfully receives the calling result or the sending times corresponding to the calling result are equal to a time threshold.
5. The method according to claim 1, wherein the result indication information indicates that the operation call corresponding to the operation identifier fails; and
according to the result indication information, determining to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information includes:
and executing the preset operation corresponding to the retry indication information.
6. The method of claim 5, wherein the retry indication information indicates that the retry is performed when the operation provided by the calling server fails; and
executing the preset operation corresponding to the retry indication information comprises:
and sending the second calling request to the server until receiving result indication information which indicates that the operation calling corresponding to the operation identifier is successful and returned by the server or the sending times corresponding to the second calling request are equal to a time threshold.
7. The method according to one of claims 1 to 6, characterized in that the method further comprises:
counting the number of the received first call requests in a preset time period;
and when the number is larger than a first number threshold value, executing preset current limiting operation to control the number of second calling requests sent to the server.
8. The method of claim 7, further comprising:
counting the number of first calling requests received by a server cluster within a preset time period;
and when the number is larger than a second number threshold, executing preset server cluster current limiting operation to control the number of second call requests sent by the server cluster to the server.
9. A method for processing a request, the method comprising:
receiving a calling instruction corresponding to operation provided by a server;
generating a call request, wherein the call request comprises: the operation identifier of the operation, callback indicating information indicating whether to call back when the operation provided by the calling service end is successful, and retry indicating information indicating whether to retry when the operation provided by the calling service end is failed, wherein the callback indicating information and the retry indicating information are obtained according to the requirements of call back and retry in the calling operation process;
and sending the calling request to a forwarding end so that the forwarding end sends the calling request containing the operation identifier to a server end to call the operation corresponding to the operation identifier and determines to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information according to the success or failure of the calling.
10. A method for processing a request, the method comprising:
receiving a call request sent by a forwarding terminal, wherein the call request comprises: an operation identifier;
generating result indication information indicating success or failure of operation calling corresponding to the operation identifier;
and sending the result indication information to a forwarding end so that the forwarding end determines whether to execute a preset operation corresponding to callback indication information indicating whether to call back when the operation provided by the calling service end is successful or whether to execute a preset operation corresponding to retry indication information indicating whether to retry when the operation provided by the calling service end is failed according to the result indication information, wherein the callback indication information and the retry indication information are obtained according to requirements of callback and retry in the calling operation process.
11. A request processing apparatus, characterized in that the apparatus comprises:
a request receiving unit, configured to receive a first invocation request sent by a client, where the first invocation request includes: the method comprises the steps that operation identification of operation provided by a server side, callback indicating information for indicating whether callback is carried out when the operation provided by a calling server side is successful, and retry indicating information for indicating whether retry is carried out when the operation provided by the calling server side is failed, wherein the callback indicating information and the retry indicating information are obtained according to requirements of callback and retry in the calling operation process;
a request sending unit, configured to send a second call request including the operation identifier to the server, and receive return information returned by the server, where the return information includes: result indication information indicating success or failure of operation calling corresponding to the operation identifier;
and the determining unit is configured to determine to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information according to the result indication information.
12. The apparatus of claim 11, wherein the determining unit comprises:
the first execution subunit is configured to send, to the client, a call result generated after an operation corresponding to the call operation identifier in the return information, when the result indication information indicates that the operation corresponding to the operation identifier is successfully called and the callback indication information indicates that the operation provided by the call server is successfully called;
and the second execution subunit is configured to send the second call request to the server until receiving result indication information indicating that the operation call corresponding to the operation identifier returned by the server is successful or the number of times of sending corresponding to the second call request is equal to a threshold number when the result indication information indicates that the operation call corresponding to the operation identifier fails and the retry indication information indicates that the operation provided by the calling server is retried when the operation provided by the calling server is failed.
13. The apparatus of claim 12, further comprising:
the judging unit is configured to judge whether the calling result is successfully received by the client after the calling result is sent to the client;
and the retry unit is configured to send the calling result to the client when the client does not successfully receive the calling result until the client successfully receives the calling result or the sending times corresponding to the calling result are equal to a time threshold.
14. The apparatus of claim 13, further comprising:
the first statistical unit is configured to count the number of the first call requests received in a preset time period;
the current limiting unit is configured to execute preset current limiting operation to control the number of second calling requests sent to the server when the number is greater than a first number threshold;
the second counting unit is configured for counting the number of the first calling requests received by the server cluster within a preset time period;
and the cluster current limiting unit is configured to execute preset server cluster current limiting operation to control the number of the second call requests sent to the server when the number is greater than a second number threshold.
15. A request processing apparatus, characterized in that the apparatus comprises:
the instruction receiving unit is configured to receive a call instruction corresponding to an operation provided by the server;
a request generating unit configured to generate a call request, the call request including: the operation identifier of the operation, callback indicating information indicating whether to call back when the operation provided by the calling service end is successful, and retry indicating information indicating whether to retry when the operation provided by the calling service end is failed, wherein the callback indicating information and the retry indicating information are obtained according to the requirements of call back and retry in the calling operation process;
and the call request sending unit is configured to send the call request to the forwarding end so that the forwarding end sends the call request containing the operation identifier to the server end to call the operation corresponding to the operation identifier and determine to execute the preset operation corresponding to the callback indication information or execute the preset operation corresponding to the retry indication information according to the call success or failure.
16. A request processing apparatus, characterized in that the apparatus comprises:
a call request receiving unit configured to receive a call request sent by a forwarding end, where the call request includes: an operation identifier;
the information generating unit is configured to generate result indicating information indicating success or failure of operation calling corresponding to the operation identifier;
and the information sending unit is configured to send the result indication information to the forwarding end so that the forwarding end determines whether to execute a preset operation corresponding to callback indication information indicating whether to perform callback when the operation provided by the calling service end is successful or whether to execute a preset operation corresponding to retry indication information indicating whether to perform retry when the operation provided by the calling service end is failed according to the result indication information, wherein the callback indication information and the retry indication information are obtained according to requirements of callback and retry in the calling operation process.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610584728.2A CN107645476B (en) | 2016-07-22 | 2016-07-22 | Request processing method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610584728.2A CN107645476B (en) | 2016-07-22 | 2016-07-22 | Request processing method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107645476A CN107645476A (en) | 2018-01-30 |
| CN107645476B true CN107645476B (en) | 2021-06-11 |
Family
ID=61109389
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610584728.2A Active CN107645476B (en) | 2016-07-22 | 2016-07-22 | Request processing method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107645476B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110162409B (en) * | 2018-02-11 | 2024-06-18 | 北京京东尚科信息技术有限公司 | Control method and device |
| CN110471739B (en) * | 2019-07-22 | 2023-07-11 | 创新先进技术有限公司 | Instruction retry method and device |
| CN114911633B (en) * | 2021-02-07 | 2024-07-12 | 北京字节跳动网络技术有限公司 | Remote procedure call retry method, device and equipment |
| CN112965823B (en) * | 2021-03-24 | 2023-12-26 | 百度在线网络技术（北京）有限公司 | Control method and device for call request, electronic equipment and storage medium |
| CN114095576B (en) * | 2021-11-22 | 2024-03-08 | 北京爱奇艺科技有限公司 | Call request sending method and device |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1483162A (en) * | 2000-07-27 | 2004-03-17 | BEAϵͳ��˾ | System and method for request assembling and load sharing |
| CN101697139A (en) * | 2009-11-06 | 2010-04-21 | 金蝶软件（中国）有限公司 | Method, device and registry for remote procedure call |
| CN103731312A (en) * | 2014-01-26 | 2014-04-16 | 飞狐信息技术（天津）有限公司 | Method and apparatus for performing failure checking on service of remote method invocation |
| CN105099989A (en) * | 2014-04-24 | 2015-11-25 | 阿里巴巴集团控股有限公司 | Service request processing and service processing result acquiring method, device and system |
| CN105553993A (en) * | 2015-12-18 | 2016-05-04 | 广州华多网络科技有限公司 | Remote service dispatching method and device and server |
-
2016
- 2016-07-22 CN CN201610584728.2A patent/CN107645476B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1483162A (en) * | 2000-07-27 | 2004-03-17 | BEAϵͳ��˾ | System and method for request assembling and load sharing |
| CN101697139A (en) * | 2009-11-06 | 2010-04-21 | 金蝶软件（中国）有限公司 | Method, device and registry for remote procedure call |
| CN103731312A (en) * | 2014-01-26 | 2014-04-16 | 飞狐信息技术（天津）有限公司 | Method and apparatus for performing failure checking on service of remote method invocation |
| CN105099989A (en) * | 2014-04-24 | 2015-11-25 | 阿里巴巴集团控股有限公司 | Service request processing and service processing result acquiring method, device and system |
| CN105553993A (en) * | 2015-12-18 | 2016-05-04 | 广州华多网络科技有限公司 | Remote service dispatching method and device and server |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107645476A (en) | 2018-01-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107645476B (en) | Request processing method and device | |
| CN111277639B (en) | Method and device for maintaining data consistency | |
| CN109873863B (en) | Asynchronous calling method and device of service | |
| KR102407334B1 (en) | Gateway apparatus and operating method thereof | |
| CN110609755A (en) | Message processing method, device, equipment and medium for cross-block chain node | |
| CN109034603B (en) | Business process execution method, device and computer readable storage medium | |
| CN110727523B (en) | Service request processing method, service request processing device and readable storage medium | |
| CN114827280A (en) | Request processing method, device, equipment and medium | |
| CN110750365A (en) | Remote procedure calling method, system, terminal and storage medium | |
| CN109218338B (en) | Information processing system, method and device | |
| CN110740163A (en) | Idempotent control method, idempotent control device, electronic equipment and readable storage medium | |
| CN112732547B (en) | Service testing method and device, storage medium and electronic equipment | |
| CN112818336A (en) | Data access method, data access device and computer readable storage medium | |
| CN113010330A (en) | Method and terminal for retrying micro-service request | |
| CN106961529B (en) | Work order processing method and communication service equipment | |
| CN115934378A (en) | Service data processing method and device, electronic equipment and storage medium | |
| US20180373512A1 (en) | Method and device for simulating synchronous blocking in asynchronous environment, storage medium, server and terminal | |
| CN112395194B (en) | Method and device for accessing test platform | |
| US20220276901A1 (en) | Batch processing management | |
| CN113342595A (en) | Gray scale verification method, device, equipment and storage medium | |
| CN111552907A (en) | Message processing method, device, equipment and storage medium | |
| CN107800577B (en) | Device configuration method and device for mobile terminal | |
| CN111125676B (en) | Joint authorization method and device | |
| CN112272211A (en) | Service request processing method, device and system | |
| CN112150126A (en) | Information processing method, information processing apparatus, electronic device, and medium |
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 | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20191122 Address after: 201210 room j1328, floor 3, building 8, No. 55, Huiyuan Road, Jiading District, Shanghai Applicant after: SHANGHAI YOUYANG NEW MEDIA INFORMATION TECHNOLOGY Co.,Ltd. Address before: 100085 Beijing, Haidian District, No. ten on the ground floor, No. 10 Baidu building, layer three Applicant before: BEIJING BAIDU NETCOM SCIENCE AND TECHNOLOGY Co.,Ltd. |
|
| TA01 | Transfer of patent application right | ||
| EE01 | Entry into force of recordation of patent licensing contract |
Application publication date: 20180130 Assignee: BEIJING BAIDU NETCOM SCIENCE AND TECHNOLOGY Co.,Ltd. Assignor: SHANGHAI YOUYANG NEW MEDIA INFORMATION TECHNOLOGY Co.,Ltd. Contract record no.: X2020990000202 Denomination of invention: Method and apparatus for processing request of wireless links establishing or increasing License type: Exclusive License Record date: 20200420 |
|
| EE01 | Entry into force of recordation of patent licensing contract | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| CP03 | Change of name, title or address |
Address after: 401120 b7-7-2, Yuxing Plaza, No.5, Huangyang Road, Yubei District, Chongqing Patentee after: Chongqing duxiaoman Youyang Technology Co.,Ltd. Address before: 201210 room j1328, 3 / F, building 8, 55 Huiyuan Road, Jiading District, Shanghai Patentee before: SHANGHAI YOUYANG NEW MEDIA INFORMATION TECHNOLOGY Co.,Ltd. |
|
| CP03 | Change of name, title or address |