Order processing method, device, storage medium and electronic device

Abstract

The present disclosure relates to an order processing method, device, storage medium and electronic device, so as to avoid users from repeatedly sending order requests after the interface of the ticket supply system returns to normal from abnormality, thereby improving the order processing efficiency. The order processing method comprises: determining that the interface of the ticket supply system is abnormal; saving the order information used to initiate a request to the ticket supply system into an acquiring cache; if the interface of the ticket supply system returns to normal, sending a request to the ticket supply system according to the order information in the acquiring cache.

Description

Technical Field

[0001] The present disclosure relates to the field of data processing technology, and in particular, to an order processing method, device, storage medium and electronic device. Background Art

[0002] With the continuous development of computer technology, more and more people choose to buy tickets online. However, when people buy tickets online, the ticket supply system may have system instability or abnormal ticket purchase during peak hours. In the related art, in order to deal with the above problems in the ticket supply system, when the ticket supply system is detected to be abnormal, the order transaction submitted by the user is usually controlled to fail, or the ticket sales are stopped. Therefore, when the ticket supply system returns to normal, it is necessary to resend the order request to the ticket supply system. Summary of the invention

[0003] The purpose of the present disclosure is to provide an order processing method, device, storage medium and electronic device to avoid users from repeatedly sending order requests and improve order processing efficiency.

[0004] In order to achieve the above objectives, in a first aspect, the present disclosure provides an order processing method, comprising:

[0005] Identify interface anomalies with the ticketing provisioning system;

[0006] Saving order information used to initiate a request to the ticketing provisioning system in an acquiring cache;

[0007] If the interface of the ticket supply system returns to normal, a request is sent to the ticket supply system according to the order information in the acquiring buffer.

[0008] Optionally, the method further comprises:

[0009] sending a simulated order request to the ticket provisioning system;

[0010] If the response of the ticket supply system to the simulated order request meets a preset condition, it is determined that the interface of the ticket supply system is restored to normal.

[0011] Optionally, the preset conditions include:

[0012] The ticket supply system responds to the simulated order request successfully for a preset number of consecutive times; or,

[0013] The response of the ticket supply system to the simulated order request is failure, and the failure type is not an interface exception type.

[0014] Optionally, sending a request to the ticket supply system according to the order information in the acquiring cache includes:

[0015] Determine the order status of the order information in the acquiring cache, wherein the order status of each order information is an unordered state or an unpaid state;

[0016] According to the order status, an order request or a payment request is sent to the ticket supply system for each order information.

[0017] Optionally, sending a request to the ticket supply system according to the order information in the acquiring cache includes:

[0018] For the order information in the acquiring cache that is in an unordered state, sending an order request to the order interface of the ticket supply system;

[0019] If a successful order response from the ticket supply system is received, a payment request is sent to a payment interface of the ticket supply system;

[0020] If an interface exception occurs again in the ticket supply system before the ticket supply system responds to the payment request, the order information is saved again in the acquiring cache, and the order information is marked as unpaid.

[0021] Optionally, the ticket supply system supports idempotence verification, and sending a request to the ticket supply system according to the order information in the acquiring cache includes:

[0022] Determine whether there are multiple order information with the same order number and in different order statuses in the acquiring cache;

[0023] If there is first order information in an unordered state and second order information in an unpaid state in the acquiring cache, sending a request to the order interface of the ticket supply system according to the first order information in the unordered state, wherein the first order information and the second order information have the same order number;

[0024] After the order is successfully placed, a request is sent to the payment interface of the ticket supply system according to the second order information in an unpaid state.

[0025] Optionally, the method further comprises:

[0026] If the ticketing supply system responds successfully to the order information, deleting the order information in the acquiring cache; or

[0027] If no response to the order information from the ticket supply system is received within a preset time period, the order information in the acquiring buffer is deleted.

[0028] In a second aspect, the present disclosure further provides an order processing device, the device comprising:

[0029] A determination module, used to determine interface anomalies of the ticketing provision system;

[0030] A saving module, used to save the order information used to initiate a request to the ticket supply system into an acquiring cache;

[0031] The sending module is used to send a request to the ticket supply system according to the order information in the acquiring buffer when the interface of the ticket supply system returns to normal.

[0032] Optionally, the device further comprises:

[0033] A request sending module, used for sending a simulated order request to the ticket supply system;

[0034] The interface determination module is used to determine that the interface of the ticket supply system is restored to normal when the response of the ticket supply system to the simulated order request meets a preset condition.

[0035] Optionally, the preset conditions include:

[0036] The ticket supply system responds to the simulated order request successfully for a preset number of consecutive times; or,

[0037] The response of the ticket supply system to the simulated order request is failure, and the failure type is not an interface exception type.

[0038] Optionally, the sending module is used to:

[0039] Determine the order status of the order information in the acquiring cache, wherein the order status of each order information is an unordered state or an unpaid state;

[0040] According to the order status, an order request or a payment request is sent to the ticket supply system for each order information.

[0041] Optionally, the sending module is used to:

[0042] For the order information in the acquiring cache that is in an unordered state, sending an order request to the order interface of the ticket supply system;

[0043] If a successful order response from the ticket supply system is received, a payment request is sent to a payment interface of the ticket supply system;

[0044] If an interface exception occurs again in the ticket supply system before the ticket supply system responds to the payment request, the order information is saved again in the acquiring cache, and the order information is marked as unpaid.

[0045] Optionally, the ticketing supply system supports idempotency verification, and the sending module is used to:

[0046] Determine whether there are multiple order information with the same order number and in different order statuses in the acquiring cache;

[0047] If there is first order information in an unordered state and second order information in an unpaid state in the acquiring cache, sending a request to the order interface of the ticket supply system according to the first order information in the unordered state, wherein the first order information and the second order information have the same order number;

[0048] After the order is successfully placed, a request is sent to the payment interface of the ticket supply system according to the second order information in an unpaid state.

[0049] Optionally, the device further comprises:

[0050] A first deleting module, configured to delete the order information in the acquiring cache when the ticketing supply system responds successfully to the order information; or

[0051] The second deleting module is configured to delete the order information in the acquiring buffer when no response to the order information from the ticket supply system is received within a preset period of time.

[0052] In a third aspect, the present disclosure further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of any one of the methods described in the first aspect.

[0053] In a fourth aspect, the present disclosure further provides an electronic device, including:

[0054] a memory having a computer program stored thereon;

[0055] A processor is used to execute the computer program in the memory to implement the steps of any one of the methods in the first aspect.

[0056] Through the above technical solution, when an abnormality occurs in the interface of the ticket supply system, the user's order information can be saved in the acquiring cache. Then, when the interface of the ticket supply system returns to normal, the order request can continue to be sent to the ticket supply system according to the order information in the acquiring cache. Compared with the method of directly controlling the failure of user order transactions or stopping sales in related technologies, the method disclosed in the present invention does not require users to repeatedly initiate order requests, thereby improving order processing efficiency.

[0057] Other features and advantages of the present disclosure will be described in detail in the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] The accompanying drawings are used to provide a further understanding of the present disclosure and constitute a part of the specification. Together with the following specific embodiments, they are used to explain the present disclosure but do not constitute a limitation of the present disclosure. In the accompanying drawings:

[0059] Figure 1 is a schematic diagram of an application scenario of an order processing method according to an exemplary embodiment of the present disclosure;

[0060] Figure 2 is a flow chart of an order processing method according to an exemplary embodiment of the present disclosure;

[0061] Figure 3 is a flow chart of an order processing method according to another exemplary embodiment of the present disclosure;

[0062] Figure 4 is a block diagram of an order processing device according to an exemplary embodiment of the present disclosure;

[0063] Figure 5 It is a block diagram of an electronic device according to an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION

[0064] The specific implementation of the present disclosure is described in detail below in conjunction with the accompanying drawings. It should be understood that the specific implementation described herein is only used to illustrate and explain the present disclosure, and is not used to limit the present disclosure.

[0065] With the continuous development of computer technology, more and more people choose to buy tickets online. However, when people buy tickets online, the ticket supply system may have system instability or abnormal ticket purchase during peak hours. In the related art, in order to deal with the above problems in the ticket supply system, when the ticket supply system is detected to be abnormal, the order transaction submitted by the user is usually controlled to fail, or the ticket sales are stopped. Therefore, when the ticket supply system returns to normal, it is necessary to resend the order request to the ticket supply system.

[0066] In order to solve the above problems, the present disclosure provides an order processing method, device, storage medium and electronic device to avoid users from repeatedly sending order requests and improve order processing efficiency.

[0067] First, the application scenario of the embodiment of the present disclosure is described. Figure 1 The order processing method in the embodiment of the present disclosure can be applied to the third-party ticketing system 101 ( Figure 1 The third-party ticketing system is used as a server for illustration). The third-party ticketing system 101 can receive the user terminal 102 ( Figure 1 The order request is sent by the user terminal as a mobile phone, and the order request is sent to the ticket supply system 103 ( Figure 1 The ticket supply system is used as a server for illustration), thereby completing the processing of the order request initiated by the user. It should be understood that Figure 1 This is merely an illustrative description of the application scenario of the order processing method provided by the present disclosure and is not intended to limit the present disclosure.

[0068] The following is the disclosure of Figure 1 The order processing method in the embodiment of the present disclosure is explained by taking the application scenario shown as an example.

[0069] Figure 2 is a flowchart of an order processing method according to an exemplary embodiment of the present disclosure. Figure 2 , the order processing method may include:

[0070] Step S201: determining that an interface of the ticketing supply system is abnormal.

[0071] For example, the interface of the ticket supply system may be determined to be abnormal when any of the following situations is detected: interface connection timeout of the ticket supply system, timeout in reading data from the interface of the ticket supply system, abnormal parsing of data obtained from the interface of the ticket supply system, etc., which is not limited in the embodiments of the present disclosure.

[0072] Step S202: Save the order information used to initiate a request to the ticket supply system into the acquiring cache.

[0073] That is to say, in the embodiments of the present disclosure, the acquiring cache is used to save order information when the interface of the ticket supply system is abnormal. For example, the acquiring cache can save order information in the form of a queue, or can also save order information in the form of an array, etc. The embodiments of the present disclosure are not limited to this.

[0074] Step S203: if the interface of the ticket supply system is restored to normal, a request is sent to the ticket supply system according to the order information in the acquiring buffer.

[0075] In the above manner, when an exception occurs in the interface of the ticket supply system, the user's order information can be saved in the acquiring cache. Then, when the interface of the ticket supply system returns to normal, the order request can continue to be sent to the ticket supply system according to the order information in the acquiring cache. The user does not need to repeatedly initiate order requests, thereby improving order processing efficiency.

[0076] In a possible manner, the embodiment of the present disclosure may also send a simulated order request to the ticket supply system. If the response of the ticket supply system to the simulated order request meets a preset condition, it is determined that the interface of the ticket supply system has returned to normal.

[0077] For example, sending the simulated order request to the ticket supply system may be sent continuously or periodically, such as sending a simulated order request to the ticket supply system once every one minute, etc., which is not limited in the embodiments of the present disclosure.

[0078] In one possible manner, the preset condition may include that the ticket supply system successfully responds to the simulated order request for a preset number of consecutive times; or that the ticket supply system fails to respond to the simulated order request, and the failure type is not an interface exception type.

[0079] For example, the preset number of times can be set according to actual conditions, etc., which is not limited in the embodiments of the present disclosure. For example, according to actual conditions, the preset number of times can be set to six times, and when the ticket supply system responds to the simulated order request successfully for six consecutive times, it can be determined that the interface of the ticket supply system has returned to normal.

[0080] Alternatively, in other possible cases, if the simulated order request does not meet the ticket purchase requirements of the ticket supply system, then the ticket supply system's response to the simulated order request is a failure, and this failure is not caused by an interface exception of the ticket supply system, that is, the failure type is not an interface exception type, so it can be determined that the interface of the ticket supply system has returned to normal.

[0081] It should be understood that in the embodiment of the present disclosure, when there is one failure in the ticket supply system's response to the simulated order request, and the failure type is not an interface abnormal type, it can be determined that the interface of the ticket supply system has returned to normal. Alternatively, in order to improve the accuracy of the judgment result, when there are multiple failures in the ticket supply system's response to the simulated order request, and the failure type is not an interface abnormal type, it can be determined that the interface of the ticket supply system has returned to normal, and the embodiment of the present disclosure is not limited to this.

[0082] Through the above method, if the interface of the ticket supply system is abnormal, a simulated order request can be sent to the ticket supply system while the order information is saved in the acquiring cache. Then, it can be determined whether the interface of the ticket supply system has returned to normal based on the response result of the ticket supply system to the simulated order request. In this way, it is possible to automatically detect whether the interface of the ticket supply system has returned to normal, so that when the interface returns to normal, a request can be sent to the ticket supply system in time according to the order information in the acquiring cache, thereby further improving the order processing efficiency.

[0083] In one possible manner, in step S203, the order status of the order information in the acquiring cache may be determined first, wherein the order status of each order information is an unordered state or an unpaid state, and then, based on the order status, an order request or a payment request is sent to the ticketing supply system for each order information.

[0084] When a user terminal purchases tickets online through a third-party ticketing system, each order has an ordering stage and a payment stage. The ordering stage refers to the stage from when the user terminal sends an order request to the third-party ticketing system to when the user terminal receives an order response message sent by the third-party ticketing system. The payment stage refers to the stage from when the user terminal sends a payment request to the third-party ticketing system after receiving a response message sent by the third-party ticketing system indicating a successful order to when the user terminal receives a payment response message sent by the third-party ticketing system.

[0085] If an exception occurs in the interface of the ticket supply system during the ordering stage, that is, the user fails to place an order, then the order status corresponding to the order information initiated to the ticket supply system is the unordered state. If an exception occurs in the interface of the ticket supply system during the payment stage, that is, the user successfully places an order but the payment fails, then the order status corresponding to the order information initiated to the ticket supply system is the unpaid state.

[0086] After determining the order status of the order information, an order request or a payment request may be sent to the ticket supply system for each order information according to the order status.

[0087] In a possible case, if the order information is only saved in the acquiring cache at the order placement stage (i.e., the order information in the order status is the unordered state), then when the interface of the ticket supply system returns to normal, an order request can be sent to the order placement interface of the ticket supply system. It should be understood that if the order success response sent by the ticket supply system is not received, a message indicating that the order placement failed can be returned to the user terminal.

[0088] In another possible case, if the order information is only saved in the acquiring cache during the payment phase (i.e., the order information in the unpaid state), a payment request can be sent to the payment interface of the ticket supply system when the interface of the ticket supply system returns to normal. It should be understood that if the order success response sent by the ticket supply system is not received, a message indicating payment failure can be returned to the user terminal.

[0089] In another possible situation, when the ticket supply system has repeated system instability, there may be order information that is saved in the acquiring cache at both the order placement stage and the payment stage. In this case, an order request can be sent to the order interface of the ticket supply system for the order information in the acquiring cache that is in an unordered state. If a successful order response is received from the ticket supply system, a payment request is sent to the payment interface of the ticket supply system. If an interface exception occurs again in the ticket supply system before the ticket supply system responds to the payment request, the order information is saved in the acquiring cache again and the order information is marked as unpaid.

[0090] That is to say, for the order information that is saved in the acquiring cache at both the order placement stage and the payment stage, when releasing the order information (sending a request to the ticketing supply system based on the order information in the acquiring cache), the order information can be released based on the order status. Specifically, the order information in the acquiring cache that is in the unordered state can be released first. Then, after the order information in the unordered state is successfully released, the order information in the unpaid state can be released.

[0091] Furthermore, if an interface exception occurs again in the ticket supply system during the process of releasing order information in an unpaid state (before the ticket supply system responds to a payment request), the order information can be marked as unpaid and saved in the acquiring cache again. When the ticket supply system returns to normal, a payment request can be sent directly to the payment interface, further improving order processing efficiency.

[0092] It should be understood that if an interface exception occurs again in the ticket supply system before the ticket supply system responds to the payment request, while marking the order information as unpaid and saving it in the acquiring cache again, a message indicating payment failure may be returned to the user terminal.

[0093] In one possible case, if after sending a request corresponding to order information A to the ticket supply system, it is determined that the interface of the ticket supply system is abnormal, the order information A used to initiate the request to the ticket supply system can be saved in the acquiring cache, and then when the interface of the ticket supply system returns to normal, the request can be resent to the ticket supply system based on the order information A in the acquiring cache.

[0094] However, the ticket supply system has already received the request corresponding to the order information A, and may have successfully responded to the request corresponding to the order information A. Then, when the ticket supply system receives the request corresponding to the order information A again after the interface returns to normal, it will return a failure response message.

[0095] To avoid this situation, the ticket supply system can support idempotence verification, so that the ticket supply system can re-respond to historical requests that have been sent before, ensuring that the first order information saved in the acquiring cache can be re-responded when an exception occurs in the interface of the ticket supply system, or ensuring that the order information that has been saved again in the acquiring cache due to repeated instability of the ticket supply system can be re-responded.

[0096] Accordingly, in the case where the ticket supply system supports idempotency verification, the process of sending a request to the ticket supply system according to the order information in the acquiring cache may be to first determine whether there are multiple order information with the same order number and in different order states in the acquiring cache. If there is a first order information in an unordered state and a second order information in an unpaid state in the acquiring cache, a request is sent to the order interface of the ticket supply system according to the first order information in the unordered state, and then, after the order is successfully placed, a request is sent to the payment interface of the ticket supply system according to the second order information in the unpaid state. The first order information and the second order information have the same order number.

[0097] That is to say, when releasing the order information in the acquiring cache (sending a request to the ticketing supply system according to the order information in the acquiring cache), the release can be performed according to the order number. Specifically, the order information with the same order number can be released first, and then other order information with the same order number can be released. And the release process of the order information with the same order number can be to first release the first order information in the unordered state, and then release the second order information after the first order information is successfully released.

[0098] Through the above method, when releasing the order information in the acquiring cache, it can be released according to the order status or according to the order number, thereby meeting different application scenarios and usage requirements and having a wide range of applications.

[0099] Furthermore, in order to prevent the order information from being stored in the acquirer cache for a long time, reduce the storage pressure of the acquirer cache and the processing pressure of the ticket supply system on the order information in the acquirer cache, the order information in the acquirer cache can be deleted. In one possible case, if the ticket supply system responds successfully to the order information, the order information in the acquirer cache can be deleted; or if no response to the order information from the ticket supply system is received within a preset time, the order information in the acquirer cache can be deleted.

[0100] For example, the preset time length may be set according to preset rules, etc., which is not limited in the embodiments of the present disclosure. For example, when a request is sent to the ticket supply system during the day, the preset time length may be set to 1 hour. If a response to the order information from the ticket supply system is not received for more than 1 hour, the order information in the acquiring cache may be deleted. Alternatively, when a request is sent to the ticket supply system at night, the preset time length may be set to 2 hours. If a response to the order information from the ticket supply system is not received for more than 2 hours, the order information in the acquiring cache may be deleted. Alternatively, for peak ticket purchase periods and ticket orders that need to be used on the same day, the preset time length may be set to 10 minutes. If a response to the order information from the ticket supply system is not received for more than 10 minutes, the order information in the acquiring cache may be deleted.

[0101] In one possible manner, after the order information used to initiate a request to the ticket supply system is saved in the acquiring cache, the time period for which the order information is saved in the acquiring cache can also be determined, and then the waiting time corresponding to the time period is displayed to the user terminal that sent the order information.

[0102] For example, the time period saved to the acquiring cache and the waiting time corresponding to the time period can be set according to different application requirements, etc., and the embodiments of the present disclosure do not limit this. For example, the time period saved to the acquiring cache can include a weekend time period and a weekday time period. Accordingly, the waiting time corresponding to the weekend time period can be 10 minutes, and the waiting time for the weekday time period can be 30 minutes. Alternatively, the time period saved to the acquiring cache can include a holiday time period and a non-holiday time period. Accordingly, the waiting time corresponding to the holiday time period can be 5 minutes, and the waiting time for the non-holiday time period can be 15 minutes, and so on.

[0103] By means of the above method, after an abnormality occurs in the interface of the ticket supply system, the order processing time that the user needs to wait for can be estimated and displayed to the user terminal, thereby increasing the intelligence of the order processing process.

[0104] The following uses the ticket supply system supporting idempotent verification as an example to illustrate the order processing method in the present disclosure through a complete embodiment. Figure 3 , the order processing method may include the following steps:

[0105] Step S301: determine that the interface of the ticketing supply system is abnormal.

[0106] Step S302: Save the order information used to initiate a request to the ticket supply system into the acquiring cache.

[0107] Step S303: sending a simulated order request to the ticket supply system.

[0108] Step S304, determining whether the response of the ticket supply system to the simulated order request meets the preset condition, if yes, proceeding to step S305, otherwise proceeding to step S306.

[0109] It should be understood that the preset condition may include the ticket supply system successfully responding to the simulated order request for a preset number of consecutive times; or the ticket supply system failing to respond to the simulated order request, and the failure type is not an interface exception type.

[0110] Step S305: Determine whether the interface of the ticket supply system has returned to normal.

[0111] It should be understood that if Figure 3 As shown, in the embodiment of the present disclosure, the order information may be first saved in the acquiring cache, and then a simulated order request may be sent to the ticket supply system to determine whether the interface of the ticket supply system has returned to normal. Alternatively, in other possible cases, a simulated order request may be sent to the ticket supply system to determine whether the interface of the ticket supply system has returned to normal, and then the order information may be saved in the acquiring cache. Alternatively, the process of saving the order information in the acquiring cache and sending a simulated order request to the ticket supply system to determine whether the interface of the ticket supply system has returned to normal may be performed simultaneously, and the embodiment of the present disclosure is not limited to this.

[0112] Step S306, determining whether a preset time period has elapsed without receiving a response from the ticket supply system to the order information, if yes, proceeding to step S307, otherwise proceeding to step S303.

[0113] Step S307, deleting order information in the acquiring cache that has not received a response for more than a preset period of time.

[0114] Step S308: When the interface of the ticket supply system returns to normal, the order status of the order information in the acquiring buffer is determined.

[0115] Step S309, determining whether there are multiple order information with the same order number and in different order statuses in the acquiring cache, if there is a first order information in an unordered state and a second order information in an unpaid state in the acquiring cache, proceed to step S310, otherwise proceed to step S311. The first order information and the second order information have the same order number.

[0116] Step S310: For the first order information in the acquiring cache that is in an unordered state, a request is sent to the order placement interface of the ticketing supply system.

[0117] Step S311, for order information in an unordered state, a request is sent to the order interface of the ticket supply system, or for order information in an unpaid state, a request is sent to the payment interface of the ticket supply system.

[0118] Step S312, after sending a request to the order interface of the ticket supply system according to the first order information, determine whether a successful order response sent by the ticket supply system is received, if yes, proceed to step S313, otherwise proceed to step S314.

[0119] Step S313: Send a payment request to the payment interface of the ticketing supply system, and delete the first order information that is successfully responded to in the acquiring cache.

[0120] Step S314: Return a response message indicating order failure or payment failure to the user terminal.

[0121] Step S315, determining whether the ticket supply system sends an interface exception again before the ticket supply system responds to the payment request, if yes, proceeding to step S316, otherwise proceeding to step S317.

[0122] Step S316, save the order information to the payment cache again, and mark the order information as unpaid, and enter step S303.

[0123] Step S317, a response message indicating successful payment is returned to the user terminal, and the second order information that is successfully responded to in the acquiring cache is deleted. It should be understood that the specific implementation process of the above steps has been described in detail above and will not be repeated here.

[0124] Through the above method, when an exception occurs in the interface of the ticket supply system, the user's order information can be saved in the acquiring cache. Then, when the interface of the ticket supply system returns to normal, the order request can continue to be sent to the ticket supply system according to the order information in the acquiring cache. There is no need for the user to repeatedly initiate order requests, which can improve order processing efficiency.

[0125] Based on the same inventive concept, Figure 4The embodiment of the present disclosure further provides an order processing device 400, which can be a part or all of an electronic device through hardware, software, or a combination of both, including:

[0126] Determination module 401, used to determine that the interface of the ticketing supply system is abnormal;

[0127] A saving module 402, configured to save order information used to initiate a request to the ticket supply system into an acquiring cache;

[0128] The sending module 403 is used to send a request to the ticket supply system according to the order information in the acquiring buffer when the interface of the ticket supply system returns to normal.

[0129] Optionally, the device 400 further includes:

[0130] A request sending module, used for sending a simulated order request to the ticket supply system;

[0131] The interface determination module is used to determine that the interface of the ticket supply system is restored to normal when the response of the ticket supply system to the simulated order request meets a preset condition.

[0132] Optionally, the preset conditions include:

[0133] The ticket supply system responds to the simulated order request successfully for a preset number of consecutive times; or,

[0134] The response of the ticket supply system to the simulated order request is failure, and the failure type is not an interface exception type.

[0135] Optionally, the sending module 403 is used to:

[0136] Determine the order status of the order information in the acquiring cache, wherein the order status of each order information is an unordered state or an unpaid state;

[0137] According to the order status, an order request or a payment request is sent to the ticket supply system for each order information.

[0138] Optionally, the sending module 403 is used to:

[0139] For the order information in the acquiring cache that is in an unordered state, sending an order request to the order interface of the ticket supply system;

[0140] If a successful order response from the ticket supply system is received, a payment request is sent to a payment interface of the ticket supply system;

[0141] If an interface exception occurs again in the ticket supply system before the ticket supply system responds to the payment request, the order information is saved again in the acquiring cache, and the order information is marked as unpaid.

[0142] Optionally, the ticketing supply system supports idempotency verification, and the sending module 403 is used to:

[0143] Determine whether there are multiple order information with the same order number and in different order statuses in the acquiring cache;

[0144] If there is first order information in an unordered state and second order information in an unpaid state in the acquiring cache, sending a request to the order interface of the ticket supply system according to the first order information in the unordered state, wherein the first order information and the second order information have the same order number;

[0145] After the order is successfully placed, a request is sent to the payment interface of the ticket supply system according to the second order information in an unpaid state.

[0146] Optionally, the device 400 further includes:

[0147] A first deleting module, configured to delete the order information in the acquiring cache when the ticketing supply system responds successfully to the order information; or

[0148] The second deleting module is configured to delete the order information in the acquiring buffer when no response to the order information from the ticket supply system is received within a preset period of time.

[0149] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0150] By using any of the above-mentioned order processing devices, when an abnormality occurs in the interface of the ticket supply system, the user's order information can be saved in the acquiring cache. Then, when the interface of the ticket supply system returns to normal, the order request can continue to be sent to the ticket supply system according to the order information in the acquiring cache. There is no need for the user to repeatedly initiate order requests, thereby improving order processing efficiency.

[0151] Based on the same inventive concept, the present disclosure also provides an electronic device, including:

[0152] a memory having a computer program stored thereon;

[0153] A processor is used to execute the computer program in the memory to implement the steps of any of the above order processing methods.

[0154] In one possible approach, the block diagram of the electronic device may be as follows: Figure 5 See Figure 5 , the electronic device 500 may be provided as a server. Figure 5 The electronic device 500 includes a processor 522, which may be one or more, and a memory 532 for storing a computer program executable by the processor 522. The computer program stored in the memory 532 may include one or more modules, each corresponding to a set of instructions. In addition, the processor 522 may be configured to execute the computer program to perform the above-mentioned order processing method.

[0155] In addition, the electronic device 500 may further include a power supply component 526 and a communication component 550, wherein the power supply component 526 may be configured to perform power management of the electronic device 500, and the communication component 550 may be configured to implement communication, such as wired or wireless communication, of the electronic device 500. In addition, the electronic device 500 may further include an input / output (I / O) interface 558. The electronic device 500 may operate based on an operating system stored in the memory 532, such as Windows Server™, Mac OSX™, Unix™, Linux™, etc.

[0156] In another exemplary embodiment, a computer-readable storage medium including program instructions is also provided, and when the program instructions are executed by a processor, the steps of the above-mentioned order processing method are implemented. For example, the computer-readable storage medium can be the above-mentioned memory 532 including program instructions, and the above-mentioned program instructions can be executed by the processor 522 of the electronic device 500 to complete the above-mentioned order processing method.

[0157] The preferred embodiments of the present disclosure are described in detail above in conjunction with the accompanying drawings; however, the present disclosure is not limited to the specific details in the above embodiments. Within the technical concept of the present disclosure, a variety of simple modifications can be made to the technical solution of the present disclosure, and these simple modifications all fall within the protection scope of the present disclosure.

[0158] It should also be noted that the various specific technical features described in the above specific embodiments can be combined in any suitable manner without contradiction. In order to avoid unnecessary repetition, the present disclosure will not further describe various possible combinations.

[0159] In addition, various embodiments of the present disclosure may be arbitrarily combined, and as long as they do not violate the concept of the present disclosure, they should also be regarded as the contents disclosed by the present disclosure.

Claims

1. An order processing method, characterized in that: The method comprises: Identify interface anomalies with the ticketing provisioning system; Saving order information used to initiate a request to the ticketing provisioning system in an acquiring cache; If the interface of the ticket supply system returns to normal, sending a request to the ticket supply system according to the order information in the acquiring buffer; The method further comprises: sending a simulated order request to the ticket provisioning system; If the response of the ticket supply system to the simulated order request meets a preset condition, determining that the interface of the ticket supply system has returned to normal; The preset conditions include: The ticket supply system responds to the simulated order request successfully for a preset number of consecutive times; or, The response of the ticket supply system to the simulated order request is failure, and the failure type is not an interface exception type.

2. The method according to claim 1, characterized in that: The sending a request to the ticket supply system according to the order information in the acquiring buffer comprises: Determine the order status of the order information in the acquiring cache, wherein the order status of each order information is an unordered state or an unpaid state; According to the order status, an order request or a payment request is sent to the ticket supply system for each order information.

3. The method according to claim 1, characterized in that The sending a request to the ticket supply system according to the order information in the acquiring buffer comprises: For the order information in the acquiring cache that is in an unordered state, sending an order request to the order interface of the ticket supply system; If a successful order response from the ticket supply system is received, a payment request is sent to a payment interface of the ticket supply system; If an interface exception occurs again in the ticket supply system before the ticket supply system responds to the payment request, the order information is saved again in the acquiring cache, and the order information is marked as unpaid.

4. The method according to claim 1, characterized in that: The ticket supply system supports idempotence verification, and sending a request to the ticket supply system according to the order information in the acquiring cache includes: Determine whether there are multiple order information with the same order number and in different order statuses in the acquiring cache; If there is first order information in an unordered state and second order information in an unpaid state in the acquiring cache, sending a request to the order interface of the ticket supply system according to the first order information in the unordered state, wherein the first order information and the second order information have the same order number; After the order is successfully placed, a request is sent to the payment interface of the ticket supply system according to the second order information in an unpaid state.

5. The method according to claim 1, characterized in that The method further comprises: If the ticketing supply system responds successfully to the order information, deleting the order information in the acquiring cache; or If no response to the order information from the ticket supply system is received within a preset time period, the order information in the acquiring buffer is deleted.

6. An order processing device, characterized in that: The device comprises: A determination module, used to determine interface anomalies of the ticketing provision system; A saving module, used to save the order information used to initiate a request to the ticket supply system into an acquiring cache; A sending module, configured to send a request to the ticket supply system according to the order information in the acquiring buffer when the interface of the ticket supply system returns to normal; The sending module is further used to send a simulated order request to the ticket supply system, and if the response of the ticket supply system to the simulated order request meets a preset condition, determine that the interface of the ticket supply system has returned to normal; The preset condition includes: the ticket supply system successfully responds to the simulated order request for a preset number of consecutive times; or the ticket supply system fails to respond to the simulated order request, and the failure type is not an interface exception type.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

8. An electronic device, characterized in that: include: a memory having a computer program stored thereon; A processor, configured to execute the computer program in the memory to implement the steps of the method according to any one of claims 1 to 5.

Images