Does Raft sacrifice anything for simplicity?
Raft为了简便易用,牺牲了一些性能,例如:
- 每个operation都需要单独写入log进行持久化存储,如果将很多operations构成一个batch一起写入会更好
- Leader和每个Follower之间只能存在一个有效的AppendEntries RPC。已pipline的形式构建多个RPCs可能更好。
- snapshot的设计只适用于状态空间比较少的情况,因为需要将所有状态全部存储在disk中。对于大型系统来说,一般只存储最近改动过的状态。
- Servers可能无法充分利用多核CPU计算,因为每次只能处理一个operation(in log order)。
Is Raft used in real-world software, or do companies generally roll their own flavor of Paxos (or use a different consensus protocol)?
很多real-world software使用了Raft机制,如 Raft: Docker (https://docs.docker.com/engine/swarm/raft/), etcd (https://etcd.io), and MongoDB.
What is Paxos? In what sense is Raft simpler?
Paxos也是一种共识算法,虽然Raft比Paxos更容易理解,但是Paxos的机制其实相比Raft更简单。Google Chubby, ZooKeeper都是基于Paxos协议来实现的。虽然Raft是一种很好理解的共识算法,但是由于其牺牲了性能方面的指标,因此实际上并不是大型分布式系统的最优选择。
How long had Paxos existed before the authors created Raft?
Paxos在1980年就已经出现了。
In Raft, the service which is being replicated is not available to the clients during an election process. In practice how much of a problem does this cause?
在Raft中,因为leader election而导致server暂停服务的时间不超过1/10s。在Raft论文中,选举事件只有在servers故障或network有问题时才出现。
Are there other consensus systems that don’t have leader-election pauses?
基于Paxos的共识算法不需要进行leader选举。
How are Raft and VMware FT related?
VMware FT存在单点故障,比如test-and-set server,而Raft不存在单点服务器故障。从这个角度来讲,Raft比VMware FT具有更