Version numbers get an additional component that can only be incremented by the Raft leader.
When Raft commits a write, it increments that counter
Because versions are compared starting from the Raft number first, this has the affect of making a committed write the most recent write in the system (e.g. +200 version number).
Dependencies are all tracked by the original version number
On eventual receipt of a higher version that is already in the log:
find all dependencies of that version, and make their "raft marker version" equal to the parent.
continue until "latest local" - then set that one to latest to write to and push in gossip.
I believe this system will eventually converge.
In Eventual only: the raft number is always 0, so eventual just works the same way as always
In Raft only: The "raft number" will be a monotonically increasing commit sequence but will have no other affect.
In Federated:
Given the following scenario:
A.1.0
/ \
A.2.0 A.3.0
| |
A.4.0 A.5.0
If A.2.0 goes to Raft, Raft will make it A.2.1 and will reject A.3.0; The replica that performed Anti-Entropy with Raft will make A.4.0 --> A.4.1 and when A.5.0 comes in via anti-entropy, A.4.1 > A.5.0 so A.5.0 will be tossed out.
I believe this system will eventually converge.
In Eventual only: the raft number is always 0, so eventual just works the same way as always In Raft only: The "raft number" will be a monotonically increasing commit sequence but will have no other affect.
In Federated:
Given the following scenario:
If A.2.0 goes to Raft, Raft will make it A.2.1 and will reject A.3.0; The replica that performed Anti-Entropy with Raft will make A.4.0 --> A.4.1 and when A.5.0 comes in via anti-entropy, A.4.1 > A.5.0 so A.5.0 will be tossed out.