redis哨兵模式详解

目录

前言：

手动干预主节点挂的情况

哨兵节点操作流程

哨兵重新选取主节点流程

主观下线

客观下线

哨兵节点选leader

挑选从节点作为主节点

---

前言：

    redis在主从模式下，主节点服务就显的尤为重要。为了保证redis集群的高可用，提出的哨兵模式。哨兵集群只负责监控主节点，如果主节点挂了，哨兵节点就可以在从节点中选取一个作为主节点，保证了redis集群服务的可靠性。

    哨兵机制是通过独立的进程体现的（redis-sentinel），和redis-server不是一个进程。redis-sentinel不负责存数据，只是对其他的resid-server起到监控的效果。通常哨兵节点也会搞一个集合，也是提供redis集群的高可用（防止哨兵节点挂了的情况）。

手动干预主节点挂的情况

1）把选中的从节点，通过slaveof no one 自立山头。

2）把其他的从节点，修改slaveof的主节点 ip和port连接上新的主节点。

3）告知客户端（修改客户端配置），让客户端能够连接新的主节点，用来完成数据的修改操作。

4）当之前挂的主节点修复完成后，就可以作为从节点，挂到这组机器中。

哨兵节点操作流程

    监控：哨兵集群会和数据节点集合建立tcp长连接，定期发送心跳包检测redis数据节点是否正常运行。

    如果主节点挂了，一个哨兵发现了还不足以判定该主节点确实挂了，需要多个哨兵都认同此判定。主要是为了防止误判（网络波动等）。

    客观认为主节点确实挂了，这些哨兵节点会选举一个leader。由这个leader负责从现有从节点中选出一个作为新主节点。

    挑选出新节点后，哨兵节点会控制该节点，执行slaveof no one让该节点作为master。并且控制其他从节点修改slaveof到新主节点上。

    哨兵节点会自动通知客户端程序，告诉新主节点ip和port。后续客户端写操作就会针对新主节点进行了。

哨兵的核心功能：

1）监控：判定主节点是否挂了。

2）自动故障转移：修改主从关系。

3）通知：通知客户端主节点发生改变。

哨兵重新选取主节点流程

主观下线

    哨兵节点通过心跳包，判定redis主节点服务器是否正常工作。如果心跳包没有如约而至，则说明redis服务器挂了。

注意：

    此时不能排除因为网络波动，因此只能单方面判断redis服务挂了。

客观下线

    多个哨兵都认为主节点挂了（认为哨兵节点挂了的数量达到法定票数）。哨兵们就认为主节点是客观下线。

    法定票数：哨兵节点配置文件中进行配置。

哨兵节点选leader

    要让多个哨兵节点选出一个leader，这个leader负责选一个从节点作为主节点。

    当哨兵1首先发现主节点客观下线后，首先给自己先投一票，然后通知哨兵2和3（拉票），哨兵2和3发现主节点客观下线后（反应慢半拍），立即会给一号哨兵投赞成票。

    哨兵2和3当它们没有投出自己手里票的时候，收到拉票请求，就会投出去。（如果有多个拉票请求，就会投给最先到达的）

    如果总的票数超过哨兵总数的一半，选举就完成了。（把哨兵节点设置为奇数个，就是为了方便投票）

注意：

    上述投票过程，就是看谁首先发现主节点客观下线（网络延时小），然后自己给自己投完后，进行拉票，其他哨兵收到拉票请求后也会投赞成票。

挑选从节点作为主节点

    此时leader选举完成，leader就会挑选一个从节点作为主节点。

1）优先级

    每个redis数据节点，都会在配置文件中，有一个优先级设置（slave-priority），优先级高的就会胜出（默认优先级都是相等的）

2）offset

    offset最大就会胜出。offset是从节点从主节点这边同步数据的进度，数值越大，说明从节点数据越接近主节点。

3）run id

    此时优先级和offset都一样，其实随便挑选一个就可以。每个redis启动的时候，都会随机生成一串数字，挑最小的run id作为主节点。

注意：

    1）指定好新的主节点之后，leader就会控制这个节点，执行slave no one 成为 master。

    2）在控制其他从节点，执行slave of，让其他从节点以新的 master 作为主节点

    3）通知客户端，新主节点 ip 和 port，这个时候主节点就更换完成。

    4）后续如果发现原主节点上线运行正常后（心跳包），那么将会作为从节点挂到这组机器上。

小结：

    redis哨兵模式只是提供了redis集群的高可用，不能解决极端情况下写丢失问题，并且也不能增加存储容量（需要redis集群解决）。