Quasi-real-time request processing method, device, computer equipment and storage medium

Abstract

The embodiment of the present invention discloses a quasi-real-time request processing method, device, computer equipment and storage medium. The method comprises: in the correspondence between pre-configured quasi-real-time requests and status data, querying the quasi-real-time request corresponding to the abnormal state, the status data including the abnormal state; sending the quasi-real-time request corresponding to each abnormal state to the responder respectively, and receiving the request result fed back by the responder. The embodiment of the present invention can simplify the exception handling of quasi-real-time requests, reduce the cost of exception handling, and improve the efficiency of exception handling.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of data processing, and in particular to a quasi-real-time request processing method, device, computer equipment and storage medium. Background Art

[0002] In recent years, the use of service distributed architecture for business processing in business systems can reduce the coupling between different businesses and improve business processing efficiency.

[0003] The requester in the business system sends a request to the responder, and the responder feeds back the request result. Quasi-real-time requests have low requirements for real-time results and allow a certain delay, but require clear request results. If an exception occurs during the response process of a non-quasi-real-time request, the responder feeds back a failure result, which is manually processed.

[0004] For example, the requester sends a quasi-real-time request and waits for the responder to feedback the request result. After receiving the request result, the requester can send the next quasi-real-time request. Due to the long response time of quasi-real-time requests, the feedback failure result is provided to the user, and the user performs exception handling, resulting in low efficiency of exception handling, thereby reducing the processing efficiency of the next quasi-real-time request. Moreover, exception handling depends on the processing timeliness and exception scenarios of the responder, which increases the complexity of exception handling and reduces the efficiency of exception handling. Summary of the invention

[0005] The embodiments of the present invention provide a quasi-real-time request processing method, apparatus, computer equipment and storage medium, which can simplify the exception processing of quasi-real-time requests, reduce the cost of exception processing and improve the efficiency of exception processing.

[0006] In a first aspect, an embodiment of the present invention provides a quasi-real-time request processing method, comprising:

[0007] In the correspondence relationship between the pre-configured quasi-real-time request and the status data, querying the quasi-real-time request corresponding to the abnormal state, the status data including the abnormal state;

[0008] The quasi-real-time requests corresponding to the abnormal states are respectively sent to the responders, and the request results fed back by the responders are received.

[0009] In a second aspect, an embodiment of the present invention further provides a quasi-real-time request processing device, comprising:

[0010] An abnormal request query module, used to query the quasi-real-time request corresponding to the abnormal state in the pre-configured correspondence between the quasi-real-time request and the state data, wherein the state data includes the abnormal state;

[0011] The abnormal request retry module is used to send the quasi-real-time request corresponding to each abnormal state to the responder, and receive the request result fed back by the responder.

[0012] In a third aspect, an embodiment of the present invention further provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor; when the processor executes the program, the quasi-real-time request processing method as described in any one of the embodiments of the present invention is implemented.

[0013] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a quasi-real-time request processing method as described in any one of the embodiments of the present invention.

[0014] The embodiment of the present invention records the correspondence between quasi-real-time requests and status data, queries the quasi-real-time requests corresponding to the abnormal status, sends the quasi-real-time requests to the responder, and receives the request results fed back by the responder for the quasi-real-time requests corresponding to the abnormal status. This solves the problem of low exception handling efficiency caused by manual handling of exceptions to quasi-real-time requests in the prior art. It can automatically implement failed retries of quasi-real-time requests, improve the processing success rate of quasi-real-time requests, reduce the complexity of exception handling of quasi-real-time requests, and improve the real-time performance of exception handling of quasi-real-time requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 is a flow chart of a quasi-real-time request processing method in Embodiment 1 of the present invention;

[0016] Figure 2a is a flow chart of a quasi-real-time request processing method in Embodiment 2 of the present invention;

[0017] Figure 2b is a schematic diagram of an application scenario applicable to an embodiment of the present invention;

[0018] Figure 3 It is a structural diagram of a quasi-real-time request processing device in Embodiment 3 of the present invention;

[0019] Figure 4 It is a structural diagram of a computer device in Embodiment 4 of the present invention. DETAILED DESCRIPTION

[0020] The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the present invention, rather than to limit the present invention. It should also be noted that, for ease of description, only parts related to the present invention, rather than all structures, are shown in the accompanying drawings.

[0021] Embodiment 1

[0022] Figure 1 This is a schematic diagram of a flowchart of a quasi-real-time request processing method in Embodiment 1 of the present invention. This embodiment is applicable to the case where the requesting party sends a quasi-real-time request to the responding party. The method can be executed by the quasi-real-time request processing device provided by the embodiment of the present invention. The device can be implemented in software and / or hardware and can generally be integrated into a computer device. Figure 1 As shown, the method of this embodiment specifically includes:

[0023] S110, querying a quasi-real-time request corresponding to an abnormal state in a pre-configured correspondence relationship between quasi-real-time requests and status data, wherein the status data includes the abnormal state.

[0024] The quasi-real-time request may refer to a service request generated based on service data, and is used by the responder to provide a service matching the service request.

[0025] Optionally, the quasi-real-time request includes at least one of the following: a verification code request, an operation result notification request, an electronic voucher acquisition request, a client message notification setting request, an order processing request, and an asynchronous task request of a workflow nature.

[0026] Among them, the verification code request may specifically be a request initiated by the requesting party to obtain the verification code in scenarios such as account registration, login or payment. The operation result notification request may refer to a request to obtain the operation result after executing the set operation. For example, the operation may be a payment operation or a lottery operation, etc. If the operation is a payment operation, the operation result is a successful payment result or a failed payment result. The electronic voucher acquisition request may refer to a request to obtain a matching electronic voucher when the electronic voucher trigger condition is met in the set activity. The electronic voucher may be a coupon or a voucher, etc. The setting client message notification request may refer to a request for the communication client to send an interactive message notification. For example, the interactive message may include financial interaction (such as red envelopes or transfers) or information interaction (chat text, chat images, chat voice or chat video, etc.). The order processing request may be a request to initiate an ordering business. An asynchronous task of a workflow nature refers to a task that needs to be executed in sequence in the workflow scenario. Among them, a workflow is the automation of part or all of a business process in a computer application environment. The asynchronous task request of a workflow nature may be a request to initiate the execution of an asynchronous task of a workflow nature.

[0027] By configuring a quasi-real-time request as multiple business requests and applying them in multiple scenarios, the applicability of the quasi-real-time request processing method can be improved and the scenario diversity of the quasi-real-time request processing method can be increased.

[0028] Quasi-real-time requests are opposite to real-time requests, and the response time of quasi-real-time requests is usually longer than that of real-time requests. Specifically, a real-time request refers to a request that the responder processes in real time immediately after receiving the request. A quasi-real-time request refers to a request that the responder waits for a set time period before processing after receiving the request. Specifically, the response delay of a quasi-real-time request is longer than the response delay of a real-time request. On the responder side, quasi-real-time requests do not require immediate processing of the request results, and at the same time have certain requirements for the response timeliness, for example, the response time cannot be greater than the set time threshold, and the responder will feedback the processing results of the request.

[0029] The status data is used to determine whether the status of the quasi-real-time request is a normal status or an abnormal status. The normal status indicates that the request result of the quasi-real-time request is a successful result. The abnormal status indicates that the request result of the quasi-real-time request is a failed result.

[0030] The quasi-real-time request corresponding to the abnormal state is queried to obtain the quasi-real-time request for which no result has been received. The quasi-real-time request corresponding to the abnormal state may refer to the quasi-real-time request that has not been successfully processed in the past.

[0031] Optionally, the querying of the quasi-real-time request corresponding to the abnormal state includes: periodically polling status data including the abnormal state in a database, the database storing the correspondence between the quasi-real-time request and the status data; and obtaining the quasi-real-time request corresponding to each of the abnormal states.

[0032] The database stores the corresponding relationship between the state data and the quasi-real-time request, and the quasi-real-time request corresponding to the abnormal state can be queried in the database. Specifically, the abnormal state can be polled regularly in the database through a decentralized distributed timing scheduling framework (job), and the quasi-real-time request corresponding to the abnormal state can be obtained to retry the quasi-real-time request corresponding to the abnormal state. Through timed polling, quasi-real-time requests that failed to be processed can be obtained at a set frequency. Since retrying will increase the amount of data processed by the responder, through timed polling, a reasonable retry frequency can be configured to reduce the processing pressure of the responder and improve the success rate of the responder's retry processing.

[0033] Specifically, job is a distributed scheduling framework that can achieve horizontal segmentation of scheduled tasks, improve the overall stability and scalability of the requester, improve the execution efficiency of scheduled polling tasks, reduce the processing pressure of scheduled polling tasks, achieve load balancing, and support idempotent processing. In addition, the job framework is a lightweight framework that can reduce the complexity of introducing a distributed transaction framework and simplify the processing operations of scheduled polling tasks.

[0034] By periodically polling the abnormal status and obtaining the quasi-real-time request corresponding to the abnormal status, the frequency of retries can be reduced and the success rate of retry processing can be improved.

[0035] Optionally, before querying the quasi-real-time request corresponding to the abnormal state, it also includes: obtaining the quasi-real-time request, the quasi-real-time request is a request that receives a request result within a set time period; sending the quasi-real-time request to the responder, and receiving the request result fed back by the responder; if the request result is a failure result, an abnormal state is generated, and a corresponding relationship between the abnormal state and the quasi-real-time request is established and stored.

[0036] In fact, the set time period is a pre-configured response delay time. Usually, the response delay time of a quasi-real-time request is less than or equal to the time corresponding to the set time period.

[0037] The quasi-real-time request is obtained and sent to the responder. In fact, at the current moment, the first quasi-real-time request is sent to the responder for processing. The request result fed back by the responder may refer to the processing result of the responder processing the quasi-real-time request for the first time.

[0038] According to the processing result, the matching status data is generated accordingly, and a corresponding relationship between the status data and the quasi-real-time request is established and stored. The quasi-real-time request corresponding to the abnormal state is the request corresponding to the failure result. If the request result is a successful result, a normal state is generated, and a corresponding relationship between the normal state and the quasi-real-time request is established and stored, and the status data also includes the normal state. The quasi-real-time request corresponding to the normal state is the request corresponding to the successful result. By storing the status data and the quasi-real-time request in pairs, the quasi-real-time request corresponding to the failure result can be quickly and accurately obtained.

[0039] The corresponding relationship between the state data and the quasi-real-time request can be updated in real time upon receiving the processing result of the quasi-real-time request in response to the policy.

[0040] By pre-establishing the correspondence between status data and quasi-real-time requests, quasi-real-time requests with failed results can be quickly and accurately queried, so that exception handling can be performed for abnormal quasi-real-time requests, reducing the labor cost of exception handling and improving the efficiency of exception handling.

[0041] S120, sending the quasi-real-time requests corresponding to the abnormal states to the responders respectively, and receiving the request results fed back by the responders.

[0042] The quasi-real-time request corresponding to the abnormal state is sent to the responder to instruct the responder to reprocess the quasi-real-time request corresponding to the abnormal state, which is actually a retry processing of the quasi-real-time request corresponding to the abnormal state, thereby improving the processing accuracy of the quasi-real-time request corresponding to the abnormal state by the responder.

[0043] Optionally, the quasi-real-time request corresponding to the abnormal state is used to instruct the responder to perform idempotent processing on the quasi-real-time request corresponding to the abnormal state.

[0044] In fact, in the quasi-real-time request processing method provided by the embodiment of the present invention, the responder needs to repeatedly process the quasi-real-time requests that have not been successfully processed. At this time, the responder needs to support idempotency to avoid repeated execution of operations and cause operation errors. The characteristic of idempotent operations is that the impact of any multiple executions is the same as the impact of a single execution. Idempotent functions, or idempotent methods, refer to functions that can be repeatedly executed with the same parameters and can obtain the same results. These functions will not affect the system state, and there is no need to worry that repeated execution will cause changes to the system.

[0045] For example, if the requester initiates a payment request, the responder should only deduct the amount from the account once. If the network retransmission or system abnormal retransmission occurs, the amount should only be deducted once. The above operation of the responder is an idempotent operation. For another example, if the requester initiates a request to create a business order, the same creation request can only create one business order, and multiple orders will not be created repeatedly.

[0046] By performing idempotent processing on the quasi-real-time request, the result of each processing in the retry processing of the quasi-real-time request can be kept consistent, thereby improving the success rate of the retry processing of the responder.

[0047] The embodiment of the present invention records the correspondence between quasi-real-time requests and status data, queries the quasi-real-time requests corresponding to the abnormal status, sends the quasi-real-time requests to the responder, and receives the request results fed back by the responder for the quasi-real-time requests corresponding to the abnormal status. This solves the problem of low exception handling efficiency caused by manual handling of exceptions to quasi-real-time requests in the prior art. It can automatically implement failed retries of quasi-real-time requests, improve the processing success rate of quasi-real-time requests, reduce the complexity of exception handling of quasi-real-time requests, and improve the real-time performance of exception handling of quasi-real-time requests.

[0048] Embodiment 2

[0049] Figure 2a This is a flow chart of a quasi-real-time request processing method in Embodiment 2 of the present invention. This embodiment is specific based on the above embodiment. The method of this embodiment specifically includes:

[0050] S210, querying a quasi-real-time request corresponding to an abnormal state in a pre-configured correspondence relationship between quasi-real-time requests and status data, wherein the status data includes the abnormal state.

[0051] For a non-exhaustive description of the embodiments of the present invention, reference may be made to the aforementioned embodiments.

[0052] The requester may include a client, and the responder may include a server, or in a distributed structure, both the requester and the caller may be servers.

[0053] In the method provided by the embodiment of the present invention, the requester only needs to query the quasi-real-time request corresponding to the abnormal state and resend it to the responder. It does not need to pay attention to the state of the responder, the processing timeliness of the responder, or the abnormal scenario of the responder. The requester and the responder are decoupled, the dependence of the processing of the quasi-real-time request corresponding to the abnormal state on the responder is increased, the processing efficiency of the quasi-real-time request corresponding to the abnormal state is improved, and at the same time, the exception handling operation of the requester is simplified. The requester only needs to pay attention to its own business scenario and improve the quality of the code.

[0054] S220, sending the quasi-real-time requests corresponding to the abnormal states to the responders respectively, and receiving the request results fed back by the responders.

[0055] S230: If the request result is a success result, update the abnormal state to a normal state.

[0056] When the request result is a success result, it indicates that the quasi-real-time request processing is successful, and no exception compensation is required, that is, retry processing.

[0057] S240: If the request result is a failure result, maintain the abnormal state.

[0058] When the request result is a failure result, it indicates that the quasi-real-time request processing has failed, and it is necessary to continue to perform exception compensation, that is, retry processing, so as to maintain the abnormal state, so that the quasi-real-time request corresponding to the abnormal state can be queried next time and sent to the responder for repeated processing, thereby further improving the processing success rate of the quasi-real-time request corresponding to the abnormal state.

[0059] Optionally, while querying the quasi-real-time request corresponding to the abnormal state, it also includes: obtaining the number of retries matching each of the abnormal states; if it is determined that the target number of retries is greater than or equal to a set number threshold, then based on the abnormal state matching the target number of retries and the corresponding quasi-real-time request, generating an alarm message, and alerting the alarm user to instruct the alarm user to process the quasi-real-time request matching the target number of retries; while maintaining the abnormal state, it also includes: updating the number of retries matching the abnormal state.

[0060] The number of retries may refer to the number of times the same quasi-real-time request is sent to the responder for processing. Usually, the quasi-real-time request corresponding to the abnormal state will be retried, and the number of retries of the quasi-real-time processing request can be associated with the abnormal state and the quasi-real-time processing request for easy query. The number of retries can be an integer greater than or equal to zero. The set number threshold is used to determine whether to issue an alarm for the quasi-real-time request, and to determine whether manual intervention is required to process the quasi-real-time request. If the target number of retries is greater than or equal to the set number threshold, it indicates that the quasi-real-time request has been retried too many times, and that the abnormality of the quasi-real-time request is difficult to compensate for and requires manual processing. The alarm information is used to provide the quasi-real-time request that cannot be compensated for the abnormality to the alarm user, and to manually handle the abnormality of the quasi-real-time request.

[0061] Update the number of retries for abnormal status matching. When the request result is a failure, the number of retries for abnormal status matching can be accumulated to a set value. Update the number of retries to accumulate the number of times the quasi-real-time request is repeatedly sent to the responder.

[0062] In addition, the abnormal type of the quasi-real-time request can also be recorded to facilitate the alarm user to handle. Among them, the alarm method can include at least one of a communication client notification, a text message notification, and a phone notification.

[0063] By configuring the number of retries for the quasi-real-time request corresponding to the abnormal state and issuing an alarm when the number of retries is greater than or equal to the set threshold, it is possible to avoid unlimited repeated processing of the quasi-real-time request corresponding to the abnormal state, release the processing resources for the quasi-real-time request corresponding to the abnormal state, reasonably allocate resources, and notify the alarm user in real time to process the quasi-real-time request corresponding to the abnormal state, thereby improving the real-time performance of manual processing of abnormal quasi-real-time requests and improving the processing efficiency of quasi-real-time requests corresponding to the abnormal state.

[0064] In a specific example, Figure 2bAs shown, the requester 201 generates a quasi-real-time request, stores the quasi-real-time request in a database 203, and sends the quasi-real-time request to the responder 202 for processing. The responder 202 feeds back the request result to the requester 201. The requester 201 associates the status data matched by the request result with the quasi-real-time request and stores it in the database 203. The requester 201 periodically polls the database 203 through the job framework to obtain the quasi-real-time request corresponding to the abnormal state, and sends it to the responder 202 for processing. The responder 202 feeds back the request result to the requester 201. The requester 201 updates the status data corresponding to the quasi-real-time request with the status data matched by the request result to update the database 203. The requester 201 queries the database 203 for the number of retries matched by the abnormal state. If it is determined that the number of retries is greater than or equal to the set number threshold, an alarm message is generated and sent to the alarm user. The alarm message can be the content of an email or the interactive information of a communication client. In addition, it can also be the content of a phone call.

[0065] The embodiment of the present invention can accurately update the status data of the quasi-real-time request according to the processing result of the quasi-real-time request retry processing by receiving the request result of the quasi-real-time request feedback corresponding to the abnormal state on the responding party, determining the status data of the quasi-real-time request according to the request result, and updating or maintaining the status data, so as to process the quasi-real-time request that is determined to be in an abnormal state again, thereby improving the processing success rate of the quasi-real-time request corresponding to the abnormal state.

[0066] Embodiment 3

[0067] Figure 3 Schematic diagram of a quasi-real-time request processing device in Embodiment 3 of the present invention. Embodiment 3 is a corresponding device for implementing the quasi-real-time request processing method provided by the above embodiments of the present invention, which can be implemented in software and / or hardware and can generally be integrated into a computer device.

[0068] Accordingly, the device of this embodiment may include:

[0069] The abnormal request query module 310 is used to query the quasi-real-time request corresponding to the abnormal state in the pre-configured correspondence between the quasi-real-time request and the state data, wherein the state data includes the abnormal state;

[0070] The abnormal request retry module 320 is used to send the quasi-real-time request corresponding to each abnormal state to the responder, and receive the request result fed back by the responder.

[0071] The embodiment of the present invention records the correspondence between quasi-real-time requests and status data, queries the quasi-real-time requests corresponding to the abnormal status, sends the quasi-real-time requests to the responder, and receives the request results fed back by the responder for the quasi-real-time requests corresponding to the abnormal status. This solves the problem of low exception handling efficiency caused by manual handling of exceptions to quasi-real-time requests in the prior art. It can automatically implement failed retries of quasi-real-time requests, improve the processing success rate of quasi-real-time requests, reduce the complexity of exception handling of quasi-real-time requests, and improve the real-time performance of exception handling of quasi-real-time requests.

[0072] Furthermore, the quasi-real-time request processing device also includes: a corresponding relationship establishment module, which is used to obtain a quasi-real-time request before querying the quasi-real-time request corresponding to the abnormal state, and the quasi-real-time request is a request that receives a request result within a set time period; send the quasi-real-time request to the responder, and receive the request result fed back by the responder; if the request result is a failure result, generate an abnormal state, and establish a corresponding relationship between the abnormal state and the quasi-real-time request for storage.

[0073] Furthermore, the abnormal request query module 310 includes: a timed polling unit for periodically polling status data including abnormal status in a database, wherein the database stores the correspondence between quasi-real-time requests and status data; and obtaining quasi-real-time requests corresponding to each of the abnormal statuses.

[0074] Furthermore, the quasi-real-time request processing device also includes: a status data updating module, which is used to update the abnormal state to a normal state after receiving the request result fed back by the responder if the request result is a successful result; if the request result is a failed result, maintain the abnormal state.

[0075] Furthermore, the quasi-real-time request processing device also includes: a retry count update module, which is used to obtain the retry count matching each abnormal state while querying the quasi-real-time request corresponding to the abnormal state; if it is determined that the target retry count is greater than or equal to the set count threshold, then based on the abnormal state matching the target retry count and the corresponding quasi-real-time request, an alarm message is generated, and an alarm user is alerted to instruct the alarm user to process the quasi-real-time request matching the target retry count; while maintaining the abnormal state, the retry count matching the abnormal state is updated.

[0076] Furthermore, the quasi-real-time request corresponding to the abnormal state is used to instruct the responder to perform idempotent processing on the quasi-real-time request corresponding to the abnormal state.

[0077] Furthermore, the quasi-real-time request includes at least one of the following: a verification code request, an operation result notification request, an electronic voucher acquisition request, a client message notification setting request, an order processing request, and an asynchronous task request of a workflow nature.

[0078] The above-mentioned device can execute the quasi-real-time request processing method provided by the embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0079] Embodiment 4

[0080] Figure 4 A schematic diagram of the structure of a computer device provided in Embodiment 4 of the present invention. Figure 4 A block diagram of an exemplary computer device 12 suitable for use in implementing embodiments of the present invention is shown. Figure 4 The computer device 12 shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0081] like Figure 4 As shown, the computer device 12 is in the form of a general-purpose computing device. The components of the computer device 12 may include, but are not limited to: one or more processors or processing units 16, a system memory 28, and a bus 18 connecting different system components (including the system memory 28 and the processing unit 16). The computer device 12 may be a device attached to the bus.

[0082] Bus 18 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor, or a local bus using any of a variety of bus structures. For example, these architectures include but are not limited to Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0083] The computer device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the computer device 12, including volatile and non-volatile media, removable and non-removable media.

[0084] The system memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. The computer device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 34 may be used to read and write non-removable, non-volatile magnetic media ( Figure 4 not shown, usually called a "hard drive"). Although Figure 4 Not shown in the figure, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk"), and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a compact disk read-only memory (CD-ROM), a digital video disk (DVD-ROM) or other optical media) may be provided. In these cases, each drive may be connected to the bus 18 via one or more data medium interfaces. The system memory 28 may include at least one program product having a set (e.g., at least one) of program modules that are configured to perform the functions of the various embodiments of the present invention.

[0085] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28, such program modules 42 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment. Program modules 42 generally perform the functions and / or methods of the embodiments described herein.

[0086] The computer device 12 may also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), one or more devices that enable a user to interact with the computer device 12, and / or any device that enables the computer device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). Such communication may be performed through an input / output (I / O) interface 22. In addition, the computer device 12 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN)) through a network adapter 20. As shown in the figure, the network adapter 20 communicates with other modules of the computer device 12 through the bus 18. It should be understood that although Figure 4Not shown, other hardware and / or software modules may be used in conjunction with the computer device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays (Redundant Arrays of Inexpensive Disks, RAID) systems, tape drives, and data backup storage systems.

[0087] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the quasi-real-time request processing method provided by any embodiment of the present invention.

[0088] Embodiment 5

[0089] Embodiment 5 of the present invention provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the method provided in all the embodiments of the present invention is implemented:

[0090] That is, when the program is executed by the processor, it is implemented as follows: in the correspondence between the pre-configured quasi-real-time requests and the status data, the quasi-real-time request corresponding to the abnormal state is queried, and the status data includes the abnormal state; the quasi-real-time request corresponding to each of the abnormal states is sent to the responder respectively, and the request result fed back by the responder is received.

[0091] The computer storage medium of the embodiment of the present invention can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a RAM, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, an optical fiber, a portable CD-ROM, an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, a device or a device or used in combination with it.

[0092] Computer-readable signal media may include a data signal propagated in baseband or as part of a carrier wave, which carries a computer-readable program code. Such propagated data signals may take a variety of forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0093] The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wire, optical cable, radio frequency (RF), etc., or any suitable combination of the foregoing.

[0094] Computer program code for performing the operations of the present invention may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a LAN or WAN, or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0095] Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A quasi-real-time request processing method, characterized in that: include: In the correspondence relationship between the pre-configured quasi-real-time request and the status data, querying the quasi-real-time request corresponding to the abnormal state, the status data including the abnormal state; Sending the quasi-real-time requests corresponding to each of the abnormal states to the responding party respectively, and receiving the request results fed back by the responding party; The quasi-real-time request refers to a service request generated according to service data, which is used by the responder to provide a service matching the service request; the response delay of the quasi-real-time request is greater than the response delay of the real-time request; The quasi-real-time request corresponding to the abnormal state is used to instruct the responder to perform idempotent processing on the quasi-real-time request corresponding to the abnormal state; The quasi-real-time request includes at least one of the following: a verification code request, an operation result notification request, an electronic voucher acquisition request, a client message notification setting request, an order processing request, and an asynchronous task request of a workflow nature; Before querying the quasi-real-time request corresponding to the abnormal status, it also includes: Obtaining a quasi-real-time request, wherein the quasi-real-time request is a request for which a request result is received within a set time period; Sending the quasi-real-time request to the responder, and receiving the request result fed back by the responder; If the request result is a failure result, an abnormal state is generated, and a corresponding relationship between the abnormal state and the quasi-real-time request is established and stored.

2. The method according to claim 1, characterized in that The quasi-real-time request corresponding to the abnormal state of the query includes: Periodically polling status data including abnormal status in a database, wherein the database stores a correspondence between quasi-real-time requests and status data; A quasi-real-time request corresponding to each of the abnormal states is obtained.

3. The method according to claim 1, characterized in that After receiving the request result fed back by the responder, the method further includes: If the request result is a successful result, updating the abnormal state to a normal state; If the request result is a failure result, the abnormal state is maintained.

4. The method according to claim 3, characterized in that When querying the quasi-real-time request corresponding to the abnormal status, it also includes: Obtain the number of retries matched by each of the abnormal states; If it is determined that the target retry number is greater than or equal to the set number threshold, an alarm message is generated according to the abnormal state matching the target retry number and the corresponding quasi-real-time request, and an alarm is issued to the alarm user to instruct the alarm user to process the quasi-real-time request matching the target retry number; While maintaining the abnormal state, it also includes: Update the number of retries matching the abnormal state.

5. A quasi-real-time request processing device, characterized in that: include: An abnormal request query module, used to query the quasi-real-time request corresponding to the abnormal state in the pre-configured correspondence between the quasi-real-time request and the state data, wherein the state data includes the abnormal state; An abnormal request retry module is used to send the quasi-real-time request corresponding to each abnormal state to the responder, and receive the request result fed back by the responder; The quasi-real-time request refers to a service request generated according to service data, which is used by the responder to provide a service matching the service request; the response delay of the quasi-real-time request is greater than the response delay of the real-time request; The quasi-real-time request corresponding to the abnormal state is used to instruct the responder to perform idempotent processing on the quasi-real-time request corresponding to the abnormal state; The quasi-real-time request includes at least one of the following: a verification code request, an operation result notification request, an electronic voucher acquisition request, a client message notification setting request, an order processing request, and an asynchronous task request of a workflow nature; The quasi-real-time request processing device also includes: a corresponding relationship establishing module, which is used to obtain a quasi-real-time request before querying the quasi-real-time request corresponding to the abnormal state, wherein the quasi-real-time request is a request that receives a request result within a set time period; send the quasi-real-time request to the responder, and receive the request result fed back by the responder; if the request result is a failure result, generate an abnormal state, establish a corresponding relationship between the abnormal state and the quasi-real-time request, and store it.

6. A computer device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the quasi-real-time request processing method as described in any one of claims 1-4 is implemented.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the quasi-real-time request processing method as described in any one of claims 1 to 4 is implemented.

Images