如何基于Raft绕过​分布式算法一致性的那些痛?

 

Q&A  

 

Q1:抛砖引玉问一下,swankit 的典型部署是跨数据中心部署吗?如果是的话,raft 的心跳时间你们的经验值是? 在网络抖动的情况下,如何避免 follower 频繁发起新 Term 的选举?

A1:由于目前我们的项目还没有大规模的应用到生产所以心跳和选举的间隔参考的swarmkit和etcd分别设置的1秒和10秒。目前我们的实现方式是不支持跨数据中心的部署的。至于如何避免follower频繁发起新的term选举目前还只有设置选举间隔这一条了。

 

Q2:Raft和Multi-Paxos的区别?

A2:Raft可以说是从Paxos 中发展出来的,答:简单来说就是 Raft 在理解和实现都要比 Multi Paxos 要简单,主要体现在两阶段的限制。Paxos 出现的太早了,严格的证明,非常的学术,有兴趣的可以去看 Lamport 老的论文,包括最早那篇和 make simple,make live。我也不敢说理解透彻,只是了解到谷歌的 Chubby 是基于Multi Paxos 实现的。至于实践上的区别可以参考http://bingotree.cn/?p=614。

 

Q3:第一张图里,显示了3个raft节点,一个leader,两个follower,那律师节点是随机的么?另外,图中显示,心跳是两两节点完成的,而不是用连到一个交换机,这种方式会不会有什么问题?

A3:由于在Raft节点中任何一个节点都可以成为候选者向其他节点请求投票所以需要 两两之间互相通信, 所以如果不是连到同一交换机导致节点之间无法互相通信是有问题的。

 

Q4:请问这次采用了哪个raft的开源实现?还是自己实现了raft协议?

A4:用的是 coreos 的 etcd/raft 库 https://github.com/coreos/etcd/tree/master/raft。