I use etcd[1] which is an implementation of Raft for cluster configuration. I have a hard time seeing how Raft or consensus in general scales to a general solution for reliable consistency services.
One can not scale by adding servers because all potential members must be known, and consistency is only guaranteed if you are willing to require confirmations forcing full round trip communication with all members for every write. Anything more than 7 servers or so, and things start getting dodgy. Try to improve reliability by adding servers in geographically diverse areas is untenable altogether.
I don't see how simply having multiple servers with failover, and a version clock isn't equally or even more reliable due to it's scalability. The byzantine generals problem[2] is more about reliable voting and trust rather that high performance and reliability.
One can not scale by adding servers because all potential members must be known, and consistency is only guaranteed if you are willing to require confirmations forcing full round trip communication with all members for every write. Anything more than 7 servers or so, and things start getting dodgy. Try to improve reliability by adding servers in geographically diverse areas is untenable altogether.
I don't see how simply having multiple servers with failover, and a version clock isn't equally or even more reliable due to it's scalability. The byzantine generals problem[2] is more about reliable voting and trust rather that high performance and reliability.
I'd very much appreciate more insight on this.
1. https://github.com/coreos/etcd
2. http://en.wikipedia.org/wiki/Byzantine_fault_tolerance