redis-15-哨兵

哨兵

之前我们主从架构中，如果主节点挂了，我们要人为干预。现在 Redis 引入了哨兵这个机制，自动化故障恢复。

下图，右面是数据节点，左面是哨兵，它是分布式架构模式，主要就是监控数据节点的主从服务器，自动切换故障节点。

概念

监控(Monitor)：哨兵会不断检查主从节点运作正常。

通知（Notification）：如果有问题，那么会通过 api 发送消息出去。

故障自动迁移(Automatic failover)：当一个主服务器故障，哨兵会自动发生故障迁移。

配置提供者（Configuration provider）客户端不需要直接链接到主从节点，可以直接连接到哨兵，因为哨兵提供了一个服务发现的功能，客户端连接到哨兵后，就可以获取到主从节点的信息，如果主节点发生故障，重新产生主节点，哨兵也会把新的信息同步给客户端。

哨兵的分布式好处

可以再一个架构中运行多个哨兵进程。

1. 降低误报。（决策机制，大多数节点认为正确的事情，才是正确的）
2. 减低客户端的影响。（哨兵可以统一的对外提供服务，并不用关心数据节点内部细节）
3. 任意哨兵都可以对外提供服务。
4. 哨兵模式基于主从模式，所有的优点，哨兵都有。
5. 主从自动切换，系统健壮性，高可用性。
6. 哨兵可以一直检查主从服务器是否运行正常。一旦监控到某个 Redis 服务器有问题，哨兵就通过 API 向管理员发送通知。

哨兵的不足

1. 哨兵的配置是允许丢失有限的写入。这点要评估一下是否符合你的系统要求。
2. 主从切换需要时间，会丢失数据。（集群中，分片机制解决）
3. 主节点写入的压力也存在。存储能力受到单机的限制。（受单机限制）
4. 动态扩容困难，对于集群，容量达到上限时在线扩容会变得复杂。

哨兵工作原理

哨兵内部有 3 个定时任务

1. 每秒每个哨兵对其他哨兵和 Redis 节点执行 PING 命令。
2. 每 2 秒每个哨兵通过 Master 节点的 channel 交换消息。（Pub/Sub 机制）
3. 每 10 秒每个哨兵会对主节点（Master）和从节点（Slave）执行 Info 命令。

如何判断下线

主观下线：某个单独的哨兵实例对服务器做出下线的判断，认为某个服务下线了（接收不到返回结果，网络超时等等）。依据配置

sentinel down-after-milliseconds mymaster 10000

然后让其他的哨兵去判断，如果也是无法返回结果，就进行后续流程，进行仲裁，我们配置的仲裁结果是 2，也就是说 3 个哨兵中有 2 个哨兵觉得不通，那么就不通了。

客观下线：多个哨兵实例对同一个服务器做出下线判断，并且通过命令交流以后，得出下线的判断，然后开启故障转移(failover)。

仲裁：就是少数服从多数。配置文件中 quorum 配置项，默认是哨兵个数的 1/2+1,我们的案例中是 3 个哨兵，所以 3/2+1=2

故障迁移一致性

哨兵的分布式一致性算法使用 raft 共识算法。

1. 哨兵自动故障迁移使用 Raft 算法选出 leader，确保一个给定的周期（epoch）中，只有一个 leader 产生。
2. 在同一个周期中，不会有 2 个哨兵同时被选中为 leader，并且每个哨兵在同一个节点中只会对一个 Leader 进行投票。
3. 更高的配置节点总是由于较低的节点，因此每个哨兵都会主动使用更新的节点来代替自己的配置。

---

如何学以致用，在哪些场景中应用Redis

《Go语言+Redis实战课》

添加微信	公众号更多内容