Raft实现报告(11)

简介: Raft实现报告(11)

Raft实现报告(11)

时间和可用性

对于Raft的要求之一就是安全性不能依赖于时间。系统不能因为某些事件发生的比预期更快,或者更慢而产生不确定的结果,且会极大的增大复杂性。但是,可用性(系统能够及时响应client的能力)必然区别于时间。没有稳定的leader,raft就无法取得进步。

Leader的选举是Raft中时机最关键的节点,能否保持一致性,能否安全复制日志条目,能否安全提交日志条目。只要系统能够满足一下的时许要求。那么Raft就能选举并且维持一个稳定的leader。

广播时间<<选举时间<<MTBF

在这个不等式中,广播时间是服务器向服务器集群中的每个服务器并行发送RPC并接受他们响应的平均时间。选举超时在以前的文章中介绍过,Raft通过特殊的超时机制,动态变化超时时间。MTBF是单个服务器的平均故障间隔时间。

广播时间应该比选举超时小一个数量级,为了leader可以发送心跳消息,以防止follower开始新的选举;鉴于以前提到的选举超时的随机方法,这种不平等的时间也使得分票变得不太可能。选举超时应该比MTBF小几个数量级,这样系统才能稳步的推进。当leader崩溃时,系统将差不多选举超时时间范围内不可用。


相关文章
|
存储 算法
Raft实现报告(六)
Raft实现报告(六)
|
存储 算法 安全
Raft实现报告(九)
Raft实现报告(九)
|
存储 索引
Raft实现报告(五)
Raft实现报告(五)
|
算法 安全
Raft实现报告(13)
Raft实现报告(13)
|
存储 算法
Raft实现报告(12)
Raft实现报告(12)
|
Linux
Raft实现报告(18)
Raft实现报告(18)
|
存储 安全
Raft实现报告(14)
Raft实现报告(14)
|
存储 索引
Raft实现报告(16)
Raft实现报告(16)