A fault recovery method based on freight rate request characteristics and related equipment

Abstract

The present invention provides a fault restoration method based on freight rate request characteristics and related equipment, including determining each request identification code and each log file corresponding to each request instruction input by the user, and then obtaining the request response result corresponding to each log file, and displaying the request response result to the user, the user inputs the target request identification code corresponding to the fault problem in the request response result, and searches for each target log file corresponding to the target request identification code in all log files according to the target request identification code, determines each request instruction original text corresponding to each target request instruction by reading these target log files, constructs a request instruction message corresponding to each target request instruction based on these request instruction original texts, sends the request instruction message to the test environment, and enables the test environment to execute each target request instruction corresponding to the target request identification code according to the request instruction message. The method of the present invention enables the test environment to quickly restore the fault context environment.

Description

Technical Field

[0001] The present invention relates to the field of distributed system fault troubleshooting, and in particular to a fault restoration method based on freight rate request characteristics and related equipment. Background Art

[0002] Once a system failure occurs in the fare calculation system, the ticket agent system of the entire network will be unable to issue tickets normally, affecting people's ticket purchasing and travel needs.

[0003] Reproducing the system fault environment is the basis for debugging and analyzing problematic programs. After the user executes the page turning request instruction multiple times in the freight rate calculation system, if the failure problem of not getting the execution result or the execution result is incorrect is triggered, this kind of fault problem is quite difficult to troubleshoot, mainly because the user's execution fault-related request instruction and sequence are not clear, and secondly, the request instructions executed by the user multiple times will eventually be distributed to different physical machines by the load balancer for execution, and the system operation logs are also scattered on different physical machines, and all users' request logs are intertwined and difficult to distinguish, resulting in difficulty in replaying the request instructions in the test environment in a short time and restoring the fault environment for gdb debugging and analysis. Summary of the invention

[0004] In view of this, the present invention provides a fault recovery method and related equipment based on freight rate request characteristics. Through this method, the time for searching various log files associated with the fault problem is saved, so that the test environment can quickly replay various request instructions associated with the fault problem to restore the context environment corresponding to the fault problem.

[0005] The present invention also provides a fault recovery device based on freight rate request characteristics to ensure the implementation and application of the above method in practice.

[0006] A fault recovery method based on freight rate request characteristics, comprising:

[0007] Receive each request instruction input by the user;

[0008] Determining the request identification code corresponding to each request instruction in sequence according to the order in which each request instruction is input by the user;

[0009] Determine, according to each of the request identification codes corresponding to each of the request instructions, each of the log files corresponding to each of the request instructions;

[0010] Calling a preset maintenance system, obtaining a request response result corresponding to each of the log files, and displaying it to the user, if the request response result shows that there is a fault problem, the request response result includes a target request identification code corresponding to the fault problem;

[0011] If the target request identification code input by the user is received, searching for each target log file corresponding to the target request identification code in all the log files;

[0012] Read the request instruction original text in each of the target log files, and construct a request instruction message corresponding to each target request instruction associated with each of the request instruction original texts;

[0013] The request instruction message is sent to a test environment, so that each of the target request instructions is executed in the test environment according to the request instruction message.

[0014] The above method may optionally further include: after receiving each request instruction input by the user, determining the request identification code corresponding to each request instruction in sequence according to the input order of each request instruction input by the user, and before:

[0015] Get the preset request types;

[0016] According to each of the request types, determining whether the request instruction is a first-level request instruction, each of the request types corresponding to each filling rule;

[0017] If the request instruction is the first-level request instruction, all stored data in the data storage area corresponding to the user must be cleared first.

[0018] The above method, optionally, determining the request identification code corresponding to each request instruction in sequence according to the input order of each request instruction input by the user, comprises:

[0019] Based on the input order of the user input, sequentially obtain each request information corresponding to each request instruction on the current terminal;

[0020] The request identification code corresponding to each request instruction is generated according to each of the request information.

[0021] Optionally, the method of determining each log file corresponding to each request instruction according to each request identification code corresponding to each request instruction includes:

[0022] According to each of the filling rules corresponding to each of the request instructions, the request identification code corresponding to each of the request instructions is sequentially filled into the data storage area to obtain a target data storage area, wherein the target data storage area contains target data composed of each of the request identification codes;

[0023] The target data is printed into each operation log corresponding to each request instruction, so as to obtain each log file corresponding to each log.

[0024] A fault recovery device based on freight rate request characteristics, characterized by comprising:

[0025] A receiving unit, used to receive each request instruction input by a user;

[0026] a determining unit, configured to determine, in sequence, a request identification code corresponding to each of the request instructions according to the order in which each of the request instructions is input by the user;

[0027] A display unit, used to determine each log file corresponding to each request instruction according to each request identification code corresponding to each request instruction;

[0028] A calling unit, used to call a preset maintenance system, obtain a request response result corresponding to each of the log files, and display it to the user. If the request response result shows that there is a fault problem, the request response result includes a target request identification code corresponding to the fault problem;

[0029] a search unit, configured to search for each target log file corresponding to the target request identification code in all the log files if the target request identification code input by the user is received;

[0030] A construction unit, configured to read the original request instruction text in each of the target log files, and construct a request instruction message corresponding to each target request instruction associated therewith according to each of the original request instruction texts;

[0031] A sending unit is used to send the request instruction message to the test environment, so as to execute each of the target request instructions in the test environment according to the request instruction message.

[0032] The above device may optionally further include:

[0033] A first acquisition subunit, used to acquire each preset request type;

[0034] A judging subunit, used for judging whether the request instruction is a first-level request instruction according to each of the request types, each of the request types corresponding to each filling rule;

[0035] The clearing subunit is used to clear all the stored data in the data storage area corresponding to the user if the request instruction is the first-level request instruction.

[0036] In the above device, optionally, the determining unit includes:

[0037] A second acquisition subunit, configured to sequentially acquire, based on the input order of the user input, each piece of request information corresponding to each request instruction on the current terminal;

[0038] The generating subunit is used to generate the request identification code corresponding to each request instruction according to each request information.

[0039] In the above device, optionally, the display unit comprises:

[0040] A filling subunit is used to fill the request identification code corresponding to each request instruction into the data storage area in turn according to each filling rule corresponding to each request instruction, so as to obtain a target data storage area, wherein the target data storage area contains target data composed of each request identification code;

[0041] The printing subunit is used to print the target data into each operation log corresponding to each request instruction to obtain each log file corresponding to each log.

[0042] A storage medium includes a stored program, wherein when the program is running, the device where the storage medium is located is controlled to execute the above-mentioned fault recovery method based on freight rate request characteristics.

[0043] An electronic device includes one or more processing devices and a memory, on which one or more programs are stored, wherein when the one or more programs are executed by the one or more processing devices, the one or more processing devices implement the above-mentioned fault recovery method based on freight rate request characteristics.

[0044] Compared with the prior art, the present invention includes the following advantages: when receiving each request instruction input by the user, the request identification code corresponding to the request instruction is determined in turn according to the input order of each request instruction input by the user, and then the log files corresponding to each request instruction are determined, and the request response results corresponding to each log file are obtained based on the maintenance system and displayed to the user, if the target request identification code in the request response result input by the user is received, the target log files corresponding to the target request identification code are searched in all log files, the request instruction original text in each target log file is read, and the request instruction message corresponding to the target request instruction associated with each request instruction original text is constructed, and the request instruction message is sent to the test environment, so as to execute each target request instruction according to the request instruction message in the test environment. The method of the present invention saves the time of searching the log files associated with the fault, and enables the test environment to quickly execute the request instructions associated with the fault to restore the context environment corresponding to the fault problem. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0046] Figure 1 A system structure diagram of a fault recovery system based on freight rate request characteristics provided by an embodiment of the present invention;

[0047] Figure 2 Another system structure diagram of a fault recovery system based on freight rate request characteristics provided by an embodiment of the present invention;

[0048] Figure 3 A method flow chart of a fault recovery method based on freight rate request characteristics provided by an embodiment of the present invention;

[0049] Figure 4 A device structure diagram of a fault recovery device based on freight rate request characteristics provided by an embodiment of the present invention;

[0050] Figure 5 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0051] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments described herein, which are instead provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0052] The term "including" and its variations used herein are open inclusions, i.e., "including but not limited to". The term "based on" means "based at least in part on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.

[0053] It should be noted that the concepts such as "first" and "second" mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0054] It should be noted that the modifications of "one" and "plurality" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, it should be understood as "one or more".

[0055] In order to facilitate understanding of the technical solution of the present invention, the technical terms appearing in the present invention are explained:

[0056] Session: The credential used to uniquely identify a user in the freight rate calculation system. It is associated with the user's current request status information in the system and is similar in function to cookies in http requests.

[0057] contextTracer: is the name of the data storage area customized by the present invention. Each redis / data center contains a unique contextTracer data storage area, which is an independent module in the freight rate calculation system.

[0058] TOKEN: A fixed-length string generated based on the computing node machine IP, the time when the instruction was received, the process number, and other information, such as 3GAAATQL3CKUK4.

[0059] Sessionkey: A string representation used to uniquely identify user credentials in the freight rate calculation system. Sessionkey can be used as a key for redis storage.

[0060] PID: The PID carried in the request indicates the user's terminal number, which is similar to the terminal user's identity ID and can be used to construct the session key.

[0061] OFFICE: The OFFICE carried in the request indicates the user's OFFIC number, such as PEK099, and is also used to identify the user.

[0062] MarketingCarrier: This field is related to the specific content of the request and indicates the two-letter code of the marketing airline.

[0063] cmd: request command, such as first-level request command, second-level request command, page turning request command, etc.

[0064] Level 1 request instruction: A type of request in the freight rate calculation system, such as the automatic freight rate calculation instruction PATA, the published freight rate query instruction FD, the private freight rate query instruction NFD, etc., all belong to the level 1 request instructions. The level 1 request instructions are independent of each other and have no contextual association, but each level 1 request instruction has several level 2 request instructions associated with it.

[0065] Secondary request instruction: A type of request in the freight rate calculation system. The secondary request instruction is contextually associated with the previous primary request instruction. For example, the SFB instruction for querying brand additional service information is the secondary request instruction of PATA, and the NFN instruction for querying freight rate rule details is the secondary request instruction of the NFD instruction, and so on.

[0066] Page turning request instruction: a type of request in the freight rate calculation system, which turns the page of the execution result of the previous instruction (first-level request instruction or second-level request instruction), such as turning the page PN backward, turning the page PB forward, turning the specified page NFPG, etc.

[0067] As can be seen from the background technology, when a user inputs multiple request instructions in the freight rate calculation system, the load balancer will distribute each request instruction to different physical machines for execution. When there is a fault in the freight rate calculation system, it is difficult to sort out the various request instructions associated with the fault and the input / execution order of each request instruction, making it difficult to restore the context environment corresponding to the fault.

[0068] Therefore, an embodiment of the present invention provides a fault recovery method based on freight rate request characteristics and related equipment. In this solution, when each request instruction input by the user is received, the request identification code corresponding to the request instruction is determined in turn according to the input order of each request instruction input by the user, and then the log files corresponding to each request instruction are determined. Based on the maintenance system, the request response results corresponding to each log file are obtained and displayed to the user. If the target request identification code in the request response result input by the user is received, the target log files corresponding to the target request identification code are searched in all log files, the request instruction original text in each target log file is read, and the request instruction message corresponding to the target request instruction associated with each request instruction original text is constructed, and the request instruction message is sent to the test environment to replay each target request instruction according to the request instruction message in the test environment.

[0069] First, a structural diagram of a fault restoration system based on freight request features used in a fault restoration method based on freight request features of the present invention is introduced. The fault restoration system can be applied to a variety of system platforms, and its execution subject can be a processor of a computer terminal or various mobile devices. The system structural diagram of the fault restoration system is as follows: Figure 1 As shown, it specifically includes: a load balancer 101, a cluster / computing node 102, a redis / data center 103, and a log retrieval system 104. The output end of the load balancer 101 is connected to the input end of the cluster / computing node 102, the output end of the cluster / computing node 102 is connected to the input end of the redis / data center 103, and the output end of the log retrieval system 104 is connected to the input end of the cluster / computing node 104.

[0070] The load balancer 101 is used to distribute each request instruction to each physical machine in the cluster / computing node.

[0071] The cluster / computing node 102 is used to calculate the freight rate for the request instruction when receiving the request instruction.

[0072] Redis / data center 103 is used to store the intermediate results corresponding to the request instructions generated during the freight rate calculation process.

[0073] The log retrieval system 104 is used to remotely search various log files scattered in the cluster / computing node 102 according to the TOKEN when receiving the TOKEN to determine various target log files.

[0074] based on Figure 1 The process of implementing fault recovery in the public fault recovery system based on freight rate request characteristics is as follows:

[0075] When the user inputs each request instruction using the user terminal, the load balancer 101 is called to send each request instruction to the cluster / computing node 102 , that is, the cluster / computing node 102 receives each request instruction input by the user through the load balancer 101 .

[0076] There are multiple computing nodes, i.e., multiple physical machines, in the cluster / computing node, and each computing node runs a copy of a freight rate calculation system.

[0077] Among them, each request instruction at least includes a first-level request instruction, a second-level request instruction and a page turning request instruction.

[0078] For example, the primary request instruction may be PAT, FD, NFD, etc., the secondary request instruction may be SFN, PFN, NFN, etc., and the page turning request instruction may be PN, PL, PF, etc.

[0079] That is, when the cluster / computing node 102 receives each request instruction input by the user through the load balancer 101, it starts to perform the fault recovery process, which is as follows:

[0080] According to the order in which each request instruction is input by the user, the cluster / computing node 102 is used to sequentially determine the request identification code corresponding to each request instruction.

[0081] For example, if the user inputs the request instruction in the order of a primary request instruction, a secondary request instruction, and a page turning request instruction, the cluster / computing node 102 first determines the primary request identification code corresponding to the primary request instruction, then determines the secondary request identification code corresponding to the secondary request instruction, and finally determines the page turning request identification code corresponding to the page turning request instruction. The secondary request instruction is a secondary request instruction that is contextually associated with the primary request instruction, and the page turning request instruction is a page turning request instruction that is contextually associated with the secondary request instruction.

[0082] The request identification code is data stored in the variable-length tail structure in the contextTracer data storage area, and the data stored in the variable-length tail structure in the data storage area includes but is not limited to the request identification code, and the data may also include a request instruction name. The request identification code is TOKEN, and the request instruction name is cmd.

[0083] It should be noted that the contextTracer data storage area includes a fixed-length header and a variable-length tail. The fixed-length header includes the basic information of the request instruction (the basic information is usually the parsed data of the first-level request instruction), and the variable-length tail includes the request identification code and the request instruction name of the request instruction. The structural diagram of the specific data structure of the contextTracer data storage area is shown in Figure 2 shown.

[0084] Among them, the basic information includes various feature data and session data after parsing the request instruction, such as the source system of the request instruction, the PID number and OFFICE number of the request instruction, the marketing carrier code contained in the request instruction, the system time of receiving the request instruction, etc. The basic information of the fixed-length header only contains the data parsed by the first-level request instruction. The secondary request instructions (secondary, page turning, etc.) share a set of context data with consistent basic information. In the subsequent executed secondary request instructions, if the basic information is missing, it can be directly obtained from the fixed-length header to realize the function of information completion. Secondly, the basic information stored in the fixed-length header can also be used to perform fine control of the subsequent secondary request instruction traffic, user behavior statistics, etc.

[0085] The variable-length tail stores the command names cmd executed in sequence by each level of request commands and the tokens generated by the cluster / computing node. In a user terminal, each secondary request command and page-turning request command executed by the user will be appended to the end of the variable-length tail.

[0086] It should also be noted that when the user wants to execute the first-level request instruction again, the old data in the contextTracer structure will be cleared, and then the fixed-length header data will be filled with the basic information of the currently executed first-level request instruction, and cmd and TOKEN will be filled into the first data block of the variable-length tail.

[0087] According to each of the request identification codes corresponding to each of the request instructions, each of the log files corresponding to each of the request instructions is determined.

[0088] The cluster / computing node 102 includes multiple physical machines, and the functions of these physical machines are the same. Each request instruction will be distributed to any physical machine for execution by the load balancer 101, so the corresponding operation logs generated when each request instruction is executed will also be scattered on any physical machine.

[0089] After determining the request identification code corresponding to each request instruction, the request identification code can be recorded in the operation log corresponding to the request instruction in a fixed format to obtain the log file corresponding to the request instruction. At this time, the prefix of the log line in the log file contains the TOKEN corresponding to the current request instruction, and the TOKEN is wrapped in square brackets, that is, [TOKEN].

[0090] It should be noted that, according to the input order of each request instruction input by the user and the filling rules corresponding to each request instruction, the request identification code corresponding to each request instruction is filled into the variable-length tail structure in the data storage area in turn. At this time, the target data in the variable-length tail structure is used as a fixed format.

[0091] It should also be noted that the various log files are scattered on various physical machines in the cluster / computing node 102 .

[0092] For example, in a user terminal, when a first-level request instruction input by a user is received, all old data contained in the contextTracer data storage area is cleared, the first-level request instruction is parsed based on the current user terminal, and the first-level basic information of the current first-level request instruction is obtained. According to the first-level basic information, the first-level cmd and the first-level TOKEN of the first-level request instruction are determined by using the cluster / computing node, and the first-level basic information is filled into the fixed-length header structure of the contextTracer, and the first-level cmd and the first-level TOKEN are filled into the first data block of the variable-length tail structure of the contextTracer. If a second-level request instruction is received from the user at this time, the current second-level request instruction is determined. Find the secondary cmd and secondary TOKEN corresponding to the instruction, and append the secondary cmd and secondary TOKEN to the second data block after the first data block to associate the primary request instruction with the secondary request instruction. Similarly, if the user continues to input a page turning request instruction, the page turning cmd and page turning TOKEN corresponding to the page turning request instruction are appended to the third data block after the second data block to associate the secondary request instruction with the page turning request instruction. When the user stops inputting the request instruction, the first data block, the second data block and the third data block are used as all request identification code data, and are printed to each operation log corresponding to each request instruction to obtain each log file corresponding to each request instruction.

[0093] The preset maintenance system is called to obtain the request response results corresponding to each of the log files, and displayed to the user.

[0094] If the request response result shows that there is a fault problem, the request response result includes a target request identification code corresponding to the fault problem, and the target request identification code can be marked as a fault.

[0095] The maintenance system displays each log file to the system maintenance personnel who are troubleshooting the problem. The system maintenance personnel analyze each log file, obtain the request response results corresponding to each log file, and send the request response results to the user so that the user can check whether there is a fault problem in the current request response result. If the user finds a fault through the request response result, the user can input the target request identification code contained in the request response result into the log retrieval system.

[0096] It should be noted that if the request response result is a fault, the user cannot view the log files corresponding to the current request instructions, or the log files displayed to the user corresponding to the current request instructions indicate that there is a fault problem.

[0097] If the log retrieval system 104 receives the target request identification code input by the user, it searches for each target log file corresponding to the target request identification code in all the log files.

[0098] Because the various log files are scattered on multiple physical machines, the target TOKEN is input into the log retrieval system 104, and the log retrieval system can be called to remotely retrieve the corresponding multiple log files in each physical machine, and quickly retrieve the various target log files corresponding to its TOKEN from all log files.

[0099] The request instruction original text in each of the target log files is read, and a request instruction message corresponding to each target request instruction associated therewith is constructed according to each of the request instruction original texts.

[0100] The request instruction message is sent to a test environment, so that each of the target request instructions is executed in the test environment according to the request instruction message.

[0101] In the system provided by the embodiment of the present invention, the request instruction input by the user will be distributed by the load balancer 101 to a computing node in the cluster / computing node 102 for freight rate calculation. In the process of freight rate calculation, an intermediate result corresponding to the request instruction is generated, and the intermediate result will be stored in the redis / data center 103 and printed to the operation logs scattered on each machine, so as to obtain a log file corresponding to each request instruction, and then obtain a request response result corresponding to each log file. The log retrieval system 104 can be called to remotely retrieve each log file corresponding to the target TOKEN with a fault problem, reconstruct the request instruction message based on each target log file, and load the request instruction message in the test environment to restore the context environment corresponding to each request instruction.

[0102] Among them, intermediate results refer to useful data generated during the calculation or query process. These data can also be called context data. They are not the final calculation results returned, but the intermediate data will affect the calculation results of the user's subsequent instructions. The intermediate data will be cached in the redis data center.

[0103] The calculation result finally returned is the request response result analyzed by the system maintenance personnel.

[0104] After receiving the user request instruction, the cluster / computing node will immediately do two things: first, generate a sessionkey based on the user's session information (ID information of the client terminal). Through the sessionkey, the context data generated by the calculation process corresponding to the request instruction can be stored and extracted in redis / data center; second, generate a token based on the machine IP, the time point when the request instruction is received, the process number and other information. The prefix of each log generated by the subsequent calculation process will contain the token. Through the token, the log file of the computing node in the cluster can be easily located, and then the request instruction log (the log file contains many log lines of instructions) can be filtered in the log file through the token. In addition, the TOKEN will also be included in the calculation results and returned to the user. The user can view the calculation results. If a fault is found in the calculation results, the user can send the corresponding TOKEN with the fault to the log retrieval system. The log file can be searched in the log retrieval system through the TOKEN provided by the user, and the target log files of the associated instructions can be found according to the user behavior track recorded by contextTracer in the log. The complete message corresponding to each target request instruction, namely the request instruction message, can be extracted from it. Then, in the test environment, the context environment can be restored in the order of the complete message to troubleshoot the problem.

[0105] For example, when a user executes a freight rate calculation instruction from Beijing to Shanghai for the first time, the system may eventually calculate intermediate results such as different prices and applicable rules for multiple routes and cabins. However, the result finally returned to the user only contains summary data of some of the best calculation results. If the user wants to query more detailed applicable rules and other data for a certain calculation result, it is necessary to send relevant instructions to the calculation system again. The calculation system needs to extract the last intermediate result, and then generate and return the calculation result that the user is concerned about based on the intermediate result and specific query instructions.

[0106] Based on the above-mentioned fault recovery system based on the freight request feature, Figure 3 The above is a flowchart of a fault recovery method based on freight rate request characteristics provided by an embodiment of the present invention. The method can be applied to a variety of system platforms, and its execution subject can be a processor of a computer terminal or various mobile devices. The method flowchart of the method is as follows Figure 1 As shown, specifically including:

[0107] S201: receiving various request instructions input by the user;

[0108] In the method provided by the embodiment of the present invention, the user can input various request instructions through the user terminal, and call the load balancer to send these request instructions to any physical machine included in the cluster / computing node.

[0109] It should be noted that each request instruction corresponds to each request type, and each request type includes but is not limited to a primary request instruction, a secondary request instruction, and a page turning request instruction, wherein each request type corresponds to a different filling rule.

[0110] Therefore, after receiving a request instruction, it is necessary to first determine the request type of the request instruction, and then process it according to the filling rule corresponding to the request type.

[0111] It should also be noted that if the request instruction input by the user is a first-level request instruction, all stored data in the data storage area must be cleared before applying the filling rule corresponding to the first-level request instruction to fill the data storage area corresponding to the user.

[0112] S202: determining the request identification code corresponding to each request instruction in sequence according to the order in which each request instruction is input by the user;

[0113] In the method provided by the embodiment of the present invention, according to the input order of each request instruction input by the user, such as the user first inputs the first-level request instruction and then enters the second-level request instruction, the first-level request information corresponding to the first-level request instruction on the current user terminal, that is, the basic information, is first determined based on the cluster / computing node, and then the first-level cmd and first-level TOKEN corresponding to the first-level request instruction are generated according to each first-level request information. After determining the first-level TOKEN, the second-level request information corresponding to the second-level request instruction is then determined and the corresponding second-level cmd and second-level TOKEN are generated, and the first-level TOKEN is used as the request identification code corresponding to the first-level request instruction, and the second-level TOKEN is used as the request identification code corresponding to the second-level request instruction.

[0114] Specifically, by parsing the request instruction, various request information corresponding to the request instruction is determined, such as the source system of the request instruction, the PID number and OFFICE number of the request instruction, the marketing carrier code MarketingCarrier contained in the request instruction, and the system time of receiving the request instruction.

[0115] It should be noted that after determining the request information, request identification code and request instruction name of each request instruction, these request information, request identification code and request instruction name need to be cached in the input order of each request instruction, that is, filled into the contextTracer data storage area contained in the redis / data center.

[0116] It should also be noted that each request instruction corresponds to each filling rule.

[0117] S203: determining each log file corresponding to each request instruction according to each request identification code corresponding to each request instruction;

[0118] In the method provided by the embodiment of the present invention, after determining the filling rules corresponding to each request instruction, the request identification code corresponding to the request instruction is filled into the contextTracer data storage area based on the filling rules corresponding to the request instruction. At the same time, according to the input order corresponding to each request instruction input by the user, the request identification codes corresponding to each request instruction are filled into the contextTracer data storage area in sequence. When the request identification code corresponding to the last input request instruction is filled, the filling process can be stopped and a new target data storage area can be obtained. According to the target data contained in the target data storage area, the log files corresponding to each request instruction are determined. Its target data is composed of each request identification code.

[0119] The target data storage area includes but is not limited to target data composed of various request identification codes.

[0120] Among them, some key steps and instruction details during the execution of the request instruction, which are helpful for manually verifying the accuracy of the calculation results and troubleshooting calculation problems, will be printed in the log files scattered on each physical machine in the cluster / computing node, so as to manually analyze the work order questions raised by the user. The series of contents are intermediate results. On the same computing node, the running logs of all request instructions will be output to the same log file in the order of operation, that is, the log file records the running logs of all request instructions associated with the same context, and when the size of the log file exceeds 500MB, the system will automatically generate a new log file, and the subsequent log content will continue to be printed in the new log file, and so on.

[0121] S204: calling a preset maintenance system, obtaining request response results corresponding to each of the log files, and displaying them to the user;

[0122] If the request response result shows that there is a fault problem, the request response result includes a target request identification code corresponding to the fault problem.

[0123] After determining each log file, the maintenance system is called, and based on the maintenance system, each log file is displayed to the system maintenance personnel who are troubleshooting the problem. The system maintenance personnel analyze these log files, obtain the request response results corresponding to each log file, and display the request response results to the user, so that the user knows whether there is a fault problem with the request response results corresponding to each request instruction.

[0124] S205: If the target request identification code input by the user is received, searching for each target log file corresponding to the target request identification code in all the log files;

[0125] Among them, if the user finds the target request identification code corresponding to the fault problem in the displayed request response result, the target request identification code is entered through the user terminal. The target request identification code is the target TOKEN. After the user provides the target TOKEN, the remaining process is automatically executed by the preset program and can be completed within a few seconds. The program is a packaged program that is executed directly in the command line related to the received target TOKEN (such as Q1EUKTQL3BSQ31) by the development and maintenance personnel.

[0126] Among them, the log lines of the associated request instructions recorded in all the records executed by TOKEN will be scattered in different log files of different physical machines, and TOKEN contains information such as machine IP, time point of receiving instructions, process number, etc. Therefore, the target log files associated with it can be quickly retrieved from various log files through the target TOKEN.

[0127] It should be noted that the request identification code corresponding to each request instruction is appended to the variable-length tail of the contextTracer data storage area, and then the data in the variable-length tail is recorded in the running log to obtain a log file. At this time, the prefix of the log line in the log file contains the [TOKEN] corresponding to each request instruction. Therefore, using the target TOKEN can easily extract each target log file in the cluster / computing node.

[0128] Specifically, each log file contains all execution records GRANDPARENT TRANSACTIONIDRECORDS of the corresponding TOKEN (request instructions executed in sequence, such as primary request instructions, secondary request instructions, and page turning request instructions).

[0129] S206: Read the original request instruction text in each of the target log files, and construct a request instruction message corresponding to each target request instruction associated with each original request instruction according to each original request instruction;

[0130] In the method provided by an embodiment of the present invention, reading the log file can determine the original request instruction text contained therein, and based on the original request instruction text, determine each target request instruction contained therein and each input / execution sequence corresponding to each target request instruction, and based on each input / execution sequence and each target request instruction, the request instruction message corresponding to each target request instruction can be reconstructed.

[0131] S207: Send the request instruction message to the test environment, so as to execute each of the target request instructions in the test environment according to the request instruction message.

[0132] Among them, after the request instruction message is input into the test environment, the test environment can execute each target request instruction in sequence according to the request instruction message, and restore the context environment corresponding to each target request instruction.

[0133] In the method provided by the embodiment of the present invention, when receiving each request instruction input by the user, the request identification code corresponding to the request instruction is determined in turn according to the input order of each request instruction input by the user, and then the log files corresponding to each request instruction are determined, and the request response results corresponding to each log file are obtained based on the maintenance system and displayed to the user, and if the target request identification code in the request response result input by the user is received, the target log files corresponding to the target request identification code are searched in all log files, the original text of the request instruction in each target log file is read, and the request instruction message corresponding to the target request instruction associated with each request instruction is constructed according to the original text of each request instruction, and the request instruction message is sent to the test environment to execute each target request instruction according to the request instruction message in the test environment. The method of the present invention saves the time of searching for log files associated with the fault, and enables the test environment to quickly replay the request instruction associated with the fault to restore the fault context environment.

[0134] Based on the method provided in the above embodiment, after performing step S201 to receive each request instruction input by the user, before performing step S202 to sequentially determine the request identification code corresponding to each request instruction according to the input order of each request instruction input by the user, the method further includes:

[0135] Get the preset request types;

[0136] According to each of the request types, determining whether the request instruction is a first-level request instruction, each of the request types corresponding to each filling rule;

[0137] If the request instruction is the first-level request instruction, all stored data in the data storage area corresponding to the user must be cleared first.

[0138] Based on the method provided in the above embodiment, step S202 mentions determining the request identification code corresponding to each request instruction in sequence according to the input order of each request instruction input by the user, including:

[0139] Based on the input order of the user input, sequentially obtain each request information corresponding to each request instruction on the current terminal;

[0140] The request identification code corresponding to each request instruction is generated according to each of the request information.

[0141] Based on the method provided in the above embodiment, step S203 mentions determining each log file corresponding to each request instruction according to each request identification code corresponding to each request instruction, including:

[0142] According to each of the filling rules corresponding to each of the request instructions, the request identification code corresponding to each of the request instructions is sequentially filled into the data storage area to obtain a target data storage area, wherein the target data storage area contains target data composed of each of the request identification codes;

[0143] The target data is printed into each operation log corresponding to each request instruction, so as to obtain each log file corresponding to each log.

[0144] In the method provided in the embodiment of the present invention, the user inputs a request instruction and provides a TOKEN associated with the fault, for example:

[0145] The user inputs NFD: SHASZX / 12JUN22 / MF (the request instruction indicates to query the private freight rate from SHA to SZX released by MF Airlines on June 22, 2022). After receiving the request instruction, the freight rate calculation system parses the user's request instruction and the message header information of the request instruction, and generates a sessionkey based on the user identifier in the message header information, and generates a TOKEN based on the machine IP, timestamp, PID of the current processing process and other information.

[0146] And use TOKEN to initialize the header of the log printing module of the current processing process. The information output to the log file in the subsequent processing flow of this process will be marked with the TOKEN, which is convenient for using TOKEN to extract the log file of the instruction later.

[0147] Since the NFD request instruction is a first-level request instruction, you need to use the sessionkey to reset the contextTracer data structure in redis / data center, and use the basic information after parsing the request instruction to initialize the fixed-length header, and use the instruction name NFD and TOKEN to generate the first data block of the variable-length tail (such as NFD, GEC6KTIL3AK6O1).

[0148] Finally, the calculation result including TOKEN is returned to the user.

[0149] If there are many business freight rate items fed back, the user can enter the page turning request instruction FN to turn the page. After receiving the page turning request instruction, the freight rate calculation system generates a sessionkey according to the user identifier in the message header information, and generates a TOKEN according to the machine IP, timestamp, PID of the current processing process and other information. Then, the sessionkey is used to append the instruction name PN and TOKEN to the end of the variable-length tail of the contextTracer (such as PN, 3GAAATQL3CKUK4) to redis / data center, and the GRANDPARENT TRANSACTIONID RECORDS is recorded in the operation log: (NFD)GEC6KTIL3AK6O1--(PN)3GAAATQL3CKUK4.

[0150] The user enters the secondary request instruction NFN:19 / / 01 (the instruction identifier queries the applicable rules of category 01 of the freight rate in Article 19 in the NFD result). After receiving the secondary request instruction, the computing system generates a sessionkey based on the user identifier in the message header information, and generates a TOKEN based on the machine IP, timestamp, PID of the current processing process and other information. Then, the sessionKey is used to append the instruction name NFN and TOKEN to the end of the variable-length tail of the contextTracer (such as NFN, TZJAYTQL3C1X13) to redis / data center, and the GRANDPARENT TRANSACTIONIDRECORDS is recorded in the operation log: (NFD)GEC6KTIL3AK6O1--(PN)3GAAATQL3CKUK4--(NFN)TZJAYTQL3C1X13.

[0151] The user may turn the page again or continue to query other freight rate rules as needed. The process is similar to the above-mentioned process after the page turning request instruction is input. Each time the secondary request instruction and the page turning request instruction are executed, the GRANDPARENT TRANSACTIONID RECORDS will be recorded in the operation log. The final GRANDPARENT TRANSACTIONID RECORDS generated may be (NFD)GEC6KTIL3AK6O1--(PN)3GAAATQL3CKUK4--(NFN)TZJAYTQL3C1X13--(NFN)ILFBOTQL3A1YO6--(PN)II5SGTQL3A1534--(PN)I1XS3TQL3AC RA3--(NFN)3UTDUTQL3AS3S4--(NFN)Q1EUKTQL3BSQ31.

[0152] If the user feels that there is a problem with the queried freight rate, he or she can provide the TOKEN contained in the problem result.

[0153] Based on the method provided in the above embodiment, according to the token provided by the user, in the process of analyzing the fault problem in the test environment, for the convenience of description, it is assumed that the token provided by the user in this example is Q1EUKTQL3BSQ31, for example:

[0154] After the packaging program such as lfepReplay is started, the Q1EUKTQL3BSQ31 provided by the user is sent to the log retrieval system, and after extracting the various target log files of the production environment of the NFN instruction, the NFN instruction message is constructed. That is, the TOKEN of the associated request instruction provided by the GRANDPARENT TRANSACTIONID RECORDS in the log file is sent to the log retrieval system in sequence, and the various log files of the associated request instruction are extracted, and the request instruction message of the associated request instruction is constructed according to the log content in the log file. After waiting for all the request instruction messages to be constructed, the request instruction message (NFD)--(PN)--(NFN)--(NFN)--(PN)--(PN)--(NFN)--(NFN) is automatically sent to the 10549 port of the test environment 10.221.5.102 machine in sequence, so as to restore the fault problem in 10.221.5.102 and perform related debug troubleshooting operations.

[0155] It should be noted that the flowcharts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or the flowchart, and the combination of the boxes in the block diagram and / or the flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0156] The names of the messages or information exchanged between the multiple devices in the embodiments of the present disclosure are only for illustrative purposes and are not intended to limit the scope of these messages or information.

[0157] The above-mentioned embodiment of the present invention Figure 3Corresponding to the fault restoration method based on the freight rate request feature shown in the embodiment of the present invention, the embodiment of the present invention also provides a fault restoration device based on the freight rate request feature, such as Figure 4 As shown, the fault recovery device based on freight rate request characteristics includes: a receiving unit 301, a determining unit 302, a display unit 303, a calling unit 304, a searching unit 305, a constructing unit 306 and a sending unit 307.

[0158] The receiving unit 301 is used to receive various request instructions input by the user;

[0159] A determining unit 302, configured to determine, in sequence, a request identification code corresponding to each of the request instructions according to the order in which each of the request instructions is input by the user;

[0160] The display unit 303 is used to determine each log file corresponding to each request instruction according to each request identification code corresponding to each request instruction;

[0161] The calling unit 304 is used to call the preset maintenance system, obtain the request response result corresponding to each of the log files, and display it to the user. If the request response result shows that there is a fault problem, the request response result includes a target request identification code corresponding to the fault problem;

[0162] The search unit 305 is configured to search for each target log file corresponding to the target request identification code in all the log files if the target request identification code input by the user is received;

[0163] A construction unit 306 is used to read the original request instruction in each of the target log files, and construct a request instruction message corresponding to each target request instruction associated therewith according to each original request instruction;

[0164] The sending unit 307 is used to send the request instruction message to the test environment, so as to execute each target request instruction in the test environment according to the request instruction message.

[0165] In the device provided by the embodiment of the present invention, when receiving each request instruction input by the user, the request identification code corresponding to the request instruction is determined in turn according to the input order of each request instruction input by the user, and then the log files corresponding to each request instruction are determined, and the request response results corresponding to each log file are obtained based on the maintenance system and displayed to the user. If the target request identification code in the request response result input by the user is received, the target log files corresponding to the target request identification code are searched in all log files, the original text of the request instruction in each target log file is read, and the request instruction message corresponding to the target request instruction associated with each request instruction is constructed according to the original text of each request instruction, and the request instruction message is sent to the test environment to execute each target request instruction according to the request instruction message in the test environment. The application of the device of the present invention saves the time of searching for log files associated with faults, and enables the test environment to quickly replay the request instructions associated with the fault to restore the fault context environment.

[0166] On the basis of the device provided in the above embodiment, the device provided in the embodiment of the present invention further includes:

[0167] A first acquisition subunit, used to acquire each preset request type;

[0168] A judging subunit, used for judging whether the request instruction is a first-level request instruction according to each of the request types, each of the request types corresponding to each filling rule;

[0169] The clearing subunit is used to clear all the stored data in the data storage area corresponding to the user if the request instruction is the first-level request instruction.

[0170] On the basis of the apparatus provided in the above embodiment, in the apparatus provided in the embodiment of the present invention, the determining unit 302 includes:

[0171] A second acquisition subunit, configured to sequentially acquire, based on the input order of the user input, each piece of request information corresponding to each request instruction on the current terminal;

[0172] The generating subunit is used to generate the request identification code corresponding to each request instruction according to each request information.

[0173] On the basis of the device provided in the above embodiment, in the device provided in the embodiment of the present invention, the display unit 303 includes:

[0174] A filling subunit is used to fill the request identification code corresponding to each request instruction into the data storage area in turn according to each filling rule corresponding to each request instruction, so as to obtain a target data storage area, wherein the target data storage area contains target data composed of each request identification code;

[0175] The printing subunit is used to print the target data into each operation log corresponding to each request instruction to obtain each log file corresponding to each log.

[0176] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0177] Another embodiment of the present application provides an electronic device, such as Figure 5 , which shows a schematic diagram of the structure of an electronic device 400 suitable for implementing an embodiment of the present invention. The electronic device in the embodiment of the present invention may include, but is not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0178] like Figure 5 As shown, the electronic device 400 specifically includes one or more processing devices 401, such as a central processing unit, a graphics processing unit, etc., and a memory 402, on which one or more programs are stored. When the one or more programs are executed by the one or more processing devices 401, the one or more processing devices 401 implement a fault recovery method based on the freight rate request feature as provided in any of the above embodiments.

[0179] Optionally, the electronic device may also include other components, see also Figure 5 , the processing device 401, the read-only memory ROM402 and the random access memory RAM403 are connected to each other via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404. Typically, the following devices can be connected to the I / O interface 405: an input device 406 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 407 including, for example, a liquid crystal display, a speaker, a vibrator, etc., a storage device 408 including, for example, a magnetic tape, a hard disk, etc., and a communication device 409. The communication device 409 can allow the electronic device 400 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 5The electronic device 400 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0180] Another embodiment of the present application provides a computer storage medium for storing a program, which, when executed, is used to implement a fault recovery method based on freight rate request characteristics as provided in any of the above embodiments.

[0181] Computer storage media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0182] The computer storage medium may be included in the electronic device 400 ; or may exist independently without being installed in the electronic device 400 .

[0183] Another embodiment of the present application provides a computer program product. When the computer program product is executed, it is used to execute any of the above-mentioned fault recovery methods based on freight rate request characteristics.

[0184] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer storage medium, and the computer program contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device 409, or installed from the storage device 406, or installed from the ROM402. When the computer program is executed by the processing device 401, the above-mentioned functions defined in the method of the embodiment of the present disclosure are executed.

[0185] In the detailed description section, this application repeats all the contents protected in the form of claims in the following form:

[0186] Receive each request instruction input by the user;

[0187] Determining the request identification code corresponding to each request instruction in sequence according to the order in which each request instruction is input by the user;

[0188] Determine, according to each of the request identification codes corresponding to each of the request instructions, each of the log files corresponding to each of the request instructions;

[0189] Calling a preset maintenance system, obtaining a request response result corresponding to each of the log files, and displaying it to the user, if the request response result shows that there is a fault problem, the request response result includes a target request identification code corresponding to the fault problem;

[0190] If the target request identification code input by the user is received, searching for each target log file corresponding to the target request identification code in all the log files;

[0191] Read the request instruction original text in each of the target log files, and construct a request instruction message corresponding to each target request instruction associated with each of the request instruction original texts;

[0192] The request instruction message is sent to a test environment, so that each of the target request instructions is executed in the test environment according to the request instruction message.

[0193] According to one or more embodiments disclosed in the present application, after receiving each request instruction input by the user, before sequentially determining the request identification code corresponding to each request instruction according to the input order of each request instruction input by the user, the method further includes:

[0194] Get the preset request types;

[0195] According to each of the request types, determining whether the request instruction is a first-level request instruction, each of the request types corresponding to each filling rule;

[0196] If the request instruction is the first-level request instruction, all stored data in the data storage area corresponding to the user must be cleared first.

[0197] According to one or more embodiments disclosed in the present application, determining the request identification code corresponding to each request instruction in sequence according to the input order of each request instruction input by the user includes:

[0198] Based on the input order of the user input, sequentially obtain each request information corresponding to each request instruction on the current terminal;

[0199] The request identification code corresponding to each request instruction is generated according to each of the request information.

[0200] According to one or more embodiments disclosed in the present application, determining each log file corresponding to each request instruction according to each request identification code corresponding to each request instruction includes:

[0201] According to each of the filling rules corresponding to each of the request instructions, the request identification code corresponding to each of the request instructions is sequentially filled into the data storage area to obtain a target data storage area, wherein the target data storage area contains target data composed of each of the request identification codes;

[0202] The target data is printed into each operation log corresponding to each request instruction, so as to obtain each log file corresponding to each log.

[0203] Although the subject matter has been described in language specific to structural features and / or methodological logical actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims.

[0204] Although several specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Certain features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination.

[0205] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present disclosure (but not limited to) by each other to form a technical solution.

Claims

1. A fault recovery method based on freight rate request characteristics, characterized in that: include: Receive each request instruction input by the user; Determining the request identification code corresponding to each request instruction in sequence according to the order in which each request instruction is input by the user; Determine, according to each of the request identification codes corresponding to each of the request instructions, each of the log files corresponding to each of the request instructions; Calling a preset maintenance system, obtaining a request response result corresponding to each of the log files, and displaying it to the user, if the request response result shows that there is a fault problem, the request response result includes a target request identification code corresponding to the fault problem; If the target request identification code input by the user is received, searching for each target log file corresponding to the target request identification code in all the log files; Read the request instruction original text in each of the target log files, and construct a request instruction message corresponding to each target request instruction associated with each of the request instruction original texts; The request instruction message is sent to a test environment, so that each of the target request instructions is executed in the test environment according to the request instruction message.

2. The method according to claim 1, characterized in that After receiving each request instruction input by the user, before sequentially determining the request identification code corresponding to each request instruction according to the input order of each request instruction input by the user, the method further includes: Get the preset request types; According to each of the request types, determining whether the request instruction is a first-level request instruction, each of the request types corresponding to each filling rule; If the request instruction is the first-level request instruction, all stored data in the data storage area corresponding to the user must be cleared first.

3. The method according to claim 1, characterized in that The step of sequentially determining the request identification code corresponding to each request instruction according to the order in which each request instruction is input by the user includes: Based on the input order of the user input, sequentially obtain each request information corresponding to each request instruction on the current terminal; The request identification code corresponding to each request instruction is generated according to each of the request information.

4. The method according to claim 2, characterized in that: The step of determining each log file corresponding to each request instruction according to each request identification code corresponding to each request instruction comprises: According to each of the filling rules corresponding to each of the request instructions, the request identification code corresponding to each of the request instructions is sequentially filled into the data storage area to obtain a target data storage area, wherein the target data storage area contains target data composed of each of the request identification codes; The target data is printed into each operation log corresponding to each request instruction, so as to obtain each log file corresponding to each log.

5. A fault recovery device based on freight rate request characteristics, characterized in that: include: A receiving unit, used to receive each request instruction input by a user; a determining unit, configured to determine, in sequence, a request identification code corresponding to each of the request instructions according to the order in which each of the request instructions is input by the user; A display unit, used to determine each log file corresponding to each request instruction according to each request identification code corresponding to each request instruction; A calling unit, used to call a preset maintenance system, obtain a request response result corresponding to each of the log files, and display it to the user. If the request response result shows that there is a fault problem, the request response result includes a target request identification code corresponding to the fault problem; a search unit, configured to search for each target log file corresponding to the target request identification code in all the log files if the target request identification code input by the user is received; A construction unit, configured to read the original request instruction text in each of the target log files, and construct a request instruction message corresponding to each target request instruction associated therewith according to each of the original request instruction texts; A sending unit is used to send the request instruction message to the test environment, so as to execute each of the target request instructions in the test environment according to the request instruction message.

6. The device according to claim 5, characterized in that Also includes: A first acquisition subunit, used to acquire each preset request type; A judging subunit, used for judging whether the request instruction is a first-level request instruction according to each of the request types, each of the request types corresponding to each filling rule; The clearing subunit is used to clear all the stored data in the data storage area corresponding to the user if the request instruction is the first-level request instruction.

7. The device according to claim 5, characterized in that The determining unit comprises: A second acquisition subunit, configured to sequentially acquire, based on the input order of the user input, each piece of request information corresponding to each request instruction on the current terminal; The generating subunit is used to generate the request identification code corresponding to each request instruction according to each request information.

8. The device according to claim 6, characterized in that The display unit comprises: A filling subunit is used to fill the request identification code corresponding to each request instruction into the data storage area in turn according to each filling rule corresponding to each request instruction, so as to obtain a target data storage area, wherein the target data storage area contains target data composed of each request identification code; The printing subunit is used to print the target data into each operation log corresponding to each request instruction to obtain each log file corresponding to each log.

9. A storage medium comprising a stored program, wherein: When the program is running, the device where the storage medium is located is controlled to execute the above-mentioned fault recovery method based on the freight rate request characteristics.

10. An electronic device, comprising one or more processing devices and a memory, on which one or more programs are stored, wherein when the one or more programs are executed by one or more processing devices, the one or more processing devices implement the above-mentioned fault recovery method based on freight rate request characteristics.

Images