Designated driving service request processing method and device, computer equipment and storage medium

Abstract

The invention relates to a designated driver service request processing method and device, computer equipment and a storage medium. The method comprises the following steps: in response to a received current request sent by a designated driver service request queue, determining a target request type according to the current request; the designated driving service request queue comprises a new request sub-queue, a detection retry request sub-queue and a step retry request sub-queue; the target request type is the request type of the current request; the request type comprises a new request, a detection retry request or a step retry request; in response to the fact that the target request type is a new request or a stepped retry request, obtaining a historical request processing success rate; the historical request processing success rate is the processing success rate of each historical request in the previous preset first time window; and in response to the situation that the historical request processing success rate is smaller than a first success rate threshold, intercepting the current request, updating the target request type as a detection retry request, and transferring and storing the current request to a detection retry request subqueue. By adopting the method, the efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, computer equipment, and storage medium for processing chauffeur service requests. Background Technology

[0002] In chauffeur services, due to actual business needs, chauffeur platforms frequently need to interact with third-party systems. These include interactions with insurance, invoice, and payment institutions. Instability of these third-party systems is a common problem, affecting the availability of the chauffeur platform's services and, in severe cases, even causing system crashes and rendering the platform unable to provide stable services.

[0003] However, traditional methods of processing chauffeur service requests suffer from inefficiency and wasted resources. Summary of the Invention

[0004] Therefore, it is necessary to provide a method, apparatus, computer equipment, and storage medium for processing chauffeur service requests that can improve efficiency and avoid wasting resources, in order to address the aforementioned technical problems.

[0005] Firstly, a method for processing chauffeur service requests is provided, the method comprising:

[0006] In response to receiving a current request from the designated driver service request queue, the target request type is determined based on the current request. The designated driver service request queue includes a new request sub-queue, a probe retry request sub-queue, and a tiered retry request sub-queue. The target request type is the request type of the current request. The request type includes a new request, a probe retry request, or a tiered retry request.

[0007] In response to a target request type of new request or tiered retry request, obtain the historical request processing success rate; the historical request processing success rate is the processing success rate of each historical request within the previous preset first time window;

[0008] If the success rate of historical request processing is less than the first success rate threshold, the current request is intercepted, the target request type is updated to a probe retry request, and the current request is transferred to the probe retry request subqueue.

[0009] In one embodiment, the method further includes: in response to the historical request processing success rate being greater than a second success rate threshold, sending the current request to a third-party business system and receiving a first processing result of the third-party business system on the current request; the second success rate threshold being greater than the first success rate threshold; in response to the first processing result being successful and the target request type being a new request, removing the current request from the new request sub-queue; in response to the first processing result being successful and the target request type being a tiered retry request, removing the current request from the tiered retry request sub-queue.

[0010] In one embodiment, the method further includes: in response to a first processing result of processing failure, recording the error code and error record information of the current request, and obtaining the first response time of the current request; in response to the first response time being greater than a time threshold, updating the target request type to a tiered retry request, and transferring the current request to a tiered retry request subqueue.

[0011] In one embodiment, the method further includes: responding to a first response time being less than or equal to a time threshold, performing an error severity analysis based on error codes and error log information to obtain a first error severity analysis result; responding to a first error severity analysis result indicating a severe error and the target request type being a new request, updating the target request type to a probe retry request and transferring the current request to a probe retry request subqueue; responding to a first error severity analysis result indicating a severe error and the target request type being a tiered retry request, updating the target request type to a probe retry request and transferring the current request to a probe retry request subqueue; responding to a first error severity analysis result indicating a minor error and the target request type being a new request, updating the target request type to a tiered retry request and transferring the current request to a tiered retry request subqueue; responding to a first error severity analysis result indicating a minor error and the target request type being a tiered retry request, removing the current request from the tiered retry request subqueue and re-storing the current request to the tiered retry request subqueue.

[0012] In one embodiment, the method further includes: in response to a historical request processing success rate being greater than a first success rate threshold and less than a second success rate threshold, randomly determining whether to send the current request to a third-party business system based on the historical request processing success rate; in response to sending the current request to the third-party business system, receiving a second processing result of the current request from the third-party business system; in response to determining that the second processing result is successful and the target request type is a new request, removing the current request from the new request sub-queue; and in response to determining that the second processing result is successful and the target request type is a tiered retry request, removing the current request from the tiered retry request sub-queue.

[0013] In one embodiment, the method further includes:

[0014] In response to the determination that the current request was not sent to the third-party business system, the target request type is updated to a probe retry request, and the current request is transferred to the probe retry request subqueue.

[0015] In one embodiment, the method further includes: in response to the target request type being a probe retry request, sending the current request to a third-party business system and receiving a third processing result from the third-party business system for the current request; in response to the third processing result being successful, removing the current request from the probe retry sub-queue and obtaining the number of requests to be sent in the probe retry sub-queue; detecting whether there are any new probe retry requests in the probe retry sub-queue within the previous preset second time window; in response to the number of requests to be sent being less than the threshold for the number of requests to be sent and no new probe retry requests being added in the probe retry sub-queue within the previous second time window, updating the request type of each probe retry request in the probe retry sub-queue to a tiered retry request, and transferring each probe retry request in the probe retry sub-queue to the tiered retry request sub-queue.

[0016] Secondly, a device for processing chauffeur service requests is provided, characterized in that the device includes a type determination module, a success rate acquisition module, and a success rate acquisition module.

[0017] The type determination module is used to determine the target request type based on the current request received from the chauffeur service request queue. The chauffeur service request queue includes a new request sub-queue, a probe retry request sub-queue, and a tiered retry request sub-queue. The target request type is the request type of the current request. The request type includes a new request, a probe retry request, or a tiered retry request. The success rate acquisition module is used to acquire the historical request processing success rate in response to the target request type being a new request or a tiered retry request. The historical request processing success rate is the processing success rate of each historical request within the previous preset first time window. The request type update module is used to intercept the current request, update the target request type to a probe retry request, and transfer the current request to the probe retry request sub-queue in response to the historical request processing success rate being less than a first success rate threshold.

[0018] Thirdly, a computer device is provided, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described in the above method embodiments.

[0019] Fourthly, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of any of the methods described in the above method embodiments.

[0020] The aforementioned method, apparatus, computer equipment, and storage medium for processing chauffeur service requests, in response to receiving a current request from the chauffeur service request queue, determine the target request type based on the current request; the chauffeur service request queue includes a new request sub-queue, a probe retry request sub-queue, and a tiered retry request sub-queue; the target request type is the request type of the current request; the request type includes a new request, a probe retry request, or a tiered retry request; then, in response to the target request type being a new request or a tiered retry request, obtain the historical request processing success rate; the historical request processing success rate is the processing success rate of each historical request within the previous preset first time window; next, in response to the historical request processing success rate being less than a first success rate threshold, intercept the current request, update the target request type to a probe retry request, and transfer the current request to the probe retry request sub-queue, thereby timely completing the adjustment of the request type, realizing request classification processing, ensuring the success rate of request processing, avoiding the need for manual intervention and increasing labor costs, and also avoiding the waste of server resources caused by continuous automatic retries of requests. Attached Figure Description

[0021] Figure 1 This is an application environment diagram of a method for processing chauffeur service requests in one embodiment;

[0022] Figure 2 This is a first flowchart illustrating a method for processing chauffeur service requests in one embodiment;

[0023] Figure 3 This is a second flowchart illustrating a method for processing chauffeur service requests in one embodiment;

[0024] Figure 4 This is a schematic diagram of the third process of a method for processing chauffeur service requests in one embodiment;

[0025] Figure 5 This is a schematic diagram of the fourth process of a method for processing chauffeur service requests in one embodiment;

[0026] Figure 6 This is a structural block diagram of a device for processing chauffeur service requests in one embodiment;

[0027] Figure 7 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0029] To facilitate understanding of this application, a more complete description will be provided below with reference to the accompanying drawings, which illustrate embodiments of the present application. However, the present application can be implemented in many different forms and is not limited to the embodiments described herein. Rather, these embodiments are provided so that the disclosure of this application will be thorough and complete.

[0030] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application.

[0031] It is understood that the terms "first," "second," etc., used herein may be used to describe various elements, but these elements are not limited by these terms. These terms are only used to distinguish one element from another. For example, without departing from the scope of this application, a first resistor may be referred to as a second resistor, and similarly, a second resistor may be referred to as a first resistor. Both the first resistor and the second resistor are resistors, but they are not the same resistor.

[0032] It is understood that the term "connection" in the following embodiments should be understood as "electrical connection," "communication connection," etc., if the connected circuits, modules, units, etc., have electrical signal or data transmission with each other.

[0033] When used herein, the singular forms of “a,” “an,” and “the” may also include the plural forms unless the context clearly indicates otherwise. It should also be understood that the terms “comprising,” “including,” or “having,” etc., specify the presence of the stated feature, whole, step, operation, component, part, or combination thereof, but do not preclude the possibility of the presence or addition of one or more other features, wholes, steps, operations, components, parts, or combinations thereof.

[0034] The method for processing chauffeur service requests provided in this application can be applied to, for example, Figure 1 In the application environment shown, terminal 102 communicates with server 104 via a network. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. Server 104 can be a standalone server or a server cluster consisting of multiple servers. It is understood that server 104 is configured with a ride-hailing platform; the ride-hailing platform can be, but is not limited to, a SaaS platform.

[0035] In one embodiment, such as Figure 2 As shown, a method for processing chauffeur service requests is provided, which is applied to... Figure 1Taking server 104 as an example, the explanation includes the following steps 201 to 203.

[0036] Step 201: In response to receiving the current request from the designated driver service request queue, determine the target request type based on the current request.

[0037] The designated driver service request queue includes a new request sub-queue, a probe retry request sub-queue, and a tiered retry request sub-queue. The target request type is the request type of the current request; the request type includes a new request, a probe retry request, or a tiered retry request. Specifically, server 104 responds to the current request sent by the designated driver service request queue and determines the target request type based on the current request.

[0038] Understandably, each probe retry request in the probe retry request subqueue sends one probe retry request to server 104 each time, based on the event type. The tiered retry request subqueue sends each tiered retry request to server 104 sequentially according to a preset request sending strategy. In a specific example, the request sending strategy could be to send the first tiered retry request, wait 1 minute before sending the next tiered retry request, wait 2 minutes before sending the next tiered retry request after that. This is just a specific example; in actual applications, it can be flexibly set according to user needs, and no restrictions are imposed here.

[0039] Step 202: In response to a target request type of either a new request or a tiered retry request, obtain the historical request processing success rate.

[0040] The historical request processing success rate is the processing success rate of all historical requests within the previous preset first time window. Specifically, server 104 responds to a target request type of either a new request or a tiered retry request by obtaining the historical request processing success rate.

[0041] Step 203: In response to the historical request processing success rate being less than the first success rate threshold, the current request is intercepted, the target request type is updated to a probe retry request, and the current request is transferred to the probe retry request subqueue.

[0042] Specifically, server 104 responds when the historical request processing success rate is less than the first success rate threshold and blocks the current request. This indicates that the historical request processing success rate is low at this time. The target request type can be updated to a probe retry request, and the current request can be transferred to the probe retry request sub-queue. This allows for timely adjustment of the request type, ensuring the success rate of request processing, avoiding the need for manual intervention and increasing labor costs, and also avoiding the waste of server resources caused by continuous automatic retries of requests.

[0043] Based on this, the above-mentioned method for processing chauffeur service requests, in response to receiving a current request from the chauffeur service request queue, determines the target request type based on the current request; the chauffeur service request queue includes a new request sub-queue, a probe retry request sub-queue, and a tiered retry request sub-queue; the target request type is the request type of the current request; the request type includes a new request, a probe retry request, or a tiered retry request; then, in response to the target request type being a new request or a tiered retry request, the historical request processing success rate is obtained; the historical request processing success rate is the processing success rate of each historical request within the previous preset first time window; next, in response to the historical request processing success rate being less than a first success rate threshold, the current request is intercepted, the target request type is updated to a probe retry request, and the current request is transferred to the probe retry request sub-queue, thereby timely completing the adjustment of the request type, realizing request classification processing, ensuring the success rate of request processing, avoiding the need for manual intervention and increasing labor costs, and also avoiding the waste of server resources caused by continuous automatic retries of requests.

[0044] In one embodiment, such as Figure 3 As shown, the method further includes steps 301 to 303.

[0045] Step 301: In response to the historical request processing success rate being greater than the second success rate threshold, the current request is sent to the third-party business system, and the first processing result of the third-party business system on the current request is received.

[0046] Step 302: In response to the first processing result being successful and the target request type being a new request, the current request is removed from the new request sub-queue;

[0047] Step 303: In response to the first processing result being successful and the target request type being a tiered retry request, the current request is removed from the tiered retry request subqueue.

[0048] Specifically, the second success rate threshold is greater than the first success rate threshold. In response to a historical request processing success rate greater than the second success rate threshold, server 104 directly sends the current request to the third-party business system and receives the first processing result from the third-party business system. Then, in response to a first processing result indicating successful processing and the target request type being a new request, the current request is removed from the new request sub-queue. In response to a first processing result indicating successful processing and the target request type being a tiered retry request, the current request is removed from the tiered retry request sub-queue. This improves request processing efficiency, ensures a high success rate, and avoids the waste of server resources caused by continuous automatic retries.

[0049] In this embodiment, in response to the historical request processing success rate being greater than the second success rate threshold, the current request is directly sent to the third-party business system, and the first processing result of the third-party business system on the current request is received; then, in response to the first processing result being successful and the target request type being a new request, the current request is removed from the new request sub-queue; in response to the first processing result being successful and the target request type being a tiered retry request, the current request is removed from the tiered retry request sub-queue, thereby improving the efficiency of request processing, ensuring the success rate of request processing, and avoiding the waste of server resources caused by continuous automatic retries of requests.

[0050] In one embodiment, such as Figure 3 As shown, the method further includes steps 304 to 305.

[0051] Step 304: In response to the first processing result being processing failure, record the error code and error log information of the current request, and obtain the first response time of the current request;

[0052] Step 305: In response to the first response time being greater than the time threshold, the target request type is updated to a tiered retry request, and the current request is transferred to the tiered retry request sub-queue.

[0053] Specifically, in response to the first processing result of server 104 being processing failure, server 104 records the error code and error log information of the current request and obtains the first response time of the current request. Then, in response to the first response time being greater than the time threshold, server 104 updates the target request type to a tiered retry request and transfers the current request to the tiered retry request sub-queue to ensure the success rate of request processing and avoid the waste of server resources caused by continuous automatic retries of requests.

[0054] In this embodiment, in response to the first processing result being processing failure, the error code and error log information of the current request are recorded, and the first response time of the current request is obtained; then, in response to the first response time being greater than the time threshold, the target request type is updated to a tiered retry request, and the current request is transferred to the tiered retry request sub-queue to ensure the success rate of request processing and avoid the waste of server resources caused by continuous automatic retry of requests.

[0055] In one embodiment, such as Figure 3 As shown, the method further includes steps 306 to 310.

[0056] Step 306: In response to the first response time being less than or equal to the time threshold, an error severity analysis is performed based on the error code and error record information to obtain the first error severity analysis result;

[0057] Step 307: In response to the first error severity analysis result being a severe error severity and the target request type being a new request, the target request type is updated to a probe retry request, and the current request is transferred to the probe retry request subqueue.

[0058] Step 308: In response to the first error severity analysis result being a severe error severity and the target request type being a tiered retry request, the target request type is updated to a probe retry request, and the current request is transferred to the probe retry request subqueue.

[0059] Step 309: In response to the first error level analysis result being a minor error level and the target request type being a new request, update the target request type to a tiered retry request and transfer the current request to the tiered retry request subqueue.

[0060] Step 310: In response to the first error level analysis result being a minor error level and the target request type being a tiered retry request, the current request is removed from the tiered retry request subqueue and then stored back into the tiered retry request subqueue.

[0061] Specifically, in response to a first response time less than or equal to a time threshold, server 104 performs an error severity analysis based on the error code and error log information to obtain a first error severity analysis result. Then, in response to a first error severity analysis result indicating a severe error and the target request type being a new request, indicating a severe error, the target request type is updated to a probe retry request, and the current request is moved to the probe retry request sub-queue for manual intervention in probe retry. Next, in response to a first error severity analysis result indicating a severe error and the target request type being a tiered retry request, indicating a severe error, the target request type is... The request type is updated to a probe retry request, and the current request is transferred to the probe retry request subqueue to enable manual intervention in probe retry. Furthermore, in response to the first error level analysis result being a minor error and the target request type being a new request, the target request type is updated to a tiered retry request, and the current request is transferred to the tiered retry request subqueue. Finally, in response to the first error level analysis result being a minor error and the target request type being a tiered retry request, the current request is removed from the tiered retry request subqueue and then re-stored in the tiered retry request subqueue. This ensures the success rate of request processing and avoids the waste of server resources caused by continuous automatic retries.

[0062] In this embodiment, in response to a first response time less than or equal to a time threshold, an error severity analysis is performed based on the error code and error log information to obtain a first error severity analysis result. Then, in response to the first error severity analysis result indicating a severe error and the target request type being a new request, indicating a severe error in the current request, the target request type is updated to a probe retry request, and the current request is transferred to the probe retry request sub-queue to enable manual intervention in probe retry. Next, in response to the first error severity analysis result indicating a severe error and the target request type being a tiered retry request, indicating a severe error in the current request, the target request type is further... To detect retry requests, the current request is transferred to the detection retry request sub-queue to enable manual intervention in retry detection. Furthermore, in response to the first error level analysis result being a minor error and the target request type being a new request, the target request type is updated to a tiered retry request, and the current request is transferred to the tiered retry request sub-queue. Finally, in response to the first error level analysis result being a minor error and the target request type being a tiered retry request, the current request is removed from the tiered retry request sub-queue and then re-stored in the tiered retry request sub-queue. This ensures a high success rate for request processing and avoids the waste of server resources caused by continuous automatic retries.

[0063] In one embodiment, such as Figure 4 As shown, the method further includes steps 401 to 40,4.

[0064] Step 401: In response to the historical request processing success rate being greater than the first success rate threshold and less than the second success rate threshold, randomly determine whether to send the current request to the third-party business system based on the historical request processing success rate.

[0065] Step 402: In response to sending the current request to the third-party business system, receive the second processing result of the current request from the third-party business system;

[0066] Step 403: In response to determining that the second processing result is successful and the target request type is a new request, the current request is removed from the new request subqueue;

[0067] Step 404: In response to determining that the second processing result is successful and the target request type is a tiered retry request, the current request is removed from the tiered retry request subqueue.

[0068] Specifically, in response to a historical request processing success rate greater than a first success rate threshold and less than a second success rate threshold, server 104 randomly determines whether to send the current request to the third-party business system based on the historical request processing success rate. Then, in response to sending the current request to the third-party business system, server 104 receives the second processing result of the third-party business system for the current request. Next, in response to determining that the second processing result is successful and the target request type is a new request, server 104 removes the current request from the new request sub-queue. Finally, in response to determining that the second processing result is successful and the target request type is a tiered retry request, server 104 removes the current request from the tiered retry request sub-queue. This ensures the success rate of request processing and avoids the waste of server resources caused by continuous automatic retries.

[0069] In a specific example, the method further includes:

[0070] If the second processing result is processing failure, record the error code and error log information of the current request, and obtain the second response time of the current request;

[0071] If the second response time exceeds the time threshold, the target request type is updated to a tiered retry request, and the current request is transferred to the tiered retry request subqueue.

[0072] If the second response time is less than or equal to the time threshold, an error severity analysis is performed based on the error code and error log information to obtain the second error severity analysis result;

[0073] In response to the second error severity analysis result being a severe error and the target request type being a new request, the target request type is updated to a probe retry request, and the current request is transferred to the probe retry request subqueue;

[0074] In response to the second error severity analysis result being a severe error severity and the target request type being a tiered retry request, the target request type is updated to a probe retry request, and the current request is transferred to the probe retry request subqueue.

[0075] In response to the second error level analysis result being a minor error level and the target request type being a new request, the target request type is updated to a tiered retry request, and the current request is transferred to the tiered retry request subqueue.

[0076] If the second error level analysis result indicates a minor error and the target request type is a tiered retry request, the current request is removed from the tiered retry request subqueue and then re-stored into the tiered retry request subqueue. The above is merely a specific example; in actual applications, it should be flexibly configured according to user needs, and no restrictions are imposed here.

[0077] In this embodiment, in response to the historical request processing success rate being greater than a first success rate threshold and less than a second success rate threshold, it is randomly determined whether to send the current request to the third-party business system based on the historical request processing success rate. Then, in response to sending the current request to the third-party business system, the second processing result of the third-party business system on the current request is received. Next, in response to determining that the second processing result is successful and the target request type is a new request, the current request is removed from the new request sub-queue. Finally, in response to determining that the second processing result is successful and the target request type is a tiered retry request, the current request is removed from the tiered retry request sub-queue. This ensures the success rate of request processing and avoids the waste of server resources caused by continuous automatic retries of requests.

[0078] In one embodiment, such as Figure 4 As shown, the method further includes step 405.

[0079] Step 405: In response to the determination that the current request was not sent to the third-party business system, the target request type is updated to a probe retry request, and the current request is transferred to the probe retry request subqueue.

[0080] Specifically, in response to the determination that the current request has not been sent to the third-party business system, server 104 updates the target request type to a probe retry request and transfers the current request to the probe retry request sub-queue to ensure the success rate of request processing and avoid the waste of server resources caused by continuous automatic retries of requests.

[0081] In this embodiment, in response to determining that the current request has not been sent to the third-party business system, the target request type is updated to a probe retry request, and the current request is transferred to the probe retry request sub-queue to ensure the success rate of request processing and avoid the waste of server resources caused by continuous automatic retries of requests.

[0082] In one embodiment, such as Figure 5 As shown, the method further includes steps 501 to 504.

[0083] Step 501: In response to the target request type being a probe retry request, the current request is sent to the third-party business system, and the third processing result of the third-party business system on the current request is received.

[0084] Step 502: In response to the third processing result being successful, remove the current request from the probe retry subqueue and obtain the number of pending requests in the probe retry subqueue.

[0085] Step 503: Check if there are any new probe retry requests in the probe retry subqueue within the previous preset second time window;

[0086] Step 504: In response to the fact that the number of requests to be sent is less than the threshold for the number of requests to be sent and there are no new probe retry requests in the probe retry subqueue in the previous second time window, update the request type of each probe retry request in the probe retry subqueue to a tiered retry request, and transfer each probe retry request in the probe retry subqueue to the tiered retry request subqueue.

[0087] Specifically, in response to a target request type of probe retry request, server 104 sends the current request to the third-party business system and receives the third processing result of the third-party business system for the current request. Then, in response to the third processing result being successful, the current request is removed from the probe retry sub-queue, and the number of requests to be sent in the probe retry sub-queue is obtained. Next, it checks whether there are any new probe retry requests in the probe retry sub-queue within the previous preset second time window. Finally, in response to the number of requests to be sent being less than the threshold for the number of requests to be sent and no new probe retry requests being added in the probe retry sub-queue within the previous second time window, the request type of each probe retry request in the probe retry sub-queue is updated to a tiered retry request, and each probe retry request in the probe retry sub-queue is transferred to the tiered retry request sub-queue. This improves request processing efficiency, ensures the success rate of request processing, and avoids the waste of server resources caused by continuous automatic retries of requests.

[0088] In a specific example, the method further includes:

[0089] If the third processing result is processing failure, record the error code and error log information of the current request, and obtain the third response time of the current request;

[0090] If the third response time exceeds the time threshold, the target request type is updated to a tiered retry request, and the current request is transferred to the tiered retry request subqueue.

[0091] If the third response time is less than or equal to the time threshold, an error severity analysis is performed based on the error code and error log information to obtain the first error severity analysis result.

[0092] In response to the third error severity analysis result being a severe error and the target request type being a new request, the target request type is updated to a probe retry request, and the current request is transferred to the probe retry request subqueue;

[0093] In response to the first error severity analysis result being a severe error and the target request type being a tiered retry request, the target request type is updated to a probe retry request, and the current request is transferred to the probe retry request subqueue.

[0094] In response to the third error level analysis result being a minor error level and the target request type being a new request, the target request type is updated to a tiered retry request, and the current request is transferred to the tiered retry request subqueue.

[0095] If the third error level analysis result indicates a minor error and the target request type is a tiered retry request, the current request is removed from the tiered retry request subqueue and then re-stored into the tiered retry request subqueue. The above is merely a specific example; in actual applications, it should be flexibly configured according to user needs, and no restrictions are imposed here.

[0096] In this embodiment, in response to the target request type being a probe retry request, the current request is sent to a third-party business system, and the third processing result of the third-party business system on the current request is received. Then, in response to the third processing result being successful, the current request is removed from the probe retry sub-queue, and the number of requests to be sent in the probe retry sub-queue is obtained. Next, it is checked whether there are any new probe retry requests in the probe retry sub-queue within the previous preset second time window. Finally, in response to the number of requests to be sent being less than the threshold for the number of requests to be sent and no new probe retry requests being added in the probe retry sub-queue within the previous second time window, the request type of each probe retry request in the probe retry sub-queue is updated to a tiered retry request, and each probe retry request in the probe retry sub-queue is transferred to the tiered retry request sub-queue. This improves request processing efficiency, ensures the success rate of request processing, and avoids the waste of server resources caused by continuous automatic retries of requests.

[0097] In a specific example, the method further includes:

[0098] Get the request count of the new request subqueue, probe the request count of the retry request subqueue, and the request count of the tiered retry request subqueue;

[0099] If the number of requests in the new request sub-queue exceeds the first request threshold, output a new request backlog warning message;

[0100] When the number of requests in the probe retry subqueue exceeds the second request threshold, a probe retry backlog warning is output.

[0101] When the number of requests in the tiered retry subqueue exceeds the third request threshold, a tiered retry backlog warning is output. The above is just a specific example. In actual applications, the settings can be flexibly configured according to user needs, and no restrictions are imposed here.

[0102] It should be understood that, although Figure 2-5The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2-5 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0103] Secondly, such as Figure 6 As shown, a device for processing chauffeur service requests is provided, characterized in that the device includes a type determination module 610, a success rate acquisition module 620, and a request type update module 630.

[0104] The type determination module 610 is used to determine the target request type based on the current request received from the chauffeur service request queue. The chauffeur service request queue includes a new request sub-queue, a probe retry request sub-queue, and a tiered retry request sub-queue. The target request type is the request type of the current request. The request type includes a new request, a probe retry request, or a tiered retry request. The success rate acquisition module 620 is used to acquire the historical request processing success rate in response to the target request type being a new request or a tiered retry request. The historical request processing success rate is the processing success rate of each historical request within the previous preset first time window. The request type update module 630 is used to intercept the current request, update the target request type to a probe retry request, and transfer the current request to the probe retry request sub-queue in response to the historical request processing success rate being less than a first success rate threshold.

[0105] In one embodiment, the method further includes a request type update module 630, which, in response to a historical request processing success rate greater than a second success rate threshold, sends the current request to a third-party business system and receives a first processing result from the third-party business system for the current request; the second success rate threshold is greater than the first success rate threshold; the request type update module 630, in response to a first processing result indicating successful processing and a target request type of new request, removes the current request from the new request sub-queue; and the request type update module 630, in response to a first processing result indicating successful processing and a target request type of tiered retry request, removes the current request from the tiered retry request sub-queue.

[0106] In one embodiment, the request type update module 630 is used to record the error code and error record information of the current request in response to the first processing result being processing failure, and to obtain the first response time of the current request; the request type update module 630 is used to update the target request type to a tiered retry request in response to the first response time being greater than a time threshold, and to transfer the current request to the tiered retry request sub-queue.

[0107] In one embodiment, the request type update module 630 is configured to, in response to a first response time being less than or equal to a time threshold, perform an error severity analysis based on the error code and error record information to obtain a first error severity analysis result; the request type update module 630 is configured to, in response to a first error severity analysis result indicating a severe error and the target request type being a new request, update the target request type to a probe retry request and transfer the current request to the probe retry request subqueue; the request type update module 630 is configured to, in response to a first error severity analysis result indicating a severe error and the target request type being a stepped retry request. The request type update module 630 is used to update the target request type to a probe retry request and transfer the current request to the probe retry request subqueue in response to the first error level analysis result being a minor error level and the target request type being a new request. The current request is then transferred to the step retry request subqueue. The request type update module 630 is also used to remove the current request from the step retry request subqueue and re-store the current request to the step retry request subqueue in response to the first error level analysis result being a minor error level and the target request type being a step retry request.

[0108] In one embodiment, the request type update module 630 is configured to, in response to a historical request processing success rate greater than a first success rate threshold and less than a second success rate threshold, randomly determine whether to send the current request to a third-party business system based on the historical request processing success rate; the request type update module 630 is configured to, in response to sending the current request to the third-party business system, receive a second processing result of the current request from the third-party business system; the request type update module 630 is configured to, in response to determining that the second processing result is successful and the target request type is a new request, remove the current request from the new request sub-queue; the request type update module 630 is configured to, in response to determining that the second processing result is successful and the target request type is a tiered retry request, remove the current request from the tiered retry request sub-queue.

[0109] In one embodiment, the request type update module 630 is used to update the target request type to a probe retry request in response to determining that the current request has not been sent to the third-party business system, and to transfer the current request to the probe retry request subqueue.

[0110] In one embodiment, the request type update module 630 is configured to, in response to the target request type being a probe retry request, send the current request to a third-party business system and receive the third processing result of the third-party business system on the current request; in response to the third processing result being successful, remove the current request from the probe retry sub-queue and obtain the number of requests to be sent in the probe retry sub-queue; the request type update module 630 is configured to detect whether there are any new probe retry requests in the probe retry sub-queue within the previous preset second time window; in response to the number of requests to be sent being less than the threshold for the number of requests to be sent and no new probe retry requests being added in the probe retry sub-queue within the previous second time window, update the request type of each probe retry request in the probe retry sub-queue to a tiered retry request and transfer each probe retry request in the probe retry sub-queue to the tiered retry request sub-queue.

[0111] Specific limitations regarding the processing device for chauffeur service requests can be found in the above description of the processing method for chauffeur service requests, and will not be repeated here. Each module in the aforementioned chauffeur service request processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0112] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The database stores currently requested data. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements a method for processing chauffeur service requests.

[0113] Those skilled in the art will understand that Figure 7 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0114] Thirdly, a computer device is provided, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described in the above method embodiments.

[0115] Fourthly, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of any of the methods described in the above method embodiments.

[0116] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0117] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0118] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for processing a chauffeur service request, the method comprising: In response to receiving a current request from the designated driver service request queue, determine the target request type based on the current request; The designated driver service request queue includes a new request sub-queue, a probe retry request sub-queue, and a tiered retry request sub-queue; the target request type is the request type of the current request; the request type includes a new request, a probe retry request, or a tiered retry request. In response to the target request type being either the new request or the tiered retry request, the historical request processing success rate is obtained; the historical request processing success rate is the processing success rate of each historical request within the previous preset first time window. In response to the historical request processing success rate being less than a first success rate threshold, the current request is intercepted, the target request type is updated to the probe retry request, and the current request is transferred to the probe retry request sub-queue.

2. The method according to claim 1, characterized in that, The method further includes: In response to the historical request processing success rate being greater than a second success rate threshold, the current request is sent to a third-party business system, and the first processing result of the current request from the third-party business system is received; the second success rate threshold is greater than the first success rate threshold. In response to the first processing result being successful and the target request type being the new request, the current request is removed from the new request subqueue; In response to the first processing result being successful and the target request type being the tiered retry request, the current request is removed from the tiered retry request subqueue.

3. The method according to claim 2, characterized in that, The method further includes: In response to the first processing result being processing failure, the error code and error log information of the current request are recorded, and the first response time of the current request is obtained; In response to the first response time being greater than the time threshold, the target request type is updated to the tiered retry request, and the current request is transferred to the tiered retry request sub-queue.

4. The method according to claim 3, characterized in that, The method further includes: In response to the first response time being less than or equal to the time threshold, an error severity analysis is performed based on the error code and the error record information to obtain a first error severity analysis result; In response to the first error severity analysis result being a severe error severity and the target request type being the new request, the target request type is updated to the probe retry request, and the current request is transferred to the probe retry request subqueue; In response to the first error severity analysis result being the severity of the error and the target request type being the tiered retry request, the target request type is updated to the probe retry request, and the current request is transferred to the probe retry request subqueue. In response to the first error severity analysis result being a minor error severity and the target request type being the new request, the target request type is updated to the tiered retry request, and the current request is transferred to the tiered retry request subqueue. In response to the first error severity analysis result being the minor error severity and the target request type being the tiered retry request, the current request is removed from the tiered retry request subqueue and then re-stored into the tiered retry request subqueue.

5. The method according to claim 2, characterized in that, The method further includes: In response to the historical request processing success rate being greater than the first success rate threshold and less than the second success rate threshold, it is randomly determined whether to send the current request to the third-party business system based on the historical request processing success rate. In response to sending the current request to the third-party business system, the system receives a second processing result from the third-party business system regarding the current request; In response to determining that the second processing result is successful and the target request type is the new request, the current request is removed from the new request subqueue; In response to determining that the second processing result is successful and the target request type is the tiered retry request, the current request is removed from the tiered retry request subqueue.

6. The method according to claim 5, characterized in that, The method further includes: In response to the determination that the current request was not sent to the third-party business system, the target request type is updated to the probe retry request, and the current request is transferred to the probe retry request subqueue.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: In response to the target request type being the probe retry request, the current request is sent to the third-party business system, and the third processing result of the third-party business system on the current request is received; In response to the third processing result being successful, the current request is removed from the probe retry subqueue, and the number of pending requests in the probe retry subqueue is obtained; Check if there are any new probe retry requests in the probe retry subqueue within the previous preset second time window; In response to the fact that the number of requests to be sent is less than the threshold for the number of requests to be sent and there is no new probe retry request in the probe retry subqueue in the previous second time window, the request type of each probe retry request in the probe retry subqueue is updated to the tiered retry request, and each probe retry request in the probe retry subqueue is transferred to the tiered retry request subqueue.

8. A device for processing chauffeur service requests, characterized in that, The device includes: The type determination module is used to respond to a current request sent by the designated driver service request queue and determine the target request type based on the current request; the designated driver service request queue includes a new request sub-queue, a probe retry request sub-queue, and a tiered retry request sub-queue; the target request type is the request type of the current request; the request type includes a new request, a probe retry request, or a tiered retry request; The success rate acquisition module is used to acquire the historical request processing success rate in response to the target request type being the new request or the tiered retry request; the historical request processing success rate is the processing success rate of each historical request within the previous preset first time window; The request type update module is used to intercept the current request in response to the historical request processing success rate being less than a first success rate threshold, update the target request type to the probe retry request, and transfer the current request to the probe retry request sub-queue.

9. 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 computer program, it implements the steps of the method according to any one of claims 1 to 7.

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

Images