深入浅出Redis高可用：哨兵机制 _Redis

1. 引言之前我们聊过 redis 的主从同步（复制）主题，这期我们来聊 Redis 的哨兵机制。

上期我们说过，在实际互联网架构上，Redis 为了保证高可用和分担读写压力，几乎都会采取主从复制的部署架构。
一方面让架构易于扩展，另一方面防止单体故障：当主库挂了，可以立即拉起从库，不至于让业务停滞太久。

江湖门派林立如果把所有互联网应用看做是一个江湖，Redis 是武林中的门派，为了让门派更加稳定，每个门派都有掌门和副掌门。
在一些小门派里面，掌门仙逝以后，都会开追悼大会，然后从副掌门中再选一个掌门出来主持大局，这个过程可能会持续好几天。
但是，在一些大门派里面，比如武林之中一些有名望的派别：武当、少林（如淘宝、微信）之流，却不可一日无掌门。
放到如今的双 11，电商应用挂几秒钟可能都是千万甚至亿万级别的损失，所以对系统的可用性要求非常高。

一般大型应用的可用性都需要达到 4 个 9：即 99.99%，一年宕机时间不超过 53 分钟。

那以武当（淘宝 Redis）为例，需要如何保证门派的稳定性呢？
首先我们得依赖副掌门机制（主从复制）做备份，上篇我们已经说过了。
这期我们来说一下在掌门挂了后如何高效交接事务（故障转移），武林门派大会 2.8 后，每个门派有一个单独的部门来负责掌门交接事宜——哨兵部门。

Redis2.8 版本以后提供的哨兵机制（Sentinel）。

2. 哨兵部门的职责在武当派，张真人之下有武当七侠，从声望和资历来看，派内将前两位弟子作为副掌门人选，他们平时也会辅助掌门处理门派事务。
而哨兵部门的职责，主要有四点：

文章插图
图片

监控：检查掌门和副掌门状态，查看他们的生命体征和情绪状态是否正常；
自动故障转移：当掌门人闭关或者嗝屁了后，立马从副掌门选一个新掌门接手门派事务；
配置提供者：外宾（客户端）来访时，通过哨兵部门来获取掌门人的联系方式；
通知：掌门更换以后，哨兵部门将新掌门已更新的信息发布到外界。

其中监控和故障转移功能主要是为了维系系统的稳定，可以第一时间感知几位掌门的状态，当掌门人闭关或者嗝屁以后，能快速地选出一个新的掌门接替门派事务。
而配置提供和通知功能主要是和客户端交互，可以理解为哨兵部门是外宾和门派建立联系的桥梁。
并且，当掌门人易主以后，哨兵机制会向客户端发布新的主节点地址。仿佛在向外界宣布，新掌门联系方式变了，望周知！

3. 哨兵部门如何工作哨兵部门这么强横，那它究竟是怎么做到的呢？接下来我们从分别从监控、节点切换、发布通知和节点恢复来详细介绍一下。

3.1 监控-感知各掌门的状态虽然说是监控，但哨兵只是对各掌门人的状态是否正常做一个判断，门派事务哨兵是一概不参与的（毕竟人家是掌门&副掌门，哨兵还管不着这么宽）！
在武当派，不管是哨兵部门的成员，还是副掌门之上，都会一招 “千里传音” ，以便更好地传递事务消息。
那既然不能参与事务，哨兵如何监控它们的状态呢？

文章插图
图片
如图所示，哨兵成员会定期给掌门人们千里传音，各掌门如果定时回复，那掌门人就处于正常状态。
反之，如果掌门在规定时间内不回复就说明状态不正常，哨兵就会采取行动。

主观下线在 Redis 服务器中，哨兵每隔 1 秒会给主从节点发送 PING 命令，如果在一定时间内收到响应，就说明节点正常运行。
如果任意一个主/从节点没有在规定时间内（down-after-milliseconds 可配置，单位是毫秒）响应，哨兵就认为这个节点挂了，将其标记为主观下线。
为什么是主观下线呢？
因为 Redis 中为了保证监控的稳定性，当一个哨兵没收到回复时，就说明这个节点有概率挂了，但是不一定完全是节点的问题，也有可能是网络故障，或者阻塞了导致消息没有正常传播。