持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第15天，点击查看活动详情

Redis集群中的故障发现

我们都知道Redis集群是一种可以解决单点故障的问题，说白了就是让一台正常的Redis代替故障Redis对外提供服务；那么这样子的话，问题来了：我们是怎么发现Redis故障的呢？

这个看似小的问题里，却大有学问；话不多说，咱们立马开始今天的学习。

监控Redis

要想知道Redis是否出故障，咱们自然而然地就想到了监控Redis的状态。

上图表示的就是用一个监控程序去监控Redis，以得知Redis的具体状态；它们之间是通过网络传输消息的，也正因为这样就会存在一个问题：

假如Redis服务时可以正常运行的，但是因为在和监控程序的交流过程中，中间网络出现了问题，这样就会导致监控程序误判该Redis出现了故障

为了解决这类问题，就提出了多个监控程序监控同一台Redis：

其实到了这一步也并不是完全可以解决上述问题的，具体还是得看你的业务场景，看你可以接受的结果是哪一种。

1. 如果要追求Redis的高度可用的话，那只要有一个监控程序认为Redis出故障了，就断定Redis出故障。在这种情况里，可用性是很高的，一旦有程序说Redis出问题了就立马更换；但是却存在误判的问题。
2. 可以允许一定的容错率，要有一定数量的监控程序都反映Redis有问题，这才断定Redis出故障。这种情况下，不至于误判Redis，但是有可能会延迟发现Redis故障。

其实上述的问题就是一个概率问题，具体到生活场景中的话，就是一个选举问题：

就好像你要选有能力的班干，那你怎么判断他是有能干还是没能干呢？

是一个人选他就说明他能干，还是多个人选他才说明他能干？

如果是多个人的话，那需要多少个人呢？

其实这就是一个概率问题，越多人选他，那就说明他真的是能干的概率就高，但也有可能他把所有人都演了，他其实是不能干的。

回到Redis上也是同样的道理，越多的监控程序认为Redis出故障了，那Redis真的出故障的概率就大。

在实际中，

一般是需要超过半数以上的监控程序认为Redis出故障了，才真正地判定Redis出故障。

在这里，我们思考一个问题：既然现在已经引入了多个监测程序的概念了，那么这个多个是多少个呢？是奇数个还是偶数个？

咱们来推导一下：

1. 假如是奇数个（3）监控程序，3个监控程序，那么需要其中的2个都说Redis出故障了，才能判断
2. 假如是偶数个（4）监控程序，4个监控程序，那么需要其中的3个都说Redis出故障了，才能判断

无论是3个还是4个监控程序，都只最多允许其中一个监控程序的说法和其余的不一致，这样才能判断；也就是说无论是3个还是4个监控程序，都只最多允许一个监控程序判断错；这说明3个和4个的容错范围是一样的，但是3个监控程序的成本更低（少了一个监控程序）

综上所述，奇数个监控程序是更好的！