《云计算技术系列丛书 云原生分布式存储基石： etcd深入解析》—1.4.5Raft算法性能评估

1.4.5　Raft算法性能评估

       对于基于复制状态机模型的一致性算法来说，需要考察的性能点是当领导人选举成功时，应于什么时候复制新的日志条目？这样集群才能继续对外提供        （写）服务。Raft 通过很少数量的消息包（一轮从领导人到集群大多数机器的消息）就达成了这个目的。在实现上，支持批量操作和管道操作进一步提高了Raft算法的吞吐量，同时还降低了时延。

       Raft算法的作者自己实现了一个Raft项目，并且基于这个实现来衡量Raft算法领导人选举的性能，具体包含如下两个方面。

       1）领导人选举的过程收敛有多快。

       2）领导人宕机后，系统不可用的时间有多久。

       为了衡量一次领导人选举的耗时，Raft算法的作者反复让一个集群的领导人宕机，并观测集群的其他节点需要多长时间才能发现领导人不存在了并选举出一个新的领导人（如图1-22所示）。领导人随机地在两次心跳包间隔内宕机，而心跳包的时间间隔刚好是选举超时时间的一半。因此，Follower能够感知到领导人宕机的最小时间是选举超时时间的一半。

       以上实验是在一个有着5个节点的集群上进行的，环境上的广播时延在15ms左右，每种场景均反复测试1000次。实验结果如图1-22所示，横坐标表示时间（单位是ms），纵坐标代表时延分布比例（0%处对应的横坐标代表最低时延，100%处对应的横坐标代表最高时延）。

图1-22　Raft算法性能评估图

       图1-22上面的实验结果表明，选举超时时间只需要较小的随机化，就能够明显地降低因为选票被瓜分而导致的重新选举，从而降低选举耗时。而选举超时时间在没有随机化的情况下，最差的时候需要花费超过10s才能完成选举过程。根据Raft作者提供的数据，在选举超时时间上仅仅增加5ms的随机变化，就可以显著改善这一情况—平均宕机时间只有287ms。在选举超时时间上增加50ms的随机化，1000次测试中完成一次选举的最长时间只要513ms。

       图1-22下面的实验结果表明，通过降低选举超时时间可以减少系统的宕机时间。Raft作者提供的数据可以表明，在选举超时时间为12～24ms的情况下，平均只需要35ms就可以选举出新的领导人，而最长一次的时间也就是152ms。然而，如果要进一步降低选举超时时间的话，就会违反Raft算法的时间不等式—选举超时时间不能小于领导人的心跳周期，这将会导致没有意义的领导人变更，反而还会降低系统的可用性。因此，Raft作者建议使用更为保守的选举超时时间，比如150～300ms。这样的时间不大可能导致没有意义的领导人变更，同时还能保证较好的可用性。