Data consistency processing method, distributed storage system and electronic equipment

Abstract

The invention discloses a data consistency processing method, a distributed storage system and electronic equipment, and belongs to the field of distributed data storage systems, and the data consistency processing method comprises the following steps: when any storage node in the distributed storage system receives to-be-updated data sent by a client, obtaining a corresponding data updating path by taking the storage node as a first storage node; according to the data updating path, each storage node carries out data persistence on itself after receiving the data to be updated, if persistence succeeds, the data to be updated is transmitted to the next storage node, if persistence fails, data rollback is carried out, and feedback information of path updating failure is sent to the upstream of the data updating path; and after receiving the information, each upstream storage node carries out data rollback on the current updated data. According to the scheme, even if the update message processing flow fails, the consistency of the data between the survival copies / fragments can be ensured in real time.

Description

Technical Field

[0001] This application relates to the field of distributed data storage systems, specifically to a data consistency processing method, a distributed storage system, and an electronic device. Background Technology

[0002] Distributed storage systems employ replication / erasure coding redundancy to ensure user data reliability and storage system availability. Every data update message issued by the storage system is expected to be correctly stored across multiple storage media using replication / erasure coding redundancy. However, in production environments, network, software, or hardware issues inevitably prevent the data from being written to the storage media. This results in substantial inconsistencies between replicas / shards of the same data within the storage system. This violates the expected failure handling principle: failure in this case leads to overall system failure.

[0003] The following are some existing solutions for ensuring consistency of update message processing between replicas / shards in distributed storage systems.

[0004] In the existing solution 1, there is a master-slave relationship between replicas and shards (this concept is used in the following description of the solution and is a common industry practice). The client sends data update messages to the master. The master first performs its own data persistence processing. If the processing fails, it will directly reply to the client indicating the failure. If the master's persistence is successful, it will distribute the update message to the slave. After receiving the update message, the slave also performs data persistence processing. If the processing is successful, it can reply to the master indicating success. If the slave's data persistence fails, it will proactively terminate its own instance. Because each successful update message is logged on both the master and slave, after the slave terminates and comes back online, the missing data can be found by comparing the logs. Subsequently, a data reconstruction process is triggered to restore the missing data, ultimately ensuring data consistency between replicas / shards.

[0005] This solution has the following shortcomings: 1. The system heavily relies on logs, which inevitably lead to write amplification during data updates, thus impacting system performance. Additionally, logs consume extra system memory and storage space.

[0006] 2. Replica / erasure coding redundancy strategies ensure that even if the storage medium becomes inaccessible, data can still be accessed as long as it remains within the redundancy limit (similar to a three-replica system, but with only one or two replicas failing). This improves system availability and data reliability. Furthermore, data / metadata verification can be performed between replicas / shards, further enhancing data reliability. Generally, the more accessible replicas or erasure-coded shards, the higher the availability and data reliability; conversely, the lower the availability and data reliability. Therefore, proactively killing the instance upon data persistence failure will reduce system availability and data reliability.

[0007] 3. Originally, the responsibility of ensuring data consistency in distributed storage systems was the data update processing flow. However, this solution shifts this responsibility to the data reconstruction flow, which directly increases the coupling between the two independent processes.

[0008] In the existing second scheme, the client sends a data update message to the master. Both the master and slaves first create a transaction instance associated with this update message. After successful creation, the master directly distributes the update message to the slaves, allowing them to process the update message in parallel. After processing the update message, the slave replies with the processing result to the master. When the master collects the processing results from all replicas / shards (including itself), it obtains a final message processing result: if any replica / shard fails, the final result is failure; otherwise, it's success. If the final processing result is failure, the master sends a message to all slaves, and all slaves and the master set their transaction status to abort and then reply to the client with a failure message. If the final processing result is success, the master sets its transaction status to commit and replies to the client with a success message. Data updates associated with abort / commit transactions are further processed by the background process: in the abort state, the updated data is rolled back; in the commit state, the updated data is committed.

[0009] This solution has the following shortcomings: 1. Relying on the transaction module in the system backend, the original responsibility of ensuring data consistency in the distributed storage system was the data update processing flow. This solution transfers this responsibility to the transaction module without reducing the complexity of the data consistency processing logic.

[0010] 2. Transactions require persistence, which affects system performance. In addition, transactions will consume additional system memory and storage space.

[0011] 3. Before processing update messages, it is necessary to send messages to the transactions that created the association, which will increase the message volume of the distributed storage system.

[0012] 4. After the primary goes offline, if the transaction is not in a committed state, each slave cannot independently determine whether the transaction is in an aborted or committed state. It is necessary to re-elect a primary and collect the processing results of all replicas / shards to determine the transaction state.

[0013] In the existing third approach, the client distributes data update messages to all replicas / shards. Based on append-only write support, if a replica / shard write fails, a different set of replicas / shards receives the update message—achieved by switching objects. The backend process compares the object's length information across replicas / shards, prioritizing the shorter version. Replicas / shards with longer data revert to the shorter version, thus ensuring data consistency across replicas / shards.

[0014] 1. This solution requires a storage system and append-only write functionality to be implemented, and therefore lacks universal applicability.

[0015] 2. The data consistency processing result can only be determined by comparing the replicas / shards in the background. Summary of the Invention

[0016] This application provides a data consistency processing method, a distributed storage system, and an electronic device, which can solve the technical problems in the prior art, such as complex data update logic, cumbersome operation, large storage space requirements, and inability to guarantee data consistency in the message processing flow.

[0017] In a first aspect, embodiments of this application provide a data consistency processing method, the data consistency processing method comprising: When any storage node in a distributed storage system receives data to be updated sent by a client, it obtains the corresponding data update path with itself as the first storage node. The data update path contains multiple storage nodes. According to the data update path, each storage node persists its own data after receiving the data to be updated. If the persistence is successful, the data to be updated is transmitted to the next storage node. If the persistence fails, the data is rolled back and a path update failure feedback message is sent to the upstream of the data update path. After receiving the message, each upstream storage node rolls back the data to be updated.

[0018] In conjunction with the first aspect, in one embodiment, the data consistency processing method further includes: After the last storage node on the data update path receives the data to be updated and successfully persists its own data, it sends a feedback message indicating that the path update was successful to the upstream of the data update path.

[0019] In conjunction with the first aspect, in one embodiment, the data consistency processing method further includes: After receiving the feedback information, the first storage node sends the feedback information to the client.

[0020] In conjunction with the first aspect, in one implementation, the data update path is sent from the client to the first storage node; or The data update path is sent from the system backend of the distributed storage system to the first storage node.

[0021] In conjunction with the first aspect, in one embodiment, the data consistency processing method further includes: If any storage node does not receive a persistence result from the next storage node, it determines that the next storage node is offline and transmits the data to be updated to the first online storage node downstream along the data update path.

[0022] In conjunction with the first aspect, in one embodiment, the data consistency processing method further includes: A pre-set waiting time is used. If any storage node exceeds the waiting time and does not receive the persistence result from the next storage node, the next storage node is determined to be offline.

[0023] In conjunction with the first aspect, in one implementation, if there is an offline storage node in the data update path, the offline storage node is skipped when sending feedback information upstream.

[0024] Secondly, embodiments of this application provide a distributed storage system, which includes multiple storage nodes, wherein the storage nodes perform data consistency processing based on the method described above.

[0025] Thirdly, embodiments of this application provide an electronic device, which includes a processor, a memory, and a data consistency processing program stored in the memory and executable by the processor, wherein when the data consistency processing program is executed by the processor, it implements the steps of the data consistency processing method.

[0026] Fourthly, embodiments of this application provide a computer-readable storage medium storing a data consistency processing program, wherein when the data consistency processing program is executed by a processor, it implements the steps of the data consistency processing method.

[0027] The beneficial effects of the technical solutions provided in this application include: Each replica / shard involved in the data update message is treated as a processing node, and all nodes form a unidirectional link. The message is processed serially on each node according to the link order. After the last node completes its processing, it is replied in reverse order. Thus, each node can be aware of the overall processing result, completely avoiding the central point in terms of physical and logical meaning. Even if there is a failure in the update message processing flow, the failed node and all its upstream nodes can update the data and roll back, thereby ensuring the consistency of data among surviving replicas / shards in real time. Moreover, this solution does not reduce the data reliability and system availability of the distributed system.

[0028] This solution does not rely on any other modules to achieve message-guaranteed transaction consistency in a distributed system, which naturally avoids write amplification during updates and the problems of additional consumption of system memory / storage space or additional message requirements.

[0029] This solution ensures data consistency among surviving replicas / shards without requiring comparisons between replicas / shards.

[0030] This solution is highly applicable and does not rely on the storage system to use append-write features. Attached Figure Description

[0031] Figure 1 This is a flowchart illustrating an embodiment of the data consistency processing method of this application; Figure 2 This is a detailed flowchart illustrating the data consistency processing method of this application when each storage node successfully completes data persistence. Figure 3 This is a detailed flowchart illustrating the data consistency processing method of this application when a storage node fails to successfully complete data persistence. Figure 4 This is a detailed flowchart illustrating the data consistency processing method in this application when one storage node is offline. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0033] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0034] In a first aspect, embodiments of this application provide a data consistency processing method.

[0035] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the data consistency processing method of this application. Figure 1 As shown, the data consistency processing methods include: Step S1: When any storage node in the distributed storage system receives data to be updated sent by the client, it obtains the corresponding data update path with itself as the first storage node. The data update path contains multiple storage nodes. Step S2: Following the data update path, each storage node persists its own data after receiving the data to be updated. Step S3: Determine if persistence was successful. If so, proceed to step S4; If not, proceed to step S5; Step S4: Transfer the data to be updated to the next storage node; Step S5: Perform data rollback and send feedback information indicating path update failure to the upstream of the data update path. Upon receiving this information, each upstream storage node will roll back the updated data.

[0036] In this embodiment, the client sends a data update message to any storage node in the distributed storage system. The message contains the data to be updated. The storage node that receives the data update message is taken as the first node of the path. The corresponding data update path is retrieved. The data update path contains multiple storage nodes. All nodes form a unidirectional link. The data update message is processed serially along the data update path. After the last node completes its processing, it performs a reply in reverse. Thus, each node can perceive the overall processing result.

[0037] This solution completely avoids the physical and logical central point in its data consistency processing method. Even if there is a failure in the update message processing flow, the failed node and all its upstream nodes can update the data and roll back, thus ensuring the consistency of data among surviving replicas / shards in real time. Moreover, this solution will not reduce the data reliability and system availability of the distributed system.

[0038] The data consistency handling method of this scheme does not rely on any other modules to achieve message-guaranteed transaction consistency in the distributed system. This naturally avoids write amplification during updates and the problems of additional consumption of system memory / storage space or additional message requirements.

[0039] The data consistency handling method in this solution ensures data consistency among surviving replicas / shards without requiring comparisons between replicas / shards.

[0040] The data consistency handling method in this solution is highly applicable and does not rely on the storage system to have append-only write capabilities.

[0041] Furthermore, in one embodiment, the data consistency processing method further includes: Step S6: After the last storage node on the data update path receives the data to be updated and successfully persists its own data, it sends a feedback message indicating that the path update is successful to the upstream of the data update path.

[0042] In this embodiment, except for the last storage node, after successfully completing data persistence, any other storage node does not immediately reply with feedback information containing the persistence success result to the previous storage node. Instead, it simply sends the data to be updated to the next storage node. The reply process updates all storage nodes along the path. This is equivalent to only replying in reverse path direction after the last storage node on the path succeeds. That is, the last storage node is the first to send a reply message to its previous storage node. After receiving the reply, the previous storage node replies the result to the storage node before that previous storage node. This process continues in this manner until the first storage node receives a reply indicating successful processing. Only then will the first storage node reply with the successful processing information to the client.

[0043] Conversely, along the path, upon encountering the first storage node that fails to process the request, a failure reply is sent to the next upstream storage node in sequence, until the first storage node receives it, at which point a failure reply is sent to the client. Regardless of whether the update succeeds or fails, sending a reply to the upstream node only occurs when the overall path update is confirmed to have succeeded or failed.

[0044] In the current scheme, once the first node receives a reply, it considers that all replicas / shards have been processed. The processing result of the reply is the overall processing result, and it can then reply to the client.

[0045] Furthermore, in one embodiment, the data update path is sent from the client to the first storage node; or The data update path is sent from the system backend of the distributed storage system to the first storage node.

[0046] In this embodiment, the first storage node is determined by the client. The storage node to which the client sends the data update message becomes the first storage node. Other storage nodes on the data update path besides the first storage node can be determined by the client or by the system backend of the distributed storage system.

[0047] Furthermore, in one embodiment, after receiving the feedback information, the first storage node sends the feedback information to the client.

[0048] In one specific embodiment, refer to Figures 2 to 4 , Figure 2 This is a detailed flowchart illustrating the data consistency processing method in this application when all storage nodes successfully complete data persistence. Figure 3 This is a detailed flowchart illustrating the process when a storage node fails to successfully complete data persistence in the data consistency processing method of this application. Figure 4 This is a detailed flowchart illustrating the data consistency processing method in this application when one storage node is offline.

[0049] The client sends a data update message to the master ( Figure 2 In step 1.1), the message carries all replica / shard information involved in this data update message in the form of an array, with the master placed at the beginning of the array.

[0050] After receiving a data update message, any replica / shard (regardless of master / slave) persists the data itself. Figure 2 Steps 1.2, 1.4, and 1.6). After successful data persistence, data is sent to the next replica / shard in the order listed in the array, until the current role is the last replica / shard in the array. Figure 2 Steps 1.3 and 1.5).

[0051] The last copy / shard of the array has successfully completed data persistence. A reply needs to be sent to the previous copy / shard in the array to process the success. Figure 2 Step 1.7).

[0052] After any replica / shard (regardless of master / slave) receives a successful reply message, it will continue to process successful replies for the previous replica / shard in the array until the current role is master ( Figure 2 Step 1.8).

[0053] The existence of replicas / shards (without distinguishing between master and slave) has resulted in data persistence failure. Figure 3 Step 2.4) will require replying to the previous replica / shard in the array with an error ( Figure 3 (Step 2.5) If the current role is the master, then it is replyClient.

[0054] When any replica / shard (regardless of master / slave) receives a reply processing failure message, it first rolls back the data that was persisted in this instance. Figure 3 (Step 2.6). Then continue processing failures by replying to the previous copy / shard in the array until the current role is master.

[0055] The host receives the reply message and replies to the client with the processing result. Figure 2 Step 1.9 Figure 3 Step 2.7 Figure 4 Step 3.7).

[0056] Furthermore, in one embodiment, the data consistency processing method further includes: If any storage node does not receive a persistence result from the next storage node, it determines that the next storage node is offline and transmits the data to be updated to the first online storage node downstream along the data update path.

[0057] Furthermore, in one embodiment, the data consistency processing method further includes: A pre-set waiting time is used. If any storage node exceeds the waiting time and does not receive the persistence result from the next storage node, the next storage node is determined to be offline.

[0058] In one specific embodiment, continue to refer to Figures 2 to 4 For scenarios where replicas / shards are offline during processing, to prevent message chain interruption, any replica / shard that has not received a reply will detect that the next replica / shard in the array is offline and needs to resend an update message to the next online replica / shard (skipping offline replicas / shards). Figure 4 Step 3.4).

[0059] To address potential network anomalies such as packet loss during processing, and to prevent message link failures, a timeout period can be set for waiting for a reply when any replica / shard distributes a data update message to the next replica / shard. If no reply is received within the timeout period, the data update message is resent to the next online replica / shard.

[0060] In summary, existing solutions all share a common and significant characteristic: a central node plays a crucial role, distributing messages and participating throughout the entire process of confirming data update results. This solution, however, completely diminishes the role of the central node: each replica / shard involved in the data update message is treated as a processing node, with all nodes forming a unidirectional link. Messages are processed sequentially, node by node, following the link's order; after the last node completes its processing, a reply is sent in reverse order, ensuring that each node is aware of the overall processing result.

[0061] Secondly, embodiments of this application also provide a distributed storage system, the distributed storage system comprising: multiple storage nodes, the storage nodes performing data consistency processing based on the aforementioned data consistency processing method.

[0062] Each replica / shard involved in the data update message is treated as a processing node, and all nodes form a unidirectional link. The message is processed serially on each node according to the link order. After the last node completes its processing, it is replied in reverse order. Thus, each node can be aware of the overall processing result, completely avoiding the central point in terms of physical and logical meaning. Even if there is a failure in the update message processing flow, the failed node and all its upstream nodes can update the data and roll back, thereby ensuring the consistency of data among surviving replicas / shards in real time. Moreover, this solution does not reduce the data reliability and system availability of the distributed system.

[0063] This distributed storage system completely avoids a physical and logical central point. Even if there is a failure in the update message processing flow, the failed node and all its upstream nodes can update the data and roll back, thus ensuring the consistency of data among surviving replicas / shards in real time. Moreover, this solution will not reduce the data reliability and system availability of the distributed system.

[0064] The distributed storage system in this solution does not rely on any other modules to ensure transactional consistency of messages in the distributed system. This naturally avoids write amplification during updates and the problems of additional consumption of system memory / storage space or additional message requirements.

[0065] The distributed storage system in this solution guarantees data consistency among live replicas / shards without requiring comparisons between replicas / shards.

[0066] This solution has strong applicability to distributed storage systems and does not rely on storage systems that use append-only features.

[0067] Furthermore, in one embodiment, if any storage node does not receive the persistence result from the next storage node, it determines that the next storage node is offline and transmits the data to be updated to the first online storage node downstream along the data update path.

[0068] Furthermore, in one embodiment, a waiting time is preset, and if any storage node exceeds the waiting time and does not receive the persistence result from the next storage node, the next storage node is determined to be offline.

[0069] Furthermore, in one embodiment, if there is an offline storage node in the data update path, the offline storage node is skipped when sending feedback information upstream.

[0070] Thirdly, embodiments of this application provide an electronic device, which may be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.

[0071] In this embodiment of the application, the electronic device may include a processor, a memory, a communication interface, and a communication bus.

[0072] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0073] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used to interconnect devices within an electronic device, as well as interfaces used to interconnect the electronic device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0074] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0075] The processor can be a general-purpose processor, which can call a data consistency processing program stored in memory and execute the data consistency processing method provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the data consistency processing program is called can be referred to in the various embodiments of the data consistency processing method of this application, and will not be repeated here.

[0076] Fourthly, embodiments of this application also provide a computer-readable storage medium.

[0077] The present application has a data consistency processing program stored on a computer-readable storage medium, wherein when the data consistency processing program is executed by a processor, it implements the steps of the data consistency processing method described above.

[0078] The method implemented when the data consistency processing procedure is executed can be referred to in various embodiments of the data consistency processing method of this application, and will not be repeated here.

[0079] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0080] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0081] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0082] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0083] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0084] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they 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 this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0085] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A data consistency processing method, characterized in that, The data consistency processing method includes: When any storage node in a distributed storage system receives data to be updated sent by a client, it obtains the corresponding data update path with itself as the first storage node. The data update path contains multiple storage nodes. According to the data update path, each storage node persists its own data after receiving the data to be updated. If the persistence is successful, the data to be updated is transmitted to the next storage node. If the persistence fails, the data is rolled back and a path update failure feedback message is sent to the upstream of the data update path. After receiving the message, each upstream storage node rolls back the data to be updated.

2. The data consistency processing method as described in claim 1, characterized in that, The data consistency processing method further includes: After the last storage node on the data update path receives the data to be updated and successfully persists its own data, it sends a feedback message indicating that the path update was successful to the upstream of the data update path.

3. The data consistency processing method as described in claim 1 or 2, characterized in that, The data consistency processing method further includes: After receiving the feedback information, the first storage node sends the feedback information to the client.

4. The data consistency processing method as described in claim 1, characterized in that, The data update path is sent from the client to the first storage node; or The data update path is sent from the system backend of the distributed storage system to the first storage node.

5. The data consistency processing method as described in claim 1, characterized in that, The data consistency processing method further includes: If any storage node does not receive a persistence result from the next storage node, it determines that the next storage node is offline and transmits the data to be updated to the first online storage node downstream along the data update path.

6. The data consistency processing method as described in claim 5, characterized in that, The data consistency processing method further includes: A pre-set waiting time is used. If any storage node exceeds the waiting time and does not receive the persistence result from the next storage node, the next storage node is determined to be offline.

7. The data consistency processing method as described in claim 6, characterized in that, If there are offline storage nodes in the data update path, skip those offline storage nodes when sending feedback information upstream.

8. A distributed storage system, characterized in that, The distributed storage system includes: multiple storage nodes, which perform data consistency processing based on the method described in any one of claims 1 to 7.

9. An electronic device, characterized in that, The electronic device includes a processor, a memory, and a data consistency processing program stored in the memory and executable by the processor, wherein when the data consistency processing program is executed by the processor, it implements the steps of the data consistency processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a data consistency processing program, wherein when the data consistency processing program is executed by a processor, it implements the steps of the data consistency processing method as described in any one of claims 1 to 7.

Images