4 ms·
Then you're sacrificing consistency guarantees. If less than a majority have committed a write, it could be lost while the cluster still has a quorum up. Wait
by refenestrator 5y ago
Then you're sacrificing consistency guarantees. If less than a majority have committed a write, it could be lost while the cluster still has a quorum up.
Waiting to report success until a majority have committed allows you to make guarantees with a straight face.. "it will probably be committed in the near future" is not the same thing.
- rubiquity 5y agoNot necessarily. As long as your quorums always overlap you can have weaker commit requirements. See the FPaxos paper and some of Heidi Howard’s blogs for more on this. https://fpaxos.github.io/ https://fpaxos.github.io/
- jimsimmons 5y agoFPaxos requires commit quorum and subsequent promise request quorum to intersect. It doesn't bring any significant thruput benefits
- rubiquity 5y agoI didn't say FPaxos brought throughput benefits. I pointed out that you can still have a correct implementation without requiring majority quorums. But since you brought it up, FPaxos can have both lower latency and higher throughput than MultiPaxos/Raft[0] ;) 0 - https://dl.acm.org/doi/pdf/10.1145/3299869.3319893 https://dl.acm.org/doi/pdf/10.1145/3299869.3319893
- jimsimmons 5y agoGreat link. Need to look into what WPaxos is.