《redis》8-主库宕机怎么办

上面一节我们讲了redis通过repliceof 组成的主从模式，主库负责执行读写操作，从库负责执行读操作。写的操作通过长链接同步给从库。这个地方有个很大的风险，主库宕机了怎么办，主库宕机之后，客户端的写操作就没有服务器可以执行了

为了解决这个隐患，redis推出了哨兵机制。哨兵是一个特殊的redis线程，通过定时ping主库和从库的ip-port来检测redis服务的状态。哨兵负责的三个主要工作：

哨兵机制

1. 判断主库是否下线
2. 选出新的主库，切换主库
3. 把新的主库通知给其他从库和客户端

判断主库下线

1. 主观下线，A哨兵主动ping 主库的ip_port，如果持续ping不同的时候，A哨兵标记主库为主观下线
2. 客观下线，多个哨兵A/B/C/D,如果超过半数的哨兵都标记主库为下线，那么主库就被标记为客观下线，防止单独的哨兵因为自己的网络环境不稳定，或者主库的服务压力过大，反应延迟导致错误下线。因为客观下线之后会选出新的主库，并且通知从库和客户端，会有较大的消耗。所以最少要三个哨兵组成哨兵集群

选出新的主库

1. 筛选合格的从库：首先剔除已经标记为主观下线的从库，下线的从库没有意义，在上线的从库中筛选前期网络稳定性好的从库，也就是说，之前的从库中，犯过错误的，经常性掉线的不能作为主库，因为当前在线，很可能过一段时间就下线了。所以之前下线次数超过一定的阈值就不能作为主库了
2. 评选出最优的从库，需要给合格的从库打分：

• 从库优先级最高的作为主库：slave-priority 配置项设置的优先级，如果从库有设置这个参数，则选出最高的从库作为主库
• 如果优先级一样高，则选出跟主库同步度最高的从库作为主库，上一节课我们讲过，在repl_backlog_buffer 中主库保存自己的master_repl_offset,从库保存自己的slave_repl_offset位置，最靠近主库位置的从库，说明数据最完整，可以选为主库
• 如果上面两个条件都一样，则看第三个条件根据runId,选择最小的runId来做新的主库。

上面的过程抽象来说比较简单，但是实施的过程还是有一定的难度，上面的内容是蒋德钧老师的课程总结。