关于Redis中哨兵(Sentinel)

Redis Sentinel 相关名词解释

名词	逻辑结构	物理结构
主节点	Redis 主服务	一个独立的 redis-server 进程
从节点	Redis 从服务	一个独立的 redis-server 进程
Redis 数据节点	主从节点	主节点和从节点的进程
哨兵节点	监控 Redis 数据节点的节点	一个独立的 redis-sentinel 进程
哨兵节点集合	若干哨兵节点的抽象组合	若干 redis-sentinel 进程
Redis 哨兵（Sentinel）	Redis 提供的高可用方案	哨兵节点集合和 Redis 主从节点
应用方	泛指一个或多个客户端	一个或多个连接 Redis 的进程

为什么引入哨兵

Redis 中的主从复制最大的问题在于主节点，主节点挂了之后，从节点只能进行读操作，不能自动升级成主节点，不能替换原有主节点对应的角色，这时需要程序员收到恢复主节点，比较繁琐。

而 Redis 哨兵可以自动对挂了的主节点进行替换。

关于从节点和主节点之间断开连接，有两种情况：

1. 从节点主动和主节点断开连接，比如 slaveof no one，这时从节点可以晋升成主节点。

2. 主节点挂了，这是一种脱离掌控的情况，从节点不会自动变为主节点。

哨兵机制，是通过一个独立的 redis-sentinel 进程来体现的，和之前的 redis-server 是不同的进程，它不负责存储数据，只是对其他的 redis-server 进程起到监控的效果。

不使用哨兵节点进行监控的程序一般还要搭配一个报警程序使用，当主节点挂了就会通知程序员，程序员解决问题的一般流程为：

1. 先确认主节点能不能恢复，是否方便恢复

2. 如果主节点挂的原因不好定位，或者原因明确，但短时间内难以解决，就需要重新选择一个从节点，将其设置为新的主节点

• 把选中的从节点通过 slaveof no one，从原来的主从关系中分离出来

• 对其他从节点修改 slaveof 的主节点 ip port，连上新的主节点

• 告知客户端（修改客户端配置），让客户端能够连接新的从节点，挂到这组机器中

这种手工处理的方式有很大的弊端，比如整个修复的过程中，所有的节点都不能正常工作，而修复的时间往往也比较长，所以这种方式很不适用。

Redis Sentinel架构

1. redis sentienl进程通过和节点之间建立TCP长连接，以发送心跳包的方式，监控某个节点是不是挂了。如果挂的是从节点，则没有什么影响；如果挂的是主节点，多个哨兵节点之间会进行协商确认主节点是不是真的挂了。

2. 如果主节点真的挂了，哨兵节点之间就会推举出一个 leader，由这个 leader 负责从其他的从节点中选出一个节点成为新的主节点。

3. 这个被选中的从节点会执行 slaveof no one 从原来的主从关系中分离出来，然后其他的从节点会设置slaveof 到这个新的主节点上。

4. 哨兵节点会自动通知客户端程序，告知新的主节点是谁，后续客户端程序再进行写操作，就会针对新的主节点进行。

哨兵选出 leader 之后，由 leader 选出新的主节点，选取依据如下：

1. 优先级：每个 Redis 数据节点都会在配置文件中有一个优先级设置----slave-priority，优先级高的从节点成为主节点。

2. offset：表示从节点从主节点同步数据的进度，数值越大，说明从节点的数据和主节点越接近，更适合作为新的主节点。

3. Run id：每个 Redis 节点启动时随机生成的一串数字，也就是说到这一步的时候就没有什么“更适合”了，相当于随机选择一个。

总结

• 哨兵节点不能只有一个，否则哨兵节点挂了也会影响系统可用性。

• 哨兵节点最好是奇数个，方便选举 leader，得票更容易超过半数。

• 哨兵节点不负责存储数据，仍然是 redis 主节点负责存储。

• 哨兵 + 主从复制解决的问题是“提高可用性”，不能解决“数据极端情况下写丢失”问题。

• 哨兵 + 主从复制不能提高数据的存储容量，当需要存的数据接近或超过机器的物理内存，这样的结构就难以胜任了。