Degradation method for avoiding incapability of placing order

Abstract

The invention discloses a degradation method for avoiding incapability of placing an order. The method comprises the following steps: step 1, carrying out a big data timing task; step 2, performing degradation estimation on switch control; s21, receiving an estimation request sent by the passenger App; s22, judging whether a degradation switch is turned on or not; if so, executing the original normal pre-estimation logic and returning; if the LBS interface is opened, starting to execute the estimation logic of degradation: 1) calling the LBS interface to obtain the travelled distance and duration from the get-on address to the get-off address; 2) organizing request parameters for requesting the big data interface; when a downstream charging application pre-estimation interface cannot be called or the pre-estimation interface has large-area abnormity / failure, after a switch is manually turned on, a big data interface is called in a degradation manner to query the cost required by historical orders in an approximate distance of a city range, and the cost is returned as a pre-estimation price, so that a problematic interface is bypassed; the business process cannot be hindered, and the passenger can continue to place an order; and the passenger experience is improved.

Description

Technical Field

[0001] The present invention belongs to the technical field of online car-hailing operation, and specifically relates to a method for avoiding downgrade due to inability to place an order. Background Art

[0002] Since online car-hailing involves many businesses, according to the software design principles, business interfaces are distributed in multiple application systems, and multiple application systems constitute a complete interface call chain of a certain business line. In the online car-hailing scenario, the process of passengers booking a car is generally as follows: the passenger enters the boarding and alighting location on the App -> the back-end server estimates the price -> the passenger confirms the car call -> the back-end server places the order. The purpose of the estimate is to show the passenger the approximate cost of the trip. The cost incurred in the actual trip may not be exactly the same as the estimated price, but it is within a certain fluctuation range. The timing diagram is as follows Figure 1 .

[0003] If the estimated interface of the billing application in the first step of the open platform application fails on a large scale (if there are 100,000 calls per minute, of which 60,000 or even more calls return exceptions or failures, the failure rate has reached more than 60%, which can be considered a large-scale failure; there are many possible reasons for the failure, including but not limited to excessive pressure on the billing application, network abnormalities, etc.), the passenger will be unable to confirm the use of the car and thus unable to place an order. In this case, how to return the estimated price to the passenger normally so as not to affect the order has become an urgent problem to be solved. Summary of the invention

[0004] The object of the present invention is to provide a method for avoiding downgrade due to failure to place an order, so as to solve the problems raised in the above background technology.

[0005] To achieve the above object, the present invention provides the following technical solutions: a method for avoiding downgrade due to inability to place an order, step 1: performing a big data timing task;

[0006] S11: Calculate the start and end time of the previous day;

[0007] S12: Paginate and query the orders whose order completion time is within the above start and end time;

[0008] S13: Determine whether the total number of orders queried this time is greater than 0; if so, continue the execution, otherwise end;

[0009] S14: extracting the city code, mileage, duration, vehicle type, service type, and original order price data in the order one by one;

[0010] S15: Save the data in step S14 to the MongoDB database;

[0011] Step 2: switch control degradation estimation;

[0012] S21: receiving an estimation request sent by the passenger App;

[0013] S22: Determine whether the downgrade switch is on; if it is off, execute the original normal estimation logic and return; if it is on, start to execute the downgrade estimation logic: 1) call the LBS interface to obtain the mileage and duration from the pick-up address to the drop-off address;

[0014] 2) Organize the request parameters for requesting the big data interface;

[0015] 3) Request the big data query interface to obtain the latest 10 historical order sets that are closest to the current estimate;

[0016] 4) Determine whether the number of historical order sets obtained in step 3) is greater than 0; if it is greater than 0, continue, otherwise end;

[0017] 5) Find an order from the order set that is closest to the mileage obtained in step 1);

[0018] 6) Obtain the original price of the order obtained in step 5) as the estimated price; and generate priceToken;

[0019] 7) Organize the estimated request return result, and use the mileage and duration obtained in step 1) and the estimated price and priceToken obtained in step 6) as the estimated return result;

[0020] 8) Bind priceToken and estimated return result;

[0021] 9) Output the return result to the passenger APP.

[0022] Preferably, the MongoDB is a database based on distributed file storage, which can store a large amount of data and dynamically expand the storage content.

[0023] Preferably, in step 8), priceToken is used as the key of Redis, the return result of step 7) is used as the Value, and the set command of Redis is called to store it in the cache, which is cached for one hour in order to bind the relationship between priceToken and the estimated return result, and to verify whether it has been estimated before when placing an order.

[0024] Preferably, the scheduled task starts to be executed at 3:00 a.m. every day, and the values ​​of the start and end times of the previous day are calculated to be 00:00:00-23:59:59 respectively.

[0025] Preferably, in step 2), the request parameters include city code, mileage, vehicle type, and service type.

[0026] Compared with the prior art, the beneficial effects of the present invention are: when the estimation interface of the downstream billing application cannot be called or the estimation interface has a large-scale abnormality / failure, after manually turning on the switch, the present invention downgrades and calls the big data interface to query the historical orders of the approximate distance within the city range and returns the required cost as the estimated price, thereby bypassing the problematic interface; it will not hinder the business process, and passengers can continue to place orders; and the passenger experience is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 This is a timing diagram of the traditional online car-hailing process.

[0028] Figure 2 This is a flowchart of the execution of the big data timing task of the present invention.

[0029] Figure 3 The flowchart of the degradation prediction execution of the switch control of the present invention is shown. DETAILED DESCRIPTION

[0030] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0031] See also Figures 1 to 3 ,The present invention provides a technical solution: a method for avoiding downgrade due to inability to place an order, step 1: performing a big data timing task;

[0032] S11: Calculate the start and end time of the previous day;

[0033] S12: Paginate and query the orders whose order completion time is within the above start and end time;

[0034] S13: Determine whether the total number of orders queried this time is greater than 0; if so, continue the execution, otherwise end;

[0035] S14: extracting the city code, mileage, duration, vehicle type, service type, and original order price data in the order one by one;

[0036] S15: Save the data in step S14 to the MongoDB database;

[0037] Step 2: switch control degradation estimation;

[0038] S21: receiving an estimation request sent by the passenger App;

[0039] S22: Determine whether the downgrade switch is on; if it is off, execute the original normal estimation logic and return; if it is on, start to execute the downgrade estimation logic: 1) call the LBS interface to obtain the mileage and duration from the pick-up address to the drop-off address;

[0040] 2) Organize the request parameters for requesting the big data interface;

[0041] 3) Request the big data query interface to obtain the latest 10 historical order sets that are closest to the current estimate;

[0042] 4) Determine whether the number of historical order sets obtained in step 3) is greater than 0; if it is greater than 0, continue, otherwise end;

[0043] 5) Find an order from the order set that is closest to the mileage obtained in step 1);

[0044] 6) Obtain the original price of the order obtained in step 5) as the estimated price; and generate priceToken;

[0045] 7) Organize the estimated request return result, and use the mileage and duration obtained in step 1) and the estimated price and priceToken obtained in step 6) as the estimated return result;

[0046] 8) Bind priceToken and estimated return result;

[0047] 9) Output the return result to the passenger APP.

[0048] In this embodiment, preferably, the MongoDB is a database based on distributed file storage, which can store a large amount of data and dynamically expand the storage content.

[0049] In this embodiment, preferably, in step 8), priceToken is used as the key of Redis, the return result of step 7) is used as the Value, and the set command of Redis is called to store it in the cache, which is cached for one hour in order to bind the relationship between priceToken and the estimated return result, and to verify whether it has been estimated before when placing an order.

[0050] In this embodiment, preferably, the scheduled task starts to execute at 3:00 a.m. every day, and the values ​​of the start and end times of the previous day are calculated to be 00:00:00-23:59:59 respectively.

[0051] In this embodiment, preferably, in step 2), the request parameters include city code, mileage, vehicle type, and service type.

[0052] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for avoiding downgrade due to inability to place an order, characterized in that: Step 1: Perform big data scheduled tasks; S11: Calculate the start and end time of the previous day; S12: Paginate and query the orders whose order completion time is within the above start and end time; S13: Determine whether the total number of orders queried this time is greater than 0; if so, continue the execution, otherwise end; S14: extracting the city code, mileage, duration, vehicle type, service type, and original order price data in the order one by one; S15: Save the data in step S14 to the MongoDB database; Step 2: Switch control degradation estimation; S21: receiving an estimation request sent by the passenger App; S22: Determine whether the downgrade switch is on; if it is off, execute the original normal estimation logic and return; If turned on, the downgrade estimation logic starts to execute: 1) Call the LBS interface to obtain the mileage and duration from the pick-up address to the drop-off address; 2) Organize the request parameters for requesting the big data interface; 3) Request the big data query interface to obtain the latest 10 historical order sets that are closest to the current estimate; 4) Determine whether the number of historical order sets obtained in step 3) is greater than 0; if it is greater than 0, continue, otherwise end; 5) Find an order from the order set that is closest to the mileage obtained in step 1); 6) Obtaining the original price on the order obtained in step 5) as the estimated price; And generate priceToken; 7) Organize the estimated request return result, and use the mileage and duration obtained in step 1) and the estimated price and priceToken obtained in step 6) as the estimated return result; 8) Bind priceToken and estimated return result; 9) Output the return result to the passenger APP.

2. A method for avoiding downgrade due to inability to place an order according to claim 1, characterized in that: The MongoDB is a database based on distributed file storage, which can store large amounts of data and dynamically expand storage content.

3. A method for avoiding downgrade due to inability to place an order according to claim 1, characterized in that: In step 8), priceToken is used as the key of Redis, and the result returned in step 7) is used as the Value. The set command of Redis is called to store it in the cache. The cache is kept for one hour in order to bind the relationship between priceToken and the estimated return result, so as to verify whether it has been estimated before when placing an order.

4. A method for avoiding downgrade due to inability to place an order according to claim 1, characterized in that: The scheduled task starts at 3:00 a.m. every day, and the start and end times of the previous day are calculated as 00:00:00-23:59:59 respectively.

5. A method for avoiding downgrade due to inability to place an order according to claim 1, characterized in that: In step 2), the request parameters include city code, mileage, vehicle type, and service type.

Images