撤消仲裁系统中的部分写入

Question

Suppose a quorum system has 5 nodes, and write & read quorum number is 3. Now, say a client sends a writes request w, and w is replicated on 2/5 nodes. Since we did not replicate on at least 3/5 nodes we say to the client that the write was not successful. Now, immediately after, 2 nodes on which the write was not replicated go down. So, out of the remaining 3 nodes, 2 have the partial write and 1 does not. In this case, how does the system figure out that the partial write w needs to be undone since it did not actually complete successfully?

Answer 1

In most systems 3/5 means that the value is chosen and must not be undone.

Different protocols and systems deal with this in different ways.

In ABD the next read will learn the value and from the one node and propagate it to other two remaining nodes.

Similarly, in Paxos , the next proposer will learn the value from that one node and will propagate it to the other two. In practical systems based on Paxos there will be a system (perhaps the Leader) that will produce a no-op proposal to ensure that the value is propagated in a timely manner.

In leader-election/primary-replica systems like Raft the leader will ensure the propagation to the replicas. That is unless of course it is one of those that died. In that case the election process typically requires the new leader to be the most up-to-date, which in this case would include the disputed value.

Answer 2

This is a common scenario you need to consider While building a distributed system to check on how to manage failures or events not getting sent to all needed nodes.

It's the Leader's responsibility to make sure the events gets successfully sent to minimum quorum defined before the event is considered as committed [there should be a Flag with Hashcode of that events ID] and the event is not eligible for retry.

When a request comes into a picture to fetch the data from distributed systems; it always goes to a Leader who will be delegating the request to near by Node by it's Hashcode. But before to delegate, Leader has to make sure that Commit Flag is TRUE(means event is delivered to minumum defined nodes). Otherwise, Leader can throw an Exception.

Also, Leader should should Stamp a Version number to the event and keep the current committed flags Version number. While retrieve the event, Leader can compare the event Versions to make sure all nodes are giving the latest and greatest data.

You can see Out of Box Functionality from Zookeeper etc systems.