1. Full Write 1 (write all, read one)Full Write 1 is the most intuitive copy control rule. When writing, only the copy is successful, only if it is written successfully. In this way, it is only necessary to read the data from one of the replicas to ensure correctness. This rule needs to solve a problem: if it is a KV system, if the first write of a key is only partially successful, then there is the result of the second write in the system, and the result of the first i-1. According to the rules, only the i-1 version is in effect. Therefore, it is necessary to globally record the current version number of the data corresponding to a key i-1. This metadata may be a bottleneck for the system. Availability: For write operations, although there are n replicas, it is not possible to tolerate any one replica exception, the availability is not high. The read service is highly available.
2. The quorum mechanism is an upgraded version of the above-mentioned content and is well understood. For usability, you can make the following compromises as appropriate. For n replicas of the system, if the write operation only succeeded W copy, then if read n-w+1 copy, then read the result of the collection, must contain the latest version of the data.
for reading and writing:The key question here is how to determine which of the read R replicas is the data that was successfully submitted? For example, submitted 3 times, only the 2nd time success. Then, when quorum reads, it is bound to read the copy of the 2nd version that was successfully submitted, and may read the 1, 3 version of the data that was not finally successfully submitted. The first way of thinking, directly with a meta-data service will be the successful submission of the version number, if there is a version number, you can directly determine which version of the data should be read. This method is not very good. But in fact quorum itself does not have any means to solve the problem.
the read operation must read the data that has been submitted successfully。 This is strong consistency. Quorum in order to solve the strong one, there is also the need to introduce additional restrictions: limiting the submission of the quorum mechanism, only on the basis of the success of the previous version, the next version of the submission. The meaning of this is that it is possible to commit an unsuccessful version, only the last version. It's good to deal with it. If you read r copies, the highest version number of copies is less than W, continue to read the r+1 copy, to determine whether the highest version of the number of copies reached W. If none of the n is reached until the end of the reading, it means that the highest version is not a successful record, and only a minor version number can be taken as the final successful commit record (guaranteed by the restriction). As can be seen, although this method solves the problem, it may be too much to read. Also, if there is a replica exception, there is a possibility that there is no way to determine which version of the current final commit succeeded. Generally speaking, we should avoid this idea and combine the quorum with the master-slave mechanism to read the master.
for selecting the main:In master-slave control, if the primary node fails, you need to select a master from the rest of the nodes. The selection of the quorum mechanism is divided into three steps: First, read the R node, take the highest version of the data, the data must be more than the latest successful submitted data (either the latest submission is successful, or the latest submission has not been successful), and second, the data to the W, so that the system to meet the requirements of writing W, Make sure the data becomes the latest commit data, and thirdly, as the new master node. Application:
GFS: GFs, using the degenerate way of quorum, that is, write full read one. In order to resolve a write-time replica corruption that is not available, GFS creates a new chunk on the machine without an exception when the append replica fails, increasing availability append on this chunk.
Dynamo: On a centralized structure, quorum writes may be thrown by different replicas at a time, which can cause inconsistent and conflicting data. Instead of dealing with this, Dynamo refers to a clock vector that records who initiated each operation and what version number. The clock vector is returned to the user and handled by the user. such as: N=3, w=r=2. Initial is (1,1,1). 1. +1,a sync to C: Data (2,1,2) with a trigger action, clock vector record [1,a][][1,a];2. Take action +2 with B, synchronize to C: Data (2,3,3), clock vector record [1,a][1,b][1,b];3. Take action +3 with a, synchronize to C: Data (5,3,5), clock vector is [(1,a) (2,a)][1,b][(1,a)]; At this point, the record on B is conflicting with a and C, which requires the user to resolve the conflict according to different policies. Can be combined to get the result 7.
Big Pipe: As with GFS, the Waro to resolve a failed copy of the write failure is that all replicas update the last record to zookeeper as the standard. Similarly, as with GFS, new chunk are created for subsequent writes to improve usability after the failure of the update.
2:quorum mechanism of distributed entry
