The motive for the version stamp:
In a distributed environment, there are multiple copies of a single piece of data. When updating the data, there may be inconsistencies in the data in multiple replicas, which includes the following two scenarios: 1. The data in some nodes has been updated, and the data in some nodes has not been updated. 2. Two nodes have been updated, but their updated content is inconsistent. This creates a problem that if a user reads the data from the two nodes at the same time, they will find that the data being read is not the same. Therefore, the user needs to decide which data is to be read and which is the old one, and then take out the new data. To do this, a version stamp is introduced to identify the old and new version of the data. How the version stamp is generated:
- The counter, which is generated by a master node to generate counter values, is distributed to all the slave nodes. If the data is updated from the node, the value of the counter is incremented by 1. The main reason for generating counter values from the master node is to ensure that all the slave nodes have the same version upgrade method (the version with large counter values must be newer than the version with the Count value).
- Timestamp, the main difficulty with this approach is that all nodes need to be consistent in time. If the time of a node is not synchronized, it causes a global error. At the same time, the accuracy of timestamps is also a concern, and if an update is very frequent (multiple updates within a millisecond), it is necessary to control the timestamp more accurately.
- A GUID that produces a globally unique ID, such as a globally unique ID based on date, hardware information, and so on. The main problem with this approach is that the GUIDs are larger, and the new and old versions cannot be judged by direct comparisons.
- Generates a hashcode based on the content. The problem with this method is similar to the problem with the GUID.
How to use version stamping: Introduces the concept of a conditional update, the general operation is to read one data before writing to the data. If these two operations are not transactional atomic, then there may be time windows where the data has changed before the data is written, rather than the data that was previously read. Therefore, the conditional Update method may be used to determine whether the current data has been modified before writing, and this is based on the version stamp. Major difficulty: Produces a rule that all nodes share a version order change. In master-slave mode, a version stamp can be generated from the master node for distribution.
- However, in the peer model, there is no concept of the master node. So the introduction is the "version stamp Array", which produces an array of elements for each node. For example, if there are three nodes, blue, green, red, then each node changes the version on this node accordingly when the data is modified locally. This data modification is then notified to all other nodes by exchanging a "version-stamp array" between two nodes. For example: An array of Node A is: [Blue:1, Green:2, Red:3], another array of Node B is: [Blue:2, Green:2, Red:3], you can know that the data in Node B is updated.
- You can also find write conflicts by using a version-stamp array. For example: An array of Node A is: [Blue:1, Green:2, Red:3], and the other array of Node B is: [Blue:2, Green:1, Red:3]. In other words, this new data has been updated in the green node and has been updated in blue, resulting in a conflict. However, a version-stamp array cannot resolve this conflict.
Version stamp (revision stamp)
