Transaction log playback method, device, equipment and medium for distributed core system

Abstract

The present invention discloses a transaction log playback method, apparatus, device, and medium for a distributed core system. The method comprises: during desensitization processing, obtaining a log processing sequence number based on a transaction request timestamp field in a transaction log; wherein, if the transaction request times of different transaction logs are the same, the corresponding log processing sequence numbers are the same; processing the log processing sequence number based on a log processing parameter to obtain a log playback sequence number; wherein, the log playback sequence number is a continuous value, and each log playback sequence number corresponds to a transaction log. Compared with the prior art, the embodiment of the present invention is suitable for scenarios with large transaction volumes in a distributed core system, improves the success rate of transaction log playback, and enhances the efficiency and coverage of automated testing.

Description

Technical Field

[0001] Embodiments of the present invention relate to computer technology, and in particular to a transaction log playback method, apparatus, device, and medium for a distributed core system. Background Art

[0002] With the increasing application of internet technologies and the proliferation of new internet products, commercial banks and other financial institutions are facing fierce competition, accelerating product iterations. The speed of information system delivery is also accelerating, and financial operations are becoming increasingly complex and diverse. With the increasing emphasis on cybersecurity and financial security, large financial institutions are gradually implementing a de-IOE process, resulting in frequent changes in system architecture. These changes have placed higher demands on the efficiency and coverage of testing core financial systems.

[0003] Transaction log replay technology, among other things, can be used to verify that the functionality and performance of the program under test meet expectations, and has a wide range of applications. To ensure the success rate of transaction log replay, log replay must be performed in the order in which production transactions occurred. For example, if an account deposits and then withdraws funds, and if the test environment replays the withdrawal followed by the deposit, there's a chance that insufficient funds will be available at the time of the withdrawal, causing the transaction to fail. The transaction log number, as the key value in a transaction log record, uniquely identifies a log entry. In traditional centralized architectures, transaction log numbers are generated centrally, and the order of transaction replay is determined by the transaction log number. However, with the development of distributed technology, the architecture of core financial systems is gradually transitioning to a distributed architecture, and transaction log numbers are also generated in a distributed manner. Therefore, transaction log numbers can no longer determine the order in which transactions occurred. If log replay continues to be based on transaction log numbers, transaction success rates cannot be guaranteed.

[0004] Prior art 1 (publication number CN108829802A) provides a method and device for replaying associated logs. This method sequentially stores each application log after application classification based on business association relationships. This method has the following technical issues: first, it requires clear business association relationships, and the sorting rules for association relationships consume a lot of manpower; second, the sequential storage of each classified application log can be resource-intensive if the number of application logs is large.

[0005] Prior art 2 (publication number CN105825428A) provides a production simulation testing method and system for commercial banks. To ensure that transactions are issued in the exact order in which they occur, this method sorts the order based on transaction log numbers. This method is suitable for log playback in a centralized architecture, where the transaction log number can determine the order in which transactions occurred. However, with the implementation of a distributed architecture, transaction log numbers are generated in a distributed manner, making it impossible to determine the order in which transactions occurred based on transaction log numbers.

[0006] Existing transaction logs contain transaction request time information, which is the time the transaction was submitted to the core system. Prior art methods also sort transaction logs by request time to determine the order in which they are played back. This method is suitable for business scenarios with relatively low transaction volumes. However, large financial institutions currently experience hundreds of millions of daily transactions, and their transaction logs also contain hundreds of millions of records. Directly sorting by request time to determine the order in which transactions occurred can easily lead to database crashes due to resource exhaustion.

[0007] In summary, the existing transaction log playback method cannot be applied to scenarios with large transaction volumes in distributed core systems, which affects the success rate of transaction log playback, the efficiency and coverage of automated testing. Summary of the Invention

[0008] The present invention provides a transaction log playback method, device, equipment and medium for a distributed core system, which is suitable for scenarios with large transaction volumes in the distributed core system, improves the success rate of transaction log playback, and enhances the efficiency and coverage of automated testing.

[0009] In a first aspect, an embodiment of the present invention provides a transaction log playback method for a distributed core system, comprising:

[0010] Desensitizing sensitive information in each transaction log according to the log desensitization parameters; during the desensitization process, obtaining a log processing sequence number based on the transaction request timestamp field in the transaction log; if the transaction request times in different transaction logs are the same, the corresponding log processing sequence numbers are the same;

[0011] Processing the log processing sequence number according to the log processing parameter to obtain a log playback sequence number; wherein the log playback sequence number is a continuous value, and each log playback sequence number corresponds to one of the transaction logs;

[0012] The transaction logs to be replayed are obtained from the database one by one according to the log replay sequence number and sent to the system under test; wherein the log sending thread simulates concurrent transaction execution according to the concurrency number set by the log replay parameter.

[0013] Optionally, the method of performing desensitization treatment includes:

[0014] Desensitize sensitive information in transaction logs one by one;

[0015] Convert the transaction request timestamp field value into a 13-digit long integer value through a conversion function, and extract the first 10 digits of the value as the log processing sequence number;

[0016] The log processing sequence number is written back to the original transaction log as a newly added field.

[0017] Optionally, the conversion function is a SimpleDateFormat class conversion function.

[0018] Optionally, the log processing method includes:

[0019] Get the initial value of the log processing sequence number;

[0020] The transaction log is obtained in a loop with a step size of 1 starting from the initial value of the log processing sequence number, and a unique log playback sequence number is assigned to each transaction log record; wherein, if the transaction log record obtained by the log processing sequence number is not unique, the log playback sequence number is assigned to each record in ascending order according to the transaction request timestamp field.

[0021] Optionally, the method of assigning a unique log playback sequence number to each transaction log record includes:

[0022] Determine the starting position of log processing according to the initial value of the log processing sequence number;

[0023] Obtaining corresponding log records from the desensitized transaction log database table according to the log processing sequence number;

[0024] If the log record obtained by the current log processing sequence number is empty, the step of adding the log processing sequence number to 1 is executed; otherwise, the step of determining whether the log record is 1 is executed;

[0025] The step of judging whether the log record is 1: if the log record obtained by the current log processing sequence number is 1, the step of directly allocating the log playback sequence number is executed; otherwise, the step of allocating the log playback sequence number in order of transaction timestamp is executed;

[0026] The step of assigning log replay sequence numbers by transaction timestamp sorting includes assigning log replay sequence numbers to each transaction log in ascending order of transaction timestamps; wherein the log replay sequence number is a long integer, and after each transaction log is processed, the log replay sequence number is incremented by 1 and assigned to the next transaction log;

[0027] The step of directly assigning a log replay sequence number: assigning a unique log replay sequence number to each transaction log; wherein the log replay sequence number is a long integer, and after each transaction log is processed, the log replay sequence number is incremented by 1 and assigned to the next transaction log;

[0028] The step of adding 1 to the log processing sequence number: after adding 1 to the log processing sequence number, the step of obtaining the corresponding log record according to the log processing sequence number is returned until the log processing sequence number reaches the end value of the log processing sequence number.

[0029] Optionally, when processing the log processing sequence number, the method further includes:

[0030] The super-long log information is merged into a complete transaction log, and a unique continuous log playback sequence number is assigned to each log record; wherein the super-long log information refers to the log information registered in two database tables.

[0031] Optionally, after sending the transaction log to be replayed to the system under test, the method further includes:

[0032] Receive transaction return messages, and collect and display information contained in the messages; wherein the information contained in the messages includes at least one of: transaction playback success rate, error information, number of transactions executed per second, and response time.

[0033] In a second aspect, an embodiment of the present invention further provides a transaction log playback device for a distributed core system, comprising:

[0034] A log desensitization module is configured to desensitize sensitive information contained in each transaction log according to log desensitization parameters; during the desensitization process, a log processing sequence number is obtained based on the transaction request timestamp field in the transaction log; if different transaction logs have the same transaction request time, the corresponding log processing sequence numbers are the same;

[0035] a log processing module, configured to process the log processing sequence number according to the log processing parameter to obtain a log playback sequence number; wherein each log playback sequence number corresponds to one of the transaction logs;

[0036] The log playback module is used to obtain the transaction logs to be played back from the database one by one according to the log playback sequence number, and simulate sending them to the system under test according to the concurrency number set by the log playback parameters.

[0037] In a third aspect, an embodiment of the present invention further provides an electronic device, comprising:

[0038] one or more processors;

[0039] a storage device for storing one or more programs,

[0040] When the one or more programs are executed by the one or more processors, the one or more processors implement the transaction log playback method of the distributed core system as described in any embodiment of the present invention.

[0041] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the transaction log playback method of the distributed core system as described in any embodiment.

[0042] During the log desensitization process, the embodiments of the present invention convert transaction request times into transaction processing sequence numbers. During log processing, transaction replay sequence numbers are generated. During log replay, log messages are replayed according to the replay sequence numbers. The log desensitization process also incorporates a process for converting the transaction request timestamp field into transaction log processing sequence numbers. Since log desensitization itself requires traversing each transaction log entry, the embodiment of the present invention does not significantly increase transaction log processing time. A process for generating log replay sequence numbers is also added to the log processing process. This process retrieves transaction logs from the database according to the transaction processing sequence numbers, allowing for the acquisition of a large number of transaction logs. Traditional methods that determine transaction replay sequence by transaction log number require a database access for each log acquisition. Therefore, the embodiments of the present invention significantly reduce data access frequency, I / O times, system overhead, and significantly improve transaction log processing efficiency. During log replay, the transaction log replay sequence numbers can be used to determine the order in which transactions occurred, allowing transaction logs to be replayed in the order in which they actually occurred in a production environment. In summary, the embodiments of the present invention are advantageously applied to scenarios with large transaction volumes in distributed core systems. In particular, log playback can significantly reduce resource and time overhead when the average daily transaction volume of financial services reaches hundreds of millions of transactions, thereby improving the success rate of transaction log playback, automated testing efficiency, and coverage. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 A flowchart of a transaction log playback method for a distributed core system provided by an embodiment of the present invention;

[0044] Figure 2 A schematic diagram of a desensitization process provided by an embodiment of the present invention;

[0045] Figure 3 A schematic diagram of a log processing flow provided by an embodiment of the present invention;

[0046] Figure 4 A schematic diagram of a process for generating a transaction playback sequence number based on a transaction request time provided by an embodiment of the present invention;

[0047] Figure 5 A flowchart of another transaction log playback method of a distributed core system provided by an embodiment of the present invention;

[0048] Figure 6 A flowchart of a transaction log playback method for a distributed core system provided by an embodiment of the present invention;

[0049] Figure 7 A schematic diagram of the structure of a transaction log playback device for a distributed core system provided by an embodiment of the present invention;

[0050] Figure 8 A schematic diagram of the structure of another transaction log playback device of a distributed core system provided by an embodiment of the present invention;

[0051] Figure 9 A schematic structural diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0052] The present invention will be further described in detail below with reference to the accompanying drawings and examples. It will be understood that the specific embodiments described herein are intended only to illustrate the present invention and are not intended to limit the present invention. It should also be noted that, for ease of description, the accompanying drawings only illustrate portions relevant to the present invention, not all structures.

[0053] It should be noted that in the embodiments of the present invention, the acquisition, storage and / or processing of the transaction logs, log desensitization parameters, and log processing parameters involved comply with the relevant provisions of national laws and regulations and do not violate public order and good morals.

[0054] Figure 1 A flow chart of a transaction log replay method for a distributed core system provided in an embodiment of the present invention. A distributed core system refers to a system in which a group of computers are interconnected through a network to transmit messages and communicate, and coordinate their behaviors to provide unified external services. The business of the distributed core system is dispersed across multiple nodes, which work together to provide services. The distributed core system is physically dispersed and logically unified. Transaction log replay refers to desensitizing the transaction logs of the production environment and executing them in the test environment to verify whether the functions and performance of the program to be tested meet expectations. The transaction log replay technology first uses the desensitized production logs for testing, which is closer to the real production scenario and improves the test coverage; second, it performs automated playback by setting a certain number of concurrency, which improves the test efficiency; third, a log replay can take into account both functional testing and performance testing, and has a wide range of applications.

[0055] The transaction log playback method provided by the embodiment of the present invention is applicable to application scenarios with large transaction volumes. The transaction log playback method can be executed by a transaction log playback device of a distributed core system, which can be implemented by software and / or hardware. Figure 1 , the transaction log playback method includes the following steps:

[0056] S110. Desensitize the sensitive information involved in each transaction log according to the log desensitization parameter; during the desensitization process, obtain a log processing sequence number according to the transaction request timestamp field in the transaction log.

[0057] If the transaction request time is the same for different transaction logs, the corresponding log processing sequence numbers will be the same, meaning that one log processing sequence number can correspond to multiple transaction logs. This is because the log processing sequence number derived from the transaction request timestamp field truncates the transaction request timestamp field. The more transactions that occur within a given time period, the more transaction logs a log processing sequence number corresponds to. For example, during log desensitization, a 10-digit long integer value generated from the transaction request timestamp is used as the log processing sequence number. For example, the interval between log processing sequence numbers is in seconds. In subsequent step S120, if transaction logs are retrieved from the database based on the transaction processing sequence number, an average of 11,574 log entries are retrieved each time (assuming an average daily transaction volume of 1 billion transactions, evenly distributed over 3,600 seconds per day). In contrast, the traditional method of determining transaction playback order based on transaction log numbers requires a database access for each transaction log entry. Taking the processing time for 100 million transaction logs as an example, the processing time can be reduced from the traditional 12 hours to 2.4 hours. Therefore, the embodiments of the present invention significantly reduce the frequency of data access, reduce the number of IOs, reduce system overhead, and significantly improve log processing efficiency.

[0058] A transaction refers to the basic logical unit of work involved in executing financial services. A transaction log is a record of transaction status, time, audit information, and message information recorded in a database log table by a financial institution. Each transaction log is associated with a transaction log number, which uniquely identifies the transaction and is typically a long integer. Log desensitization involves replacing sensitive information in transaction logs generated in production environments with non-sensitive information using a specific algorithm.

[0059] S120. Process the log processing sequence number according to the log processing parameter to obtain a log playback sequence number. The log playback sequence number is a continuous value, and each log playback sequence number corresponds to a transaction log.

[0060] Log processing refers to the process of acquiring and desensitizing transaction logs in transaction log playback technology. After obtaining and desensitizing transaction logs, the logs must be processed before they can be replayed in a test environment. A log replay sequence number is a continuous value generated during log processing based on the order in which transactions occurred. It uniquely identifies each log entry and is typically a long integer. This log replay sequence number serves as the key for retrieving transaction logs from the database during log replay.

[0061] S130. Obtain the transaction logs to be replayed from the database one by one according to the log replay sequence number, and send them to the system under test; wherein the log sending thread simulates concurrent transaction execution according to the concurrency number set by the log replay parameter.

[0062] During the log desensitization process, the embodiments of the present invention convert transaction request times into transaction processing sequence numbers. During log processing, transaction replay sequence numbers are generated. During log replay, log messages are replayed according to the replay sequence numbers. The log desensitization process also incorporates a process for converting the transaction request timestamp field into transaction log processing sequence numbers. Since log desensitization itself requires traversing each transaction log entry, the embodiment of the present invention does not significantly increase transaction log processing time. A process for generating log replay sequence numbers is also added to the log processing process. This process retrieves transaction logs from the database according to the transaction processing sequence numbers, allowing for the acquisition of a large number of transaction logs. Traditional methods that determine transaction replay sequence by transaction log number require a database access for each log acquisition. Therefore, the embodiments of the present invention significantly reduce data access frequency, I / O times, system overhead, and significantly improve transaction log processing efficiency. During log replay, the transaction log replay sequence numbers can be used to determine the order in which transactions occurred, allowing transaction logs to be replayed in the order in which they actually occurred in a production environment. In summary, the embodiments of the present invention are advantageously applied to scenarios with large transaction volumes in distributed core systems. In particular, log playback can significantly reduce resource and time overhead when the average daily transaction volume of financial services reaches hundreds of millions of transactions, thereby improving the success rate of transaction log playback, automated testing efficiency, and coverage.

[0063] Based on the above embodiments, optionally, the transaction log playback method further includes: configuring parameters, wherein the parameters include at least one of log desensitization parameters, log processing parameters, and log playback parameters.

[0064] Figure 2 A schematic diagram of a desensitization process provided by an embodiment of the present invention. Figure 2 Based on the above embodiments, optionally, the method for performing desensitization treatment includes the following steps:

[0065] S111. Desensitize sensitive information in transaction logs one by one.

[0066] S112. Convert the transaction request timestamp field value into a 13-digit long integer value through a conversion function, and extract the first 10 digits of the value as the log processing sequence number.

[0067] The conversion function can, for example, be a SimpleDateFormat class conversion function. The SimpleDateFormat class is a native class in the Java JDK and is used to format or parse time. It can convert a timestamp value in a specified format into a long integer value. For example, the parsing function converts the transaction request timestamp value into the number of milliseconds since 00:00:00:00:00 on January 1, 1970. The converted value is a 13-digit long integer value. Taking the first 10 digits, the value represents the number of seconds since 00:00:00 on January 1, 1970. Therefore, the value of the log processing sequence number can determine the order in which transaction logs occur. If multiple transactions occur within one second, a single log processing sequence number value can correspond to multiple transaction logs. For example, the transaction request timestamp 2020-10-16 00:14:27.701000 represents 00:14:27:701 on October 16, 2020. The converted log processing sequence number 1602778467 represents the number of seconds between the current time and 0:00 on January 1, 1970.

[0068] S113. Write the log processing sequence number back to the original transaction log as a newly added field.

[0069] Through S111-S113, the step of converting the transaction request time into the transaction processing sequence number during the log desensitization process is implemented, which is conducive to application in scenarios with large transaction volumes in distributed core systems, and improves the success rate of transaction log playback, automated testing efficiency and coverage.

[0070] Figure 3 A flow chart of log processing provided by an embodiment of the present invention. Figure 3 Based on the above embodiments, the log processing method includes the following steps:

[0071] S121. Obtain the initial value of the log processing sequence number.

[0072] The initial value of the log processing sequence number can be set by the user.

[0073] S122. Transaction logs are acquired in a loop with a step size of 1, starting from the initial value of the log processing sequence number, and a unique log playback sequence number is assigned to each transaction log record. If the transaction log records acquired by the log processing sequence number are not unique, log playback sequence numbers are assigned to each transaction log record in ascending order according to the transaction request timestamp field.

[0074] Among them, for the desensitized transaction logs, a unique log playback sequence number is assigned to each transaction log to be replayed, which serves as the unique identifier for the log playback module to obtain the log record, thereby ensuring that the transaction logs are replayed in the chronological order of the transactions.

[0075] S121-S122 implements the step of generating transaction replay sequence numbers during log processing, which is beneficial for application in scenarios with large transaction volumes in distributed core systems, and improves the success rate of transaction log replay, automated testing efficiency, and coverage.

[0076] Figure 4 A flow chart of generating a transaction playback sequence number based on the transaction request time provided by an embodiment of the present invention. Figure 4 Based on the above embodiments, the method for generating a transaction playback sequence number based on the transaction request time includes the following steps:

[0077] S200, log desensitization process, including: S210, S220 and S230.

[0078] S210. Extracting the transaction request timestamp field: Desensitizing sensitive information in the transaction log. When processing the transaction logs one by one in a loop, extracting the transaction request timestamp field.

[0079] S220, SimpleDateFormat class conversion: Convert the transaction request timestamp field value into a 13-digit long integer value using the SimpleDateFormat class conversion function;

[0080] S230 , generating a log processing sequence number: extracting the first 10 digits of the 13-digit long integer value as the log processing sequence number.

[0081] S300 , log processing process, including: S310 , S320 , S330 , S340 , S350 , S360 , and S370 .

[0082] S310, obtaining the initial value of the log processing sequence number: determining the starting position of the log processing according to the initial value of the log processing sequence number.

[0083] S320, obtaining a log record corresponding to the initial value of the log processing sequence number: obtaining a corresponding log record from the desensitized transaction log database table according to the log processing sequence number.

[0084] S330, determine whether the log record is empty: if the log record obtained by the current log processing sequence number is empty, execute S370; otherwise, execute S340.

[0085] If the log record obtained for the current log processing sequence number is empty, it means that no transaction occurred at the time point (for example, specific to the second) corresponding to the log processing sequence number. Therefore, step S370, where the log processing sequence number is increased by 1, is executed. If the log record obtained for the current log processing sequence number is not empty, it means that a transaction occurred at the time point (for example, specific to the second) corresponding to the log processing sequence number. Therefore, step S340, where the log record is determined to be 1, is executed.

[0086] S340, determine whether the log record is 1: If the log record obtained by the current log processing sequence number is 1, execute S360; otherwise, execute S350.

[0087] If the log record obtained by the current log processing sequence number is 1, it means that the current log processing sequence number corresponds to one transaction log. Therefore, S360 is executed to directly assign a log playback sequence number. If the log record obtained by the current log processing sequence number is not 1 (i.e., > 1), it means that the current log processing sequence number corresponds to two or more transaction logs. The transaction times of these transaction logs need to be sorted. Therefore, S350 is executed to assign log playback sequence numbers by transaction timestamp.

[0088] S350. Assigning log replay sequence numbers by transaction timestamp: Assigning log replay sequence numbers to each transaction log in ascending order of transaction timestamp. The log replay sequence number is a long integer. After each transaction log is processed, the log replay sequence number is incremented by 1 and assigned to the next transaction log.

[0089] S360. Directly assign a log replay sequence number: assign a unique log replay sequence number to each transaction log. The log replay sequence number is a long integer. After each transaction log is processed, the log replay sequence number is incremented by 1 and assigned to the next transaction log.

[0090] The log playback sequence number may be set to an initial value, and then incremented by one based on the initial value.

[0091] S370, log processing sequence number + 1: add 1 to the log processing sequence number and return to execute S320 until the log processing sequence number reaches the end value of the log processing sequence number.

[0092] Through S210-S230 and S310-S370, the transaction request time is converted into a transaction processing sequence number during the log desensitization process, and the transaction replay sequence number is generated during the log processing process. This is conducive to application in scenarios with large transaction volumes in distributed core systems, especially under conditions where the average daily transaction volume of financial services reaches hundreds of millions of transactions. Log replay can significantly reduce resource and time overhead, and improve the success rate of transaction log replay, automated testing efficiency and coverage.

[0093] Based on the above embodiments, the processing of log processing sequence numbers can optionally include: merging overlong log information into a complete transaction log, and assigning a unique, continuous log playback sequence number to each log record; wherein overlong log information refers to log information registered in two database tables. This configuration further improves the success rate of transaction log playback.

[0094] Figure 5 A flow chart of another transaction log playback method of a distributed core system provided by an embodiment of the present invention. Figure 5 Based on the above embodiments, optionally, after sending the transaction log to be replayed to the system under test, the method further includes: receiving a transaction return message and collecting and displaying the information contained in the message. Specifically, the transaction log replay method includes the following steps:

[0095] S410. Desensitize the sensitive information involved in each transaction log according to the log desensitization parameters. During the desensitization process, obtain a log processing sequence number based on the transaction request timestamp field in the transaction log. If the transaction request times of different transaction logs are the same, the corresponding log processing sequence numbers are the same.

[0096] S420: Process the log processing sequence number according to the log processing parameter to obtain a log playback sequence number; wherein the log playback sequence number is a continuous value, and each log playback sequence number corresponds to a transaction log.

[0097] S430. Obtain the transaction logs to be replayed from the database one by one according to the log replay sequence number, and send them to the system under test; wherein the log sending thread simulates concurrent transaction execution according to the concurrency number set by the log replay parameter.

[0098] S440: Receive a transaction return message, and collect and display information contained in the message; wherein the information contained in the message includes at least one of: transaction playback success rate, error information, number of transactions executed per second, and response time.

[0099] The number of transactions executed per second (TPS) starts when the client sends a request and ends when the server responds. This is used to calculate the time used and the number of completed transactions, and ultimately uses this information to evaluate the program under test.

[0100] Through S410-S440, a complete distributed core system transaction log playback method is implemented, which converts transaction request times into transaction processing sequence numbers during the log desensitization process, generates transaction replay sequence numbers during the log processing process, replays log messages according to the transaction replay sequence numbers during the log replay process, and performs statistical analysis on the program under test. This embodiment of the present invention is advantageously applicable to scenarios with large transaction volumes in distributed core systems, particularly when the average daily transaction volume of financial services reaches hundreds of millions of transactions. Log replay can significantly reduce resource and time overhead, thereby improving the success rate of transaction log replay, automated testing efficiency, and coverage.

[0101] Figure 6 A flow chart of another transaction log playback method of a distributed core system provided by an embodiment of the present invention. Figure 6 Based on the above embodiments, optionally, the transaction log playback method includes: S510, configuration parameters; S520, execution log desensitization; S530, execution log processing; S540, execution log playback; S550, statistical analysis.

[0102] Among them, S510, S520, S530, S540 and S550 can refer to the specific execution methods described in the aforementioned embodiments and will not be repeated here.

[0103] An embodiment of the present invention also provides a transaction log playback device for a distributed core system, which can be implemented by software and / or hardware and is used to execute the transaction log playback method for a distributed core system provided by any embodiment of the present invention, and has corresponding beneficial effects. Figure 7 A schematic diagram of the structure of a transaction log playback device for a distributed core system provided by an embodiment of the present invention. Figure 7 , the transaction log playback device includes:

[0104] Log desensitization module 610 is configured to desensitize sensitive information contained in each transaction log according to log desensitization parameters. During the desensitization process, a log processing sequence number is obtained based on the transaction request timestamp field in the transaction log. If different transaction logs have the same transaction request time, the corresponding log processing sequence numbers are the same.

[0105] The log processing module 620 is used to process the log processing sequence number according to the log processing parameters to obtain a log playback sequence number; wherein each log playback sequence number corresponds to a transaction log;

[0106] The log playback module 630 is used to obtain the transaction logs to be played back from the database one by one according to the log playback sequence number, and simulate sending them to the system under test according to the concurrency number set by the log playback parameters.

[0107] In this embodiment of the present invention, the log desensitization module 610 converts the transaction request time into a transaction processing sequence number, generates a transaction replay sequence number in the log processing module 620, and performs log message replay according to the transaction replay sequence number in the log replay module 530. This embodiment of the present invention is advantageously applicable to scenarios with high transaction volumes in distributed core systems. In particular, log replay in financial services with an average daily transaction volume of hundreds of millions of transactions can significantly reduce resource and time overhead, thereby improving the success rate of transaction log replay, automated testing efficiency, and coverage.

[0108] Figure 8 A schematic diagram of the structure of another distributed core system transaction log playback device provided by an embodiment of the present invention. Figure 8 Optionally, the transaction log playback device of the distributed core system also includes: a statistical analysis module 640, which is used to receive transaction return messages and perform statistics and display on the information contained in the messages; wherein the information contained in the messages includes: at least one of transaction playback success rate, error information, number of transactions executed per second and response time.

[0109] Continue to see Figure 8 Optionally, the transaction log playback device further includes a management module 650: configured to provide user interaction functions, configure log desensitization parameters, log processing parameters, and log playback parameters, etc.

[0110] Optionally, the log desensitizing module is also used to: desensitize sensitive information in transaction logs one by one; convert the value of the transaction request timestamp field into a 13-digit long integer value through a conversion function, and truncate the first 10 digits of the value as the log processing sequence number; and write the log processing sequence number back to the original transaction log as a newly added field.

[0111] Optionally, the conversion function is a SimpleDateFormat class conversion function.

[0112] Optionally, the log processing module is further used to: obtain an initial value of the log processing sequence number; start to obtain transaction logs in a loop with a step size of 1 based on the initial value of the log processing sequence number, and assign a unique log playback sequence number to each transaction log record; wherein, if the transaction log record obtained by the log processing sequence number is not unique, the log playback sequence number is assigned to each record in ascending order according to the transaction request timestamp field.

[0113] Optionally, the log processing module is further configured to:

[0114] Determine the starting position of log processing according to the initial value of the log processing sequence number;

[0115] Obtain the corresponding log record from the desensitized transaction log database table according to the log processing sequence number;

[0116] If the log record obtained by the current log processing sequence number is empty, execute the step of log processing sequence number + 1; otherwise, execute the step of judging whether the log record is 1;

[0117] The step of judging the log record as 1: If the log record obtained by the current log processing sequence number is 1, the step of directly assigning the log playback sequence number is executed; otherwise, the step of assigning the log playback sequence number by sorting by transaction timestamp is executed;

[0118] The steps of assigning log replay sequence numbers by transaction timestamp are as follows: Sort each transaction log in ascending order of transaction timestamps and assign a log replay sequence number. The log replay sequence number is a long integer. After each transaction log is processed, the log replay sequence number is incremented by 1 and assigned to the next transaction log.

[0119] Directly assigning log replay sequence numbers: Assign a unique log replay sequence number to each transaction log. The log replay sequence number is a long integer. After each transaction log is processed, the log replay sequence number is incremented by 1 and assigned to the next transaction log.

[0120] Log processing sequence number + 1 step: after adding 1 to the log processing sequence number, execute the step of obtaining the corresponding log record according to the log processing sequence number until the log processing sequence number reaches the end value of the log processing sequence number.

[0121] Optionally, the log processing module is further configured to merge overlong log information into a complete transaction log and assign a unique continuous log playback sequence number to each log record; wherein the overlong log information refers to the log information registered in the two database tables.

[0122] Figure 9 A schematic diagram of the structure of an electronic device provided by an embodiment of the present invention is shown in FIG. Figure 9 As shown, the device includes a processor 70, a memory 71, an input device 72 and an output device 73; the number of processors 70 in the device can be one or more. Figure 9 In the embodiment, a processor 70 is used as an example; the processor 70, the memory 71, the input device 72 and the output device 73 in the device can be connected by a bus or other means. Figure 9 The bus connection is taken as an example.

[0123] Memory 71, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as the program instructions / modules corresponding to the transaction log playback method of the distributed core system in the embodiments of the present invention (for example, the log desensitization module, log processing module, and log playback module in the transaction log playback device of the distributed core system). Processor 70 executes the software programs, instructions, and modules stored in memory 71 to execute various functional applications and data processing of the device, thereby implementing the transaction log playback method of the distributed core system described above.

[0124] The memory 71 may primarily include a program storage area and a data storage area. The program storage area may store an operating system and at least one application required for a function; the data storage area may store data created based on the use of the electronic device, etc. Furthermore, the memory 71 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state memory device. In some instances, the memory 71 may further include memory remotely located relative to the processor 70, and these remote memories may be connected to the device via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0125] The input device 72 may be used to receive input digital or character information and generate key signal input related to user settings and function control. The output device 73 may include a display device such as a display screen.

[0126] An embodiment of the present invention further provides a storage medium containing computer-executable instructions. When the computer-executable instructions are executed by a computer processor, the computer-executable instructions are used to perform a transaction log playback method for a distributed core system. The method includes:

[0127] Desensitize sensitive information in each transaction log based on the log desensitization parameters. During the desensitization process, a log processing sequence number is obtained based on the transaction request timestamp field in the transaction log. If different transaction logs have the same transaction request time, the corresponding log processing sequence numbers are the same.

[0128] The log processing sequence number is processed according to the log processing parameters to obtain the log playback sequence number. The log playback sequence number is a continuous value, and each log playback sequence number corresponds to a transaction log.

[0129] The transaction logs to be replayed are obtained from the database one by one according to the log replay sequence number and sent to the system under test; wherein, the log sending thread simulates concurrent transaction execution according to the concurrency number set by the log replay parameters.

[0130] Of course, the storage medium containing computer-executable instructions provided in an embodiment of the present invention is not limited to the above method operations, and can also execute related operations in the transaction log playback method of the distributed core system provided in any embodiment of the present invention.

[0131] Through the above description of the implementation methods, those skilled in the art can clearly understand that the present invention can be implemented with the help of software and necessary general-purpose hardware, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory (FLASH), hard disk or optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods of various embodiments of the present invention.

[0132] It is worth noting that in the embodiment of the transaction log playback device of the above-mentioned distributed core system, the various units and modules included are only divided according to functional logic, but are not limited to the above-mentioned division, as long as the corresponding functions can be achieved; in addition, the specific names of the functional units are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of the present invention.

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

Claims

1. A transaction log playback method for a distributed core system, characterized in that: include: Desensitize sensitive information in each transaction log based on log desensitization parameters; During the desensitization process, a log processing sequence number is obtained according to the transaction request timestamp field in the transaction log; wherein, if the transaction request times of different transaction logs are the same, the corresponding log processing sequence numbers are the same; Processing the log processing sequence number according to the log processing parameter to obtain a log playback sequence number; wherein the log playback sequence number is a continuous value, and each log playback sequence number corresponds to one of the transaction logs; Obtain the transaction logs to be replayed from the database one by one according to the log replay sequence number and send them to the system under test; wherein the log sending thread simulates concurrent transaction execution according to the concurrency number set by the log replay parameter; Methods of desensitization include: Desensitize sensitive information in transaction logs one by one; Convert the transaction request timestamp field value into a 13-digit long integer value through a conversion function, and extract the first 10 digits of the value as the log processing sequence number; Writing the log processing sequence number back to the original transaction log as a newly added field; Log processing methods include: Get the initial value of the log processing sequence number; The transaction log is obtained in a loop with a step size of 1 starting from the initial value of the log processing sequence number, and a unique log playback sequence number is assigned to each transaction log record; wherein, if the transaction log record obtained by the log processing sequence number is not unique, the log playback sequence number is assigned to each transaction log record in ascending order according to the transaction request timestamp field.

2. The transaction log playback method of the distributed core system according to claim 1, characterized in that: The conversion function is a SimpleDateFormat class conversion function.

3. The transaction log playback method of the distributed core system according to claim 1, characterized in that: Methods for assigning a unique log replay sequence number to each transaction log record include: Determine the starting position of log processing according to the initial value of the log processing sequence number; Obtain the corresponding log record from the desensitized transaction log database table according to the log processing sequence number; If the log record obtained by the current log processing sequence number is empty, the step of adding the log processing sequence number to 1 is executed; otherwise, the step of determining whether the log record is 1 is executed; The step of judging whether the log record is 1: if the log record obtained by the current log processing sequence number is 1, the step of directly allocating the log playback sequence number is executed; otherwise, the step of allocating the log playback sequence number in order of transaction timestamp is executed; The step of assigning log replay sequence numbers by transaction timestamp sorting includes assigning log replay sequence numbers to each transaction log in ascending order of transaction timestamps; wherein the log replay sequence number is a long integer, and after each transaction log is processed, the log replay sequence number is incremented by 1 and assigned to the next transaction log; The step of directly assigning a log replay sequence number: assigning a unique log replay sequence number to each transaction log; wherein the log replay sequence number is a long integer, and after each transaction log is processed, the log replay sequence number is incremented by 1 and assigned to the next transaction log; The step of adding 1 to the log processing sequence number: after adding 1 to the log processing sequence number, the step of obtaining the corresponding log record according to the log processing sequence number is returned until the log processing sequence number reaches the end value of the log processing sequence number.

4. The transaction log playback method of the distributed core system according to claim 1, characterized in that: When processing the log processing sequence number, the process further includes: The super-long log information is merged into a complete transaction log, and a unique continuous log playback sequence number is assigned to each log record; wherein the super-long log information refers to the log information registered in two database tables.

5. The transaction log playback method of the distributed core system according to claim 1, characterized in that: After sending the transaction log to be replayed to the system under test, the following steps are also included: Receive transaction return messages, and collect and display information contained in the messages; wherein the information contained in the messages includes at least one of: transaction playback success rate, error information, number of transactions executed per second, and response time.

6. A transaction log playback device for a distributed core system, characterized in that: include: The log desensitization module is used to desensitize sensitive information in each transaction log according to the log desensitization parameters; During the desensitization process, a log processing sequence number is obtained according to the transaction request timestamp field in the transaction log; wherein, if the transaction request times of different transaction logs are the same, the corresponding log processing sequence numbers are the same; a log processing module, configured to process the log processing sequence number according to the log processing parameter to obtain a log playback sequence number; wherein each log playback sequence number corresponds to one of the transaction logs; The log playback module is used to obtain the transaction logs to be played back from the database one by one according to the log playback sequence number, and simulate sending them to the system under test according to the concurrency number set by the log playback parameters; The log desensitization module is also used to: desensitize sensitive information in transaction logs one by one; convert the transaction request timestamp field value into a 13-digit long integer value through a conversion function, extract the first 10 digits as the log processing sequence number; and write the log processing sequence number back to the original transaction log as a new field; The log processing module is further configured to: obtain an initial value of a log processing sequence number; loop through transaction logs starting from the initial value of the log processing sequence number with a step size of 1, and assign a unique log playback sequence number to each transaction log record; if the transaction log records obtained by the log processing sequence number are not unique, assign log playback sequence numbers to each record in ascending order according to the transaction request timestamp field.

7. An electronic device, characterized in that: The electronic device comprises: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the transaction log playback method of the distributed core system as described in any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the transaction log playback method of the distributed core system as described in any one of claims 1 to 5 is implemented.

Images