Data verification method, device, electronic device and storage medium

Abstract

The present application relates to the field of data processing, and in particular to a data verification method, device, electronic device and storage medium for improving data verification efficiency and real-time performance, wherein the method comprises: obtaining data to be detected sent to a message queue by at least one business component, the data to be detected comprising a business identifier for indicating the business process to which the data to be detected belongs; selecting data to be detected with the same business identifier from the message queue, and comparing the selected data to be detected to obtain a comparison result; if the comparison result is inconsistent, determining difference data based on the comparison result, and outputting the difference data determined based on the comparison result when the difference data meets a preset output condition. Since the present application obtains a comparison result by comparing the data to be detected sent by at least one business component, and outputs the difference data when the preset output condition is met, the data verification efficiency and real-time performance are effectively improved, and the implementation process is simple.

Description

Technical Field

[0001] The present application relates to the field of data processing, and in particular to a data verification method, device, electronic device and storage medium. Background Art

[0002] With the increasing popularity of the internet and the rise in its user base, online data exchange scenarios are becoming more common, necessitating data verification at specific times to identify errors. Data verification provides timely assurance of consistency between both parties' records. In more complex scenarios, multiple parties may be exchanging data simultaneously, placing higher demands on data verification methods.

[0003] Reconciliation methods commonly used in related technologies typically utilize batch processing, where all required documents are exported at fixed intervals and transmitted to the reconciling party, who then processes and verifies the data. This involves multiple steps, including data conversion. However, this data reconciliation method suffers from low processing efficiency and timeliness, high intermediate state storage costs, and a complex implementation process. Summary of the Invention

[0004] The embodiments of the present application provide a data verification method, device, electronic device and storage medium to improve the efficiency and real-time performance of data verification.

[0005] The present invention provides a data verification method, including:

[0006] Acquire data to be detected sent to a message queue by at least one business component, wherein the data to be detected includes a business identifier for indicating a business process to which the data to be detected belongs;

[0007] Selecting data to be detected with the same service identifier from the message queue, and comparing the selected data to be detected to obtain a comparison result;

[0008] If the comparison results are inconsistent, the difference data determined based on the comparison results is output when the difference data meets a preset output condition.

[0009] In the above embodiment, by obtaining the data to be tested sent to the message queue by at least one business component, the data to be tested with the same business identifier is selected from the message queue for comparison, and the comparison result is obtained. When the difference data meets the preset output conditions, the difference data determined based on the comparison result is output. The streaming reconciliation method is adopted to allow multiple parties to participate in the reconciliation, and reconciliation can be performed concurrently and in real time. It has multiple characteristics such as stability and scalability, effectively improving the efficiency and real-time performance of data reconciliation, and the implementation process is simple.

[0010] In an optional embodiment, each business component is a real-time business component or a non-real-time business component, and each message queue is a real-time component message queue or a non-real-time component message queue; and obtaining the data to be detected sent to the message queue by at least one business component includes:

[0011] If the at least one service component is a real-time service component, then obtaining the to-be-detected data sent in real time by each real-time service component to its corresponding real-time message queue; or

[0012] If the at least one business component includes at least one real-time business component and at least one non-real-time business component, then the data to be detected sent in real time by each real-time business component to its corresponding real-time message queue, as well as the data files to be detected sent in batches by each non-real-time business component to the non-real-time component message queue are obtained, and each data file to be detected includes the data to be detected corresponding to a non-real-time business component in this batch.

[0013] In the above embodiment, the data to be detected is sent to the message queue in real time through the real-time business component. For the non-real-time business component that cannot send the data to be detected to the message queue in real time, the data to be detected is stored in batches in the data file to be detected and periodically unloaded to the importing party. This makes the data verification method in this application compatible with real-time business components and non-real-time business components, improves the real-time efficiency of data verification, and simplifies the implementation process.

[0014] In an optional implementation, if the at least one business component is a real-time business component, determining whether the difference data meets the preset output condition is performed in the following manner:

[0015] Determine, based on the data processing progress of each real-time business component, a first timestamp corresponding to each real-time business component, where each first timestamp represents: the latest occurrence time of the business process to which each to-be-detected data sent by the corresponding real-time business component to the real-time component message queue belongs;

[0016] The smallest first timestamp among the determined first timestamps is used as the target timestamp;

[0017] If the second timestamp corresponding to the difference data is smaller than the target timestamp, it is determined that the preset output condition is met, and the second timestamp indicates the occurrence time of the business process to which the data to be detected corresponding to the difference data belongs.

[0018] In the above embodiment, the overall processing progress of the system is used to determine when to output the difference data, which can ensure that under normal circumstances, all data to be detected that is earlier than the target timestamp has been sent to the message queue. Therefore, the difference data whose second timestamp is earlier than the target timestamp can be output, avoiding the situation where the data to be detected that belongs to the same business process has not been sent to the message queue in full, but the data to be detected sent to the message queue has been output as difference data.

[0019] In an optional implementation, the data to be detected in the data file to be detected is sorted in the order of occurrence time of the business process to which the data to be detected belongs.

[0020] In an optional implementation, if the at least one service component includes at least one real-time service component and at least one non-real-time service component, determining whether the difference data meets the preset output condition is performed in the following manner:

[0021] Based on the data processing progress of each real-time business component, determine a first timestamp corresponding to each real-time business component and a third timestamp corresponding to each non-real-time business component, wherein the first timestamp indicates the latest occurrence time of the business process to which each to-be-detected data sent by the corresponding real-time business component to the real-time component message queue belongs, and the third timestamp indicates the latest occurrence time of the business process to which the to-be-detected data contained in the to-be-detected data file sent by the corresponding non-real-time business component to the non-real-time component message queue belongs;

[0022] If the minimum first timestamp of each real-time service component is greater than the maximum third timestamp of all non-real-time service components, and the data files to be detected sent by all non-real-time service components meet the preset import conditions, it is determined that the difference data meets the preset output conditions.

[0023] In the above embodiment, by comparing the minimum timestamp of the real-time business component with the maximum timestamp of the non-real-time business component, it is determined that the real-time business component has sent the transaction information of the batch to the system. By determining whether the preset import conditions are met, it is determined that the non-real-time business component has sent the transaction information of the batch to the system. This can avoid the situation where the difference data is output before all the transaction information of the batch is sent to the system, thereby improving the accuracy and real-time performance of data verification.

[0024] In an optional implementation, it is determined that all the data files to be detected sent by the non-real-time service components meet the preset import conditions in the following manner:

[0025] If the number of the data files to be detected to be received is consistent with the number of the data files to be detected obtained, the data files to be detected to be received are: files containing all the data to be detected that each non-real-time business component needs to send in this batch.

[0026] In an optional embodiment, when the difference data meets a preset output condition, the difference data determined based on the comparison result is output:

[0027] When the difference data meets a preset output condition and complies with a preset difference adjustment strategy, outputting the difference data to a first queue for difference adjustment;

[0028] When the difference data meets a preset output condition and does not comply with a preset difference adjustment strategy, the difference data is output to a second queue for difference confirmation.

[0029] The present invention provides a data verification device, comprising:

[0030] an acquiring unit, configured to acquire data to be detected sent to a message queue by at least one business component, wherein the data to be detected includes a business identifier for indicating a business process to which the data to be detected belongs;

[0031] A comparison unit, configured to select data to be detected having the same service identifier from the message queue, and compare the selected data to be detected to obtain a comparison result;

[0032] The output unit is configured to output the difference data determined based on the comparison result if the comparison result is inconsistent, and output the difference data determined based on the comparison result when the difference data meets a preset output condition.

[0033] Optionally, each business component is a real-time business component or a non-real-time business component, and each message queue is a real-time component message queue or a non-real-time component message queue. The acquiring unit is specifically configured to:

[0034] If the at least one service component is a real-time service component, then obtaining the to-be-detected data sent in real time by each real-time service component to the corresponding real-time component message queue; or

[0035] If the at least one business component includes at least one real-time business component and at least one non-real-time business component, then the data to be detected sent in real time by each real-time business component to its corresponding real-time component message queue, as well as the data files to be detected sent in batches by each non-real-time business component to the non-real-time component message queue are obtained, and each data file to be detected includes the data to be detected corresponding to a non-real-time business component in this batch.

[0036] Optionally, the acquiring unit is specifically configured to:

[0037] The data to be detected in the data file to be detected are sorted in the order of occurrence time of the business processes to which the data to be detected belong.

[0038] Optionally, if the at least one service component includes at least one real-time service component and at least one non-real-time service component, the output unit determines whether the difference data meets the preset output condition in the following manner:

[0039] Based on the data processing progress of each real-time business component, determine a first timestamp corresponding to each real-time business component and a third timestamp corresponding to each non-real-time business component, wherein the first timestamp indicates the latest occurrence time of the business process to which each to-be-detected data sent by the corresponding real-time business component to the real-time component message queue belongs, and the third timestamp indicates the latest occurrence time of the business process to which the to-be-detected data contained in the to-be-detected data file sent by the corresponding non-real-time business component to the non-real-time component message queue belongs;

[0040] If the minimum first timestamp of each real-time service component is greater than the maximum third timestamp of all non-real-time service components, and the data files to be detected sent by all non-real-time service components meet the preset import conditions, it is determined that the difference data meets the preset output conditions.

[0041] Optionally, the acquisition unit is further configured to determine whether all the data files to be detected sent by the non-real-time service components meet the preset import condition by:

[0042] If the number of the data files to be detected to be received is consistent with the number of the data files to be detected obtained, the data files to be detected to be received are: files containing all the data to be detected that each non-real-time business component needs to send in this batch.

[0043] Optionally, the output unit is specifically configured to:

[0044] When the difference data meets a preset output condition and complies with a preset difference adjustment strategy, outputting the difference data to a first queue for difference adjustment;

[0045] When the difference data meets a preset output condition and does not comply with a preset difference adjustment strategy, the difference data is output to a second queue for difference confirmation.

[0046] An electronic device provided in an embodiment of the present application includes a processor and a memory, wherein the memory stores program code, and when the program code is executed by the processor, the processor performs the steps of any one of the above-mentioned data verification methods.

[0047] An embodiment of the present application provides a computer-readable storage medium, which includes program code. When the storage medium is run on an electronic device, the program code is used to enable the electronic device to execute the steps of any one of the above-mentioned data verification methods.

[0048] An embodiment of the present application provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps of any of the above-described data verification methods.

[0049] The beneficial effects of this application are as follows:

[0050] The embodiments of the present application provide a data verification method, device, electronic device and storage medium. Since the present application obtains the data to be detected sent to the message queue by at least one business component, selects the data to be detected with the same business identifier from the message queue for comparison, obtains the comparison result, and outputs the difference data determined based on the comparison result when the difference data meets the preset output conditions, adopts a streaming reconciliation method to allow multiple parties to participate in the verification, and can perform reconciliation concurrently and in real time. It has multiple characteristics such as stability and scalability, effectively improves the efficiency and real-time performance of data verification, and the implementation process is simple.

[0051] Other features and advantages of the present application will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the present application. The purposes and other advantages of the present application can be realized and obtained by the structures particularly pointed out in the written description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0053] Figure 1 A flowchart of a data verification method in an embodiment of the present application is shown;

[0054] Figure 2 This is a schematic diagram of a streaming reconciliation process in a common scenario in an embodiment of the present application;

[0055] Figure 3 This is a schematic diagram of a streaming reconciliation process in a special scenario in an embodiment of the present application;

[0056] Figure 4This is a structural diagram of a data verification device in an embodiment of the present application;

[0057] Figure 5 A schematic diagram of the hardware structure of an electronic device to which an embodiment of the present application is applied;

[0058] Figure 6 A schematic diagram of the hardware structure of another electronic device to which an embodiment of the present application is applied. DETAILED DESCRIPTION

[0059] To make the purpose, technical solutions, and advantages of the embodiments of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are part of the embodiments of the technical solutions of this application, but not all of them. Based on the embodiments described in this application document, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the technical solutions of this application.

[0060] The following is an introduction to some concepts involved in the embodiments of this application.

[0061] 1. In the embodiments of this application, the term "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. The character " / " generally indicates that the associated objects are in an "or" relationship.

[0062] 2. In the embodiments of the present application, the term "timestamp" is used to measure the progress of data processing. Through certain technical means, the time when the data is generated is authenticated, thereby verifying whether the data has been tampered with after generation. In the embodiments of the present application, the timestamp is used to indicate the authentication of the time at which a process is located.

[0063] 3. In the embodiments of the present application, the term "batch" is used to indicate that a batch of business processes occurs within the same time period. In the embodiments of the present application, data verification can be performed on the data to be tested corresponding to a batch of business processes.

[0064] The preferred embodiments of the present application are described below in conjunction with the drawings in the specification. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the present application and are not used to limit the present application. In addition, the embodiments and features in the embodiments of the present application can be combined with each other if there is no conflict.

[0065] The following uses the data verification method in this application for reconciling transaction information as an example to specifically introduce the data verification method in this application.

[0066] An online transaction system is usually composed of multiple functional components or modules. Every time a transaction flows through a component, it needs to be recorded in the component, and the account needs to be reconciled at a specific time to confirm whether there are any abnormal orders. For example, when a customer goes to a merchant to consume and uses electronic payment, the payment component will record an account in the system, and the collection component will also record an account in the system. Through reconciliation, it is possible to timely understand whether the accounts of both parties are consistent. If one party has paid but the other party has not received it, timely measures can be taken. It should be noted that the data verification method in this application is not only applicable to two-party data verification, but also applicable to any multi-party data verification scenario.

[0067] See Figure 1 FIG. 1 is a flow chart of a data verification method provided in an embodiment of the present application. The specific implementation process of the method is as follows:

[0068] S11: Obtaining data to be detected sent to a message queue by at least one business component;

[0069] Among them, the data to be tested includes a business identifier used to indicate the business process to which the data to be tested belongs. When the business process represents a transaction, the data to be tested is the transaction information of the transaction, including data that needs to be reconciled. The business identifier is the transaction serial number. The transaction serial number of a transaction in each business component is the same.

[0070] S12: selecting data to be detected with the same service identifier from the message queue, and comparing the selected data to be detected to obtain a comparison result;

[0071] Specifically, the data to be detected with the same business identifier in the message queue is compared, that is, the transaction information belonging to a transaction is compared according to the transaction serial number to obtain a comparison result.

[0072] S13: If the comparison results are inconsistent, determining difference data based on the comparison results, and outputting the difference data determined based on the comparison results when the difference data meets a preset output condition.

[0073] Specifically, if the comparison results are inconsistent, that is, the transaction information of a transaction in each business component is different, for example, when a transaction occurs between two parties, the transaction information at the payer shows a payment of 10 yuan, while the transaction information at the payee shows a payment of 8 yuan, that is, the transaction information is different. Such data to be tested will be used as difference data, and when the preset output conditions are met, the difference data will be output.

[0074] In the embodiments of the present application, the shortcomings of the traditional reconciliation method, such as cumbersome steps, long time consumption, low real-time performance, and difficulty in meeting the requirements of multi-party verification scenarios, are solved, and a simple, efficient, concurrent, and quasi-real-time streaming reconciliation method is proposed. This reconciliation method allows multiple parties to participate in the reconciliation, and while taking into account the normal reconciliation of the original components, it allows new components to be added to the multi-party reconciliation at minimal cost, and has multiple characteristics such as stability and scalability. In addition to reconciliation, this application is also applicable to any multi-party data verification scenario, which will not be repeated here. This application mainly uses reconciliation data verification as an example for illustration.

[0075] An optional implementation is to directly delete the data information to be tested if the comparison results are consistent;

[0076] Specifically, if the comparison results are consistent, that is, when a transaction occurs between two parties, the transaction information at the payer shows a payment of 10 yuan, and the transaction information at the payee shows a receipt of 10 yuan, then the data to be tested that is consistent with the comparison can be directly deleted from the storage unit to reduce storage resource usage.

[0077] In the embodiments of the present application, the service components are divided into: a real-time service component for sending the data to be detected to the message queue in real time, and a non-real-time service component for sending the data to be detected to the message queue in batches. The message queue is divided into: a real-time component message queue for receiving the data to be detected sent by the real-time service component in real time, and a non-real-time component message queue for receiving the data to be detected sent by the non-real-time service component in batches.

[0078] See Figure 2 , which is a schematic diagram of a stream reconciliation process in a common scenario in an embodiment of the present application, Figure 2 The business components in are all real-time business components, and the corresponding queues are real-time component message queues. Figure 2 The streaming reconciliation process in common scenarios in the embodiments of this application is specifically introduced.

[0079] The steps for streaming reconciliation in common scenarios are as follows:

[0080] Step 1: After successfully executing a transaction, the business component involved in reconciliation sends a message containing the reconciliation data to the message queue, using the globally unique transaction serial number as the key (keyword) of the reconciliation message;

[0081] Step 2: Aggregate the reconciliation messages from all participating reconciliation components into the Compare queue (the queue to be reconciled). To improve concurrent processing capabilities, the Compare queue can be further split into multiple partitioned sub-queues. Simply ensure that messages with the same key are routed to the same Compare queue partition during aggregation.

[0082] Step 3: The Compare Processor reads the reconciliation message, checks it according to the transaction serial number, and outputs the differences to the designated queue.

[0083] Specifically, it can be divided into four parts: data input, summary, output, and verification.

[0084] Specifically, in the data input section, after a successful transaction, the business component involved in reconciliation immediately sends a message to the message queue. The message contains the unique identifier of each data item (such as the transaction serial number) and the data to be reconciled. The unique identifier of a transaction is the same across all components, so the unique identifier can be used as the message key, routing data with the same key to the same compare queue.

[0085] An optional implementation is, if at least one of the business components is a real-time business component, obtaining the to-be-detected data sent in real time by each real-time business component to its corresponding real-time component message queue;

[0086] Specifically, when at least one business component is a real-time business component, after a transaction is successfully executed, the business components involved in the reconciliation, such as Figure 2 At least one of components A, B, and C sends the transaction-related information to be detected to its corresponding real-time component message queue.

[0087] For example, a transaction with transaction serial number 202109202224 is successfully executed. The components related to this transaction are component A and component B. Component A sends the transaction information related to this transaction to queue A, and component B sends the transaction information related to this transaction to queue B. The system aggregates the data in queues A and B into the Compare queue, and then the Compare Processor compares them.

[0088] In an embodiment of the present application, the transaction information of completed transactions is sent to the message queue in real time through the real-time business component to form unbounded and continuous data. There is no need to transmit data to a third party for verification, and concurrent verification is supported, thereby improving the efficiency and real-time performance of reconciliation processing.

[0089] The summary part refers to: summarizing the transaction information in the real-time component message queue to the Compare queue. The CompareProcessor uses the unique identifier of each data in the Compare queue as the key, and saves the status information (that is, the data to be tested) in the internal storage unit. The unit must have persistence and high availability capabilities. Every time there is new status information, it needs to be verified for data consistency with the existing status information according to the transaction serial number. If the verification is consistent, it means that all parties to the transaction have checked it correctly. If the consistency cannot be verified after reading all the input status information, it means that there is an accounting inconsistency in the transaction and subsequent accounting adjustments are required. In order to reduce storage resource usage, the status corresponding to this key can be deleted in the internal storage unit when the verification is consistent. When the preset output conditions are met, the status information remaining in the internal storage (that is, the transaction information that cannot be verified for consistency) is converted into a difference form and sent to the downstream queue.

[0090] The output part refers to the following: Since data in stream processing is unbounded and continuous, stateful operations must output results within a certain range (bounds), which is commonly referred to as a window in stream processing. The window is usually divided by the time of event occurrence. After data segmentation, the question of when to output the results needs to be addressed, which is called a trigger mechanism in stream processing. Outputting results can be done at a fixed periodicity, but there are risks of outputting results too early or too late. Outputting results too early can result in meaningless or even erroneous results, while outputting results too late can increase latency and reduce real-time performance.

[0091] Therefore, if the system can perceive the progress of data processing and the completion of the current window, it can perfectly obtain accurate messages with a single output. That is, the system can output messages only after it is sure that a window will not receive any more messages. This indicator of data processing progress is time, which is used to indicate the time when the data occurred.

[0092] For stream processing systems with a single business component input (i.e., no merging or branching), timestamps can be used to determine the timing of result output. However, for stream processing scenarios with multiple data sources, timestamp information must be maintained separately after data aggregation because the processing progress of multiple components is unrelated. For example, the timestamp of component A may be 3:00 PM, while the timestamp of component B may still be 10:00 AM.

[0093] Under the premise that all business components are connected to the stream processing, the window closing can be promoted by the timestamp. This application collects the timestamps of each business component to obtain the overall timestamp of the current system. When the timestamp of the state information left in the internal storage unit is less than the overall timestamp of the current system, it means that no messages before the overall timestamp will be received. Then the state information can be converted into a difference form and sent to the downstream queue.

[0094] In an optional implementation, if at least one of the business components is a real-time business component, determining whether the difference data meets the preset output condition is performed in the following manner:

[0095] Based on the data processing progress of each real-time business component, the first timestamp corresponding to each real-time business component is determined, and each first timestamp represents: the latest occurrence time of the business process to which the data to be detected belongs, which is sent by the corresponding real-time business component to the real-time component message queue; the smallest first timestamp among the determined first timestamps is used as the target timestamp; if the second timestamp corresponding to the difference data is smaller than the target timestamp, it is determined that the preset output condition is met, and the second timestamp represents the occurrence time of the business process to which the data to be detected corresponding to the difference data belongs.

[0096] Specifically, first, the data processing progress of each business component is represented by the first timestamp, and then the first timestamps of each business component are compared, and the smallest first timestamp is used as the target timestamp, which means the current overall processing progress of the system. Finally, if the second timestamp of the difference data is less than the target timestamp, it is determined that the preset output conditions are met and the difference data can be output.

[0097] For example, if the latest transaction information sent to the message queue by component A occurs at 10 o'clock, then the first timestamp of component A is 10 o'clock; if the latest transaction information sent to the message queue by component B occurs at 9 o'clock, then the first timestamp of component B is 9 o'clock; if the latest transaction information sent to the message queue by component C occurs at 11 o'clock, then the first timestamp of component C is 11 o'clock. Therefore, the target timestamp is 9 o'clock, indicating that the current processing progress of the system is 9 o'clock. All the difference data in the system with a second timestamp earlier than 9 o'clock can be output.

[0098] In an embodiment of the present application, the overall processing progress of the system is used to determine when to output the difference data, which can ensure that under normal circumstances, all transaction information earlier than the target timestamp has been sent to the message queue. Therefore, the difference data whose second timestamp is earlier than the target timestamp can be output, avoiding the situation where the transaction information related to a transaction is not fully sent to the message queue, but the transaction information sent to the message queue is output as difference data.

[0099] The verification process involves: if the data between any two components A, B, or C is inconsistent, it indicates a discrepancy in the transaction. You can output the overall discrepancy or the pairwise discrepancies as needed. Depending on the discrepancy, this application can output data to different queues. If the discrepancy results can be directly submitted to downstream account adjustments, they are output to the pending adjustments queue. If the discrepancy results require further confirmation, they are output to the pending confirmation queue.

[0100] An optional implementation is that when the difference data meets the preset output conditions and complies with the preset difference adjustment strategy, the difference data is output to a first queue for difference adjustment; when the difference data meets the preset output conditions and does not comply with the preset difference adjustment strategy, the difference data is output to a second queue for difference confirmation.

[0101] Among them, compliance with the preset difference adjustment strategy means that the difference results can be directly handed over to the downstream for accounting adjustment, while non-compliance with the preset difference adjustment strategy means that the difference results need further confirmation and cannot be directly handed over to the downstream for accounting adjustment.

[0102] In addition, when the first timestamp of some or all business components cannot be obtained, or under other abnormal circumstances, the system cannot determine the output time and the system cannot store the difference data indefinitely, it can be set: if the output time cannot be determined within the preset time, the difference data can also be further output to the second queue for difference data confirmation.

[0103] See Figure 3 As shown, it is a flow chart of the reconciliation process in a special scenario in the embodiment of the present application. Figure 3 The streaming reconciliation process in special scenarios in the embodiments of this application is described in detail.

[0104] In some cases, due to the high cost of access stream processing, some systems cannot access transaction information to the message queue in real time, such as Figure 3 As shown, Figure 3 The reconciliation process of four components is described only as an example. The actual situation may include more real-time components that can access transaction information to the message queue in real time and non-real-time components that cannot access in real time, which are also within the scope of application of this application.

[0105] The steps for streaming reconciliation in special scenarios are as follows:

[0106] Step 1: After a successful transaction, the real-time component that connects transaction information to the message queue sends a message containing reconciliation data to the message queue. The non-real-time component, which cannot connect transaction information to the message queue in real time, uses a periodic unloading method to transfer the detailed files to the importer, who then imports them into the stream processing system.

[0107] Step 2: Aggregate the reconciliation messages of each participating reconciliation component into the queue to be reconciled ( Figure 3 To improve concurrent processing capabilities, the Compare queue can be further split into multiple partitioned sub-queues. It is only necessary to ensure that messages with the same key (key value) are routed to the same Compare queue partition during aggregation.

[0108] Step 3: The Compare Processor reads the reconciliation message, checks it according to the transaction serial number, and outputs the differences to the designated queue.

[0109] Similar to common scenarios, it can be divided into four parts: data input, summary, output, and verification.

[0110] Specifically, for components that cannot access transaction information in real time through the message queue, this application uses a periodic data unloading method to unload the data files to be tested to the importer, who then imports them into the stream processing system. Data must be verified by batch. The party that generates the batch number is responsible for batch switching and notifying relevant parties. Upon receiving the batch switch notification, the relevant parties are responsible for unloading the data and sending it to the verification party.

[0111] When a business component's data is sharded, multiple data files to be tested need to be unloaded. In this case, the importer needs to be informed of the total number of files that need to be unloaded in this batch. This is where the close file is used. The use of the close file must meet certain constraints:

[0112] 1. Each component and each batch must send a close file, otherwise the reconciliation system will not know whether the batch has not been traded or the data has not arrived;

[0113] 2. Each component can have only one file or multiple files for a batch of transactions, but the close file must record the number of files included in the batch;

[0114] 3. The transaction information in each data file must be sorted by timestamp.

[0115] As with normal output, the message content includes a unique identifier for each transaction (such as a transaction serial number) and the data to be reconciled. Because the unique identifier for a transaction is the same across all components, the unique identifier can be used as the message key, routing data with the same key to the same compare queue.

[0116] An optional implementation is that if at least one business component includes at least one real-time business component and at least one non-real-time business component, then the data to be tested sent in real time by each real-time business component to its corresponding real-time component message queue, as well as the data files to be tested sent in batches by each non-real-time business component to the non-real-time component message queue are obtained, and each data file to be tested includes the data to be tested corresponding to a non-real-time business component in this batch.

[0117] Specifically, when at least one service component includes at least one real-time service component and at least one non-real-time service component, for example Figure 3The real-time business component A and the non-real-time business components B, C, and D in the real-time business component send transaction information to the message queue in real time. The non-real-time business component stores the transaction information in the data file to be tested according to transaction batches, and then unloads it to the importer, which imports the transaction information into the message queue.

[0118] For example, the data that needs to be reconciled currently is between 9:00 and 10:00, that is, the batch of data that needs to be reconciled is from 9:00 to 10:00. The real-time business component has already connected the transaction information to the message queue in real time. The non-real-time business component needs to unload the data file to be tested that contains the batch of transaction information to the importer, and the importer sends it to the message queue.

[0119] In an embodiment of the present application, transaction information is sent to a message queue in real time through a real-time business component. For non-real-time business components that cannot send transaction information to a message queue in real time, the transaction information is stored in batches in a data file to be detected and periodically unloaded to the importing party. This makes the data verification method in the present application compatible with real-time business components and non-real-time business components, improves the real-time efficiency of data verification, and simplifies the implementation process.

[0120] In an optional implementation, the data to be detected in the data file to be detected are sorted in the order of occurrence time of the business processes to which the data to be detected belong.

[0121] Specifically, the transaction information in the data file to be detected is sorted in the order of the occurrence time of the transactions to which the transaction information belongs. For example, the transaction information occurring at 9:15 should be sorted before the transaction information occurring at 9:16.

[0122] In an optional implementation, it is determined that all the data files to be detected sent by the non-real-time service components meet the preset import conditions in the following manner:

[0123] If the number of the to-be-detected data files to be received is consistent with the number of the acquired to-be-detected data files, the to-be-detected data files to be received are files containing all the to-be-detected data that each non-real-time business component needs to send in this batch.

[0124] Specifically, while the non-real-time business component sends the data files to be tested in this batch to the importer, it can also send another file containing the number of data files to be tested that should be sent to the importer in this batch. The importer can determine whether the import of the data files to be tested in this batch has been completed based on the number of data files to be tested that should be received and the number of data files to be tested actually obtained.

[0125] The aggregation phase involves aggregating transaction information from the real-time and non-real-time component message queues into the compare queue. The compare processor uses the unique identifier of each entry in the compare queue as a key and stores the status information (i.e., the data to be checked) in an internal storage unit. This unit requires persistence and high availability. Each new entry is checked for consistency against the existing status information based on the transaction serial number. A consistent check indicates that all parties involved in the transaction have verified the transaction correctly. If consistency is still not achieved after reading all the input status information, this indicates an accounting inconsistency and requires subsequent accounting adjustments. To reduce storage resource usage, the status corresponding to the key is deleted from the internal storage unit upon verification. When the preset output conditions are met, the remaining status information in the internal storage (i.e., the transaction information that could not be verified) is converted into a difference format and sent to the downstream queue. Output: Using file import, precise definition is even more difficult. The output time cannot be determined by the timestamp of any single component, as files from other non-real-time business components may not have been uninstalled or imported yet. This application uses a monitoring method to monitor whether the import of the associated component files of the batch is completed. When a batch meets all the following conditions, the batch processing is considered complete:

[0126] 1. The message queue has received transaction information (any batch) from the real-time business component;

[0127] 2. The minimum timestamp of the real-time business component is greater than the maximum timestamp of all non-real-time business components in the batch (that is, it is possible that the real-time business component does not exist and has not yet added the transaction information to the message queue);

[0128] 3. All associated components of this batch have been imported;

[0129] 4. The batch did not receive any message within the specified time (configurable).

[0130] In an optional implementation, if the at least one service component includes at least one real-time service component and at least one non-real-time service component, whether the difference data satisfies a preset output condition is determined by:

[0131] Based on the data processing progress of each real-time business component, determine a first timestamp corresponding to each real-time business component and a third timestamp corresponding to each non-real-time business component, where the first timestamp indicates the latest occurrence time of the business process to which each to-be-detected data sent by the corresponding real-time business component to the real-time component message queue belongs, and the third timestamp indicates the latest occurrence time of the business process to which the to-be-detected data contained in the to-be-detected data file sent by the corresponding non-real-time business component to the non-real-time component message queue belongs;

[0132] If the smallest first timestamp of each real-time service component is greater than the largest third timestamp of all non-real-time service components, and the data files to be detected sent by all non-real-time service components meet the preset import conditions, it is determined that the difference data meets the preset output conditions.

[0133] Specifically, first, determine the first timestamp corresponding to each real-time business component and the third timestamp corresponding to each non-real-time business component. If the smallest first timestamp is greater than the largest third timestamp, it can be determined that the transaction information of this batch of the real-time business component has been sent to the message queue. And when the preset import conditions are met, that is, the transaction information of this batch of the non-real-time business component has also been sent to the message queue, it can be determined that the preset output conditions are met and the difference data can be output.

[0134] In an embodiment of the present application, by comparing the minimum timestamp of the real-time business component with the maximum timestamp of the non-real-time business component, it is determined that the real-time business component has sent the transaction information of the batch to the system. By determining whether the preset import conditions are met, it is determined that the non-real-time business component has sent the transaction information of the batch to the system. This can avoid the situation where the difference data is output before all the transaction information of the batch is sent to the system, thereby improving the accuracy and real-time performance of data verification.

[0135] The verification process involves: if the data between any two components A, B, C, or D is inconsistent, it indicates a discrepancy in the transaction. You can output the overall discrepancy or pairwise discrepancies as needed. Depending on the discrepancy, this application can output to different queues. If the discrepancy results can be directly submitted to downstream account adjustments, they are output to the pending adjustments queue. If the discrepancy results require further confirmation, they are output to the pending confirmation queue.

[0136] Based on the same inventive concept, the present application embodiment also provides a structural diagram of a data verification device. Figure 4 As shown, it is a structural diagram of the data verification device 400, which may include:

[0137] An acquiring unit 401 is configured to acquire data to be detected sent by at least one business component to a message queue, where the data to be detected includes a business identifier for indicating a business process to which the data to be detected belongs;

[0138] The comparison unit 402 is used to select the data to be detected with the same service identifier from the message queue, and compare the selected data to be detected to obtain a comparison result;

[0139] The output unit 403 is configured to output the difference data determined based on the comparison result if the comparison result is inconsistent, and when the difference data meets a preset output condition, output the difference data determined based on the comparison result.

[0140] Optionally, each business component is a real-time business component or a non-real-time business component, and each message queue is a real-time component message queue or a non-real-time component message queue. The acquiring unit 401 is specifically configured to:

[0141] If at least one of the business components is a real-time business component, then obtaining the data to be detected that is sent in real time by each real-time business component to its corresponding real-time component message queue; or

[0142] If at least one business component includes at least one real-time business component and at least one non-real-time business component, then the data to be tested sent in real time by each real-time business component to the corresponding real-time component message queue, as well as the data files to be tested sent in batches to the non-real-time component message queue by each non-real-time business component are obtained, and each data file to be tested includes the data to be tested corresponding to a non-real-time business component in this batch.

[0143] Optionally, the acquiring unit 401 is specifically configured to:

[0144] The data to be tested in the data file to be tested are sorted in the order of the occurrence time of the business process to which the data to be tested belong.

[0145] Optionally, if the at least one service component includes at least one real-time service component and at least one non-real-time service component, the output unit 403 determines whether the difference data meets the preset output condition by:

[0146] Based on the data processing progress of each real-time business component, determine a first timestamp corresponding to each real-time business component and a third timestamp corresponding to each non-real-time business component, where the first timestamp indicates the latest occurrence time of the business process to which each to-be-detected data sent by the corresponding real-time business component to the real-time component message queue belongs, and the third timestamp indicates the latest occurrence time of the business process to which the to-be-detected data contained in the to-be-detected data file sent by the corresponding non-real-time business component to the non-real-time component message queue belongs;

[0147] If the smallest first timestamp of each real-time service component is greater than the largest third timestamp of all non-real-time service components, and the data files to be detected sent by all non-real-time service components meet the preset import conditions, it is determined that the difference data meets the preset output conditions.

[0148] Optionally, the acquiring unit 401 is further configured to determine whether all the to-be-detected data files sent by the non-real-time service components meet the preset import condition by:

[0149] If the number of the to-be-detected data files to be received is consistent with the number of the acquired to-be-detected data files, the to-be-detected data files to be received are files containing all the to-be-detected data that each non-real-time business component needs to send in this batch.

[0150] Optionally, the output unit 403 is specifically configured to:

[0151] When the difference data meets the preset output conditions and complies with the preset difference adjustment strategy, the difference data is output to the first queue for difference adjustment;

[0152] When the difference data meets the preset output condition and does not meet the preset difference adjustment strategy, the difference data is output to the second queue for difference confirmation.

[0153] For the convenience of description, the above parts are divided into modules (or units) according to their functions and described separately. Of course, when implementing this application, the functions of each module (or unit) can be implemented in the same or multiple software or hardware.

[0154] Those skilled in the art will appreciate that various aspects of the present application can be implemented as systems, methods, or program products. Therefore, various aspects of the present application can be specifically implemented in the following forms: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or an implementation that combines hardware and software aspects, which may be collectively referred to herein as a "circuit," "module," or "system."

[0155] In some possible implementations, the data verification device according to the present application may include at least a processor and a memory. The memory stores program code, and when the program code is executed by the processor, the processor executes the steps of the data verification method according to various exemplary embodiments of the present application described in this specification. For example, the processor may execute the following steps: Figure 1 Follow the steps shown in .

[0156] Based on the same inventive concept as the above method embodiment, an electronic device is also provided in the embodiment of the present application. In one embodiment, the electronic device may be a server. In this embodiment, the structure of the electronic device may be as follows: Figure 5 As shown, it includes a memory 501 , a communication module 503 and one or more processors 502 .

[0157] Memory 501 is used to store computer programs executed by processor 502. Memory 501 may mainly include a program storage area and a data storage area. The program storage area may store an operating system and programs required for running instant messaging functions, while the data storage area may store various instant messaging messages and operating instruction sets.

[0158] Memory 501 may be a volatile memory, such as random-access memory (RAM); a non-volatile memory, such as read-only memory, flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 501 may be a combination of the above memories.

[0159] The processor 502 may include one or more central processing units (CPUs) or digital processing units, etc. The processor 502 is configured to implement the above-mentioned data verification method when calling the computer program stored in the memory 501 .

[0160] The communication module 503 is used to communicate with terminal devices and other servers.

[0161] The specific connection medium between the memory 501, the communication module 503 and the processor 502 is not limited in the embodiment of the present application. Figure 5 In the embodiment, the memory 501 and the processor 502 are connected via a bus 504. Figure 5 The connections between the other components are shown in bold lines, which are only for illustration and are not intended to be limiting. The bus 504 can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, Figure 5 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0162] The memory 501 stores a computer storage medium, which stores computer executable instructions. The computer executable instructions are used to implement the data verification method of the embodiment of the present application. The processor 502 is used to execute the above-mentioned data verification method, such as Figure 1 Follow the steps shown in .

[0163] In another embodiment, the electronic device may also be other electronic devices. In this embodiment, the structure of the electronic device may be as follows: Figure 6 As shown, it includes: a communication component 610, a memory 620, a display unit 630, a camera 640, a sensor 650, an audio circuit 660, a Bluetooth module 670, a processor 680 and other components.

[0164] The communication component 610 is used to communicate with the server. In some embodiments, it may include a wireless fidelity (WiFi) module. The WiFi module is a short-range wireless transmission technology. Electronic devices can help users send and receive information through the WiFi module.

[0165] The memory 620 can be used to store software programs and data. The processor 680 executes various functions and data processing of the terminal device 60 by running the software programs or data stored in the memory 620. The memory 620 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 volatile solid-state storage device. The memory 620 stores the operating system that enables the terminal device 60 to run. In the present application, the memory 620 can store the operating system and various application programs, and may also store code for executing the data verification method of the embodiment of the present application.

[0166] The display unit 630 can also be used to display information input by the user or provided to the user, as well as a graphical user interface (GUI) for various menus of the terminal device 60. Specifically, the display unit 630 may include a display screen 632 disposed on the front of the terminal device 60. The display screen 632 may be configured in the form of a liquid crystal display, a light-emitting diode, etc. The display unit 630 can be used to display interfaces related to multimedia information recommendation in the embodiments of the present application, etc.

[0167] The display unit 630 can also be used to receive input digital or character information and generate signal input related to the user settings and function control of the terminal device 60. Specifically, the display unit 630 may include a touch screen 631 arranged on the front of the terminal device 60, which can collect user touch operations on or near it, such as clicking a button, dragging a scroll box, etc.

[0168] The touch screen 631 can be covered on the display screen 632, or the touch screen 631 and the display screen 632 can be integrated to realize the input and output functions of the terminal device 60. The integrated touch screen can be simply called a touch display screen. In this application, the display unit 630 can display applications and corresponding operation steps.

[0169] The camera 640 can be used to capture still images, and users can upload comments on the images captured by the camera 640 through the video client. There can be one or more cameras 640. The object generates an optical image through the lens and projects it onto the photosensitive element. The photosensitive element can be a charge coupled device (CCD) or a complementary metal-oxide-semiconductor (CMOS) phototransistor. The photosensitive element converts the light signal into an electrical signal, and then transmits the electrical signal to the processor 680 to convert it into a digital image signal.

[0170] The terminal device may further include at least one sensor 650, such as an acceleration sensor 651, a distance sensor 652, a fingerprint sensor 653, and a temperature sensor 654. The terminal device may also be configured with other sensors such as a gyroscope, a barometer, a hygrometer, a thermometer, an infrared sensor, a light sensor, and a motion sensor.

[0171] The audio circuit 660, speaker 661, and microphone 662 provide an audio interface between the user and the terminal device 60. The audio circuit 660 can convert the received audio data into an electrical signal and transmit it to the speaker 661, which converts it into a sound signal for output. The terminal device 60 may also be equipped with a volume button for adjusting the volume of the sound signal. On the other hand, the microphone 662 converts the collected sound signal into an electrical signal, which is received by the audio circuit 660 and converted into audio data. The audio data is then output to the communication component 610 for transmission to, for example, another terminal device 60, or the audio data is output to the memory 620 for further processing.

[0172] The Bluetooth module 670 is used to exchange information with other Bluetooth devices having a Bluetooth module through the Bluetooth protocol. For example, the terminal device can establish a Bluetooth connection with a wearable electronic device (such as a smart watch) that also has a Bluetooth module through the Bluetooth module 670 to exchange data.

[0173] The processor 680 is the control center of the terminal device. It uses various interfaces and lines to connect various parts of the entire terminal. By running or executing software programs stored in the memory 620 and calling data stored in the memory 620, it performs various functions of the terminal device and processes data. In some embodiments, the processor 680 may include one or more processing units; the processor 680 may also integrate an application processor and a baseband processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the baseband processor mainly processes wireless communications. It is understandable that the above-mentioned baseband processor may not be integrated into the processor 680. In the present application, the processor 680 can run the operating system, application programs, user interface display and touch response, as well as the data verification method of the embodiment of the present application. In addition, the processor 680 is coupled to the display unit 630.

[0174] In some possible implementations, various aspects of the data verification method provided in the present application may also be implemented in the form of a program product, which includes program code. When the program product is run on a computer device, the program code is used to enable the computer device to perform the steps of the data verification method according to various exemplary embodiments of the present application described above in this specification. For example, the computer device may perform the following steps: Figure 1 Follow the steps shown in .

[0175] The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0176] The program product of the data verification method of the embodiment of the present application can be a portable compact disk read-only memory (CD-ROM) and include program code, and can be run on a computing device. However, the program product of the present application is not limited thereto. In this document, a readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with a command execution system, device, or device.

[0177] A readable signal medium may include a data signal transmitted in baseband or as part of a carrier wave, which carries readable program code. Such a transmitted data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with a command execution system, apparatus, or device.

[0178] The program code embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0179] The program code for performing the operations of the present application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, as a stand-alone software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0180] It should be noted that although several units or subunits of the device are mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, depending on the embodiment of the application, the features and functions of two or more units described above can be embodied in a single unit. Conversely, the features and functions of a single unit described above can be further divided and embodied by multiple units.

Claims

1. A data verification method, characterized in that: The method includes: Acquire data to be detected sent to a message queue by at least one business component, the data to be detected including a business identifier for indicating a business process to which the data to be detected belongs; each business component is a real-time business component or a non-real-time business component, and each message queue is a real-time component message queue or a non-real-time component message queue; Selecting data to be detected with the same service identifier from the message queue, and comparing the selected data to be detected to obtain a comparison result; If the comparison results are inconsistent, then based on the difference data determined by the comparison results, and when the difference data meets the preset output condition, outputting the difference data determined based on the comparison results; If the at least one service component includes at least one real-time service component and at least one non-real-time service component, determining whether the difference data meets the preset output condition is performed in the following manner: Based on the data processing progress of each real-time business component, determine a first timestamp corresponding to each real-time business component and a third timestamp corresponding to each non-real-time business component, wherein the first timestamp indicates the latest occurrence time of the business process to which each to-be-detected data sent by the corresponding real-time business component to the real-time component message queue belongs, and the third timestamp indicates the latest occurrence time of the business process to which the to-be-detected data contained in the to-be-detected data file sent by the corresponding non-real-time business component to the non-real-time component message queue belongs; If the minimum first timestamp of each real-time service component is greater than the maximum third timestamp of all non-real-time service components, and the data files to be detected sent by all non-real-time service components meet the preset import conditions, it is determined that the difference data meets the preset output conditions.

2. The method according to claim 1, wherein The obtaining of the data to be detected sent by at least one business component to the message queue includes: If the at least one service component is a real-time service component, then obtaining the to-be-detected data sent in real time by each real-time service component to the corresponding real-time component message queue; or If the at least one business component includes at least one real-time business component and at least one non-real-time business component, then the data to be detected sent in real time by each real-time business component to its corresponding real-time component message queue, as well as the data files to be detected sent in batches by each non-real-time business component to the non-real-time component message queue are obtained, and each data file to be detected includes the data to be detected corresponding to a non-real-time business component in this batch.

3. The method according to claim 2, wherein If the at least one service component is a real-time service component, determining whether the difference data meets the preset output condition is performed in the following manner: Determine, based on the data processing progress of each real-time business component, a first timestamp corresponding to each real-time business component, where each first timestamp represents: the latest occurrence time of the business process to which each to-be-detected data sent by the corresponding real-time business component to the real-time component message queue belongs; The smallest first timestamp among the determined first timestamps is used as the target timestamp; If the second timestamp corresponding to the difference data is smaller than the target timestamp, it is determined that the preset output condition is met, and the second timestamp indicates the occurrence time of the business process to which the data to be detected corresponding to the difference data belongs.

4. The method according to claim 2, wherein The data to be detected in the data file to be detected are sorted in the order of occurrence time of the business processes to which the data to be detected belong.

5. The method according to claim 1, wherein Use the following methods to ensure that all data files to be tested sent by non-real-time business components meet the preset import conditions: If the number of the data files to be detected to be received is consistent with the number of the data files to be detected obtained, the data files to be detected to be received are: files containing all the data to be detected that each non-real-time business component needs to send in this batch.

6. The method according to any one of claims 1 to 5, wherein: When the difference data meets the preset output condition, the difference data determined based on the comparison result is output: When the difference data meets a preset output condition and complies with a preset difference adjustment strategy, outputting the difference data to a first queue for difference adjustment; When the difference data meets a preset output condition and does not comply with a preset difference adjustment strategy, the difference data is output to a second queue for difference confirmation.

7. A data checking device, characterized in that: The device comprises: an acquiring unit, configured to acquire data to be detected sent to a message queue by at least one business component, the data to be detected including a business identifier for indicating a business process to which the data to be detected belongs; each business component is a real-time business component or a non-real-time business component, and each message queue is a real-time component message queue or a non-real-time component message queue; A comparison unit, configured to select data to be detected having the same service identifier from the message queue, and compare the selected data to be detected to obtain a comparison result; an output unit, configured to, if the comparison results are inconsistent, output the difference data determined based on the comparison results, and when the difference data satisfies a preset output condition, output the difference data determined based on the comparison results; If the at least one service component includes at least one real-time service component and at least one non-real-time service component, determining whether the difference data meets the preset output condition is performed in the following manner: Based on the data processing progress of each real-time business component, determine a first timestamp corresponding to each real-time business component and a third timestamp corresponding to each non-real-time business component, wherein the first timestamp indicates the latest occurrence time of the business process to which each to-be-detected data sent by the corresponding real-time business component to the real-time component message queue belongs, and the third timestamp indicates the latest occurrence time of the business process to which the to-be-detected data contained in the to-be-detected data file sent by the corresponding non-real-time business component to the non-real-time component message queue belongs; If the minimum first timestamp of each real-time service component is greater than the maximum third timestamp of all non-real-time service components, and the data files to be detected sent by all non-real-time service components meet the preset import conditions, it is determined that the difference data meets the preset output conditions.

8. An electronic device, characterized in that: The method comprises a processor and a memory, wherein the memory stores program codes, and when the program codes are executed by the processor, the processor executes the steps of any one of the methods of claims 1 to 6.

9. A computer-readable storage medium, characterized in that It includes program code. When the storage medium is run on an electronic device, the program code is used to enable the electronic device to execute the steps of any one of the methods in claims 1 to 6.

Images