主从复制：多副本
经过数据持久化以后，当Redis实例发生宕机时，就可以用持久化文件快速恢复Redis中的数据。但是恢复数据也依旧需要时间，在此期间业务依旧会无法提供服务，这时候就需要更好的方案
一个实例宕机，只能用恢复数据来解决，那么我们是否可以部署多个Redis实例，然后让这些实例的数据保持实时同步，这样当一个实例宕机时，在剩下的实例里选择一个继续提供服务就好了。
这也就是主从复制-多副本，其中实时读写的节点是master，另一个实时同步数据的节点是slave。
优点是：
- 缩短不可用时间：master发生宕机，可以手动把slave提升为master继续提供服务
- 提升读性能：slave可以承担一部分读请求，提升应用的整体性能
缺点是：
当master宕机的时候，需要手动把slave提升为master，这也是花费时间的，而且需要人工介入。
所以需要把切换的过程变成自动化，这也就是一个故障自动切换机制，也就是常常听到的哨兵机制哨兵：故障自动切换
引入一个观察者，实时监测master的健康状态，这个观察者就叫做哨兵。
具体来说：
- 哨兵每隔一段时间就询问master是否正常
- master正常回复表示状态正常，回复超时表示异常
- 哨兵发生异常，发起主从切换
这里还会有一个问题是 如果master和哨兵之间的通信有网络异常，可能会产生误判。
解决方案是：部署多个哨兵让他们分布在不同的机器上，一起监测master的过程就变成了这样：
- 每个哨兵间隔一段时间就询问master是否正常
如果有一个哨兵判定master异常，就询问其他哨兵，如果有大于等于x个哨兵都认为master异常，才判定master发生了故障，进行主从切换。
哨兵判定master异常后，还有一个问题：由哪个哨兵来发起主从切换呢？
答案是选出一个哨兵领导者，由领导者进行主从切换。通过一定的选举规则和投票来选举哨兵领导者。- 每个哨兵都询问其他哨兵，请求对方为自己投票
- 每个哨兵只投票给第一个请求投票的哨兵，而且只能投票一次
- 首先拿到超过半数投票的哨兵，当选为领导者，发起主从切换。
这个选举过程就是分布式系统领域中的共识算法，在多个机器部署哨兵，它们需要共同协作完成一项任务，就组成了一个分布式系统。
