Redis Sentinel 相关名词解释
| 名词 | 逻辑结构 | 物理结构 |
|---|---|---|
| 主节点 | Redis 主服务 | 一个独立的 redis-server 进程 |
| 从节点 | Redis 从服务 | 一个独立的 redis-server 进程 |
| Redis 数据节点 | 主从节点 | 主节点和从节点的进程 |
| 哨兵节点 | 监控 Redis 数据节点的节点 | 一个独立的 redis-sentinel 进程 |
| 哨兵节点集合 | 若干哨兵节点的抽象组合 | 若干 redis-sentinel 进程 |
| Redis 哨兵（Sentinel） | Redis 提供的高可用方案 | 哨兵节点集合和 Redis 主从节点 |
| 应用方 | 泛指一个或多个客户端 | 一个或多个连接 Redis 的进程 |
为什么引入哨兵
Redis 中的主从复制最大的问题在于主节点，主节点挂了之后，从节点只能进行读操作，不能自动升级成主节点，不能替换原有主节点对应的角色，这时需要程序员收到恢复主节点，比较繁琐。
而 Redis 哨兵可以自动对挂了的主节点进行替换。
关于从节点和主节点之间断开连接，有两种情况：
-
从节点主动和主节点断开连接，比如 slaveof no one，这时从节点可以晋升成主节点。
-
主节点挂了，这是一种脱离掌控的情况，从节点不会自动变为主节点。
哨兵机制，是通过一个独立的 redis-sentinel 进程来体现的，和之前的 redis-server 是不同的进程，它不负责存储数据，只是对其他的 redis-server 进程起到监控的效果。
不使用哨兵节点进行监控的程序一般还要搭配一个报警程序使用，当主节点挂了就会通知程序员，程序员解决问题的一般流程为：
-
先确认主节点能不能恢复，是否方便恢复
-
如果主节点挂的原因不好定位，或者原因明确，但短时间内难以解决，就需要重新选择一个从节点，将其设置为新的主节点
-
把选中的从节点通过 slaveof no one，从原来的主从关系中分离出来
-
对其他从节点修改 slaveof 的主节点 ip port，连上新的主节点
-
告知客户端（修改客户端配置），让客户端能够连接新的从节点，挂到这组机器中
这种手工处理的方式有很大的弊端，比如整个修复的过程中，所有的节点都不能正常工作，而修复的时间往往也比较长，所以这种方式很不适用。
Redis Sentinel架构
-
redis sentienl进程通过和节点之间建立TCP长连接，以发送心跳包的方式，监控某个节点是不是挂了。如果挂的是从节点，则没有什么影响；如果挂的是主节点，多个哨兵节点之间会进行协商确认主节点是不是真的挂了。
-
如果主节点真的挂了，哨兵节点之间就会推举出一个 leader，由这个 leader 负责从其他的从节点中选出一个节点成为新的主节点。
-
这个被选中的从节点会执行 slaveof no one 从原来的主从关系中分离出来，然后其他的从节点会设置slaveof 到这个新的主节点上。
-
哨兵节点会自动通知客户端程序，告知新的主节点是谁，后续客户端程序再进行写操作，就会针对新的主节点进行。
哨兵选出 leader 之后，由 leader 选出新的主节点，选取依据如下：
-
优先级：每个 Redis 数据节点都会在配置文件中有一个优先级设置----slave-priority，优先级高的从节点成为主节点。
-
offset：表示从节点从主节点同步数据的进度，数值越大，说明从节点的数据和主节点越接近，更适合作为新的主节点。
-
Run id：每个 Redis 节点启动时随机生成的一串数字，也就是说到这一步的时候就没有什么"更适合"了，相当于随机选择一个。
总结
-
哨兵节点不能只有一个，否则哨兵节点挂了也会影响系统可用性。
-
哨兵节点最好是奇数个，方便选举 leader，得票更容易超过半数。
-
哨兵节点不负责存储数据，仍然是 redis 主节点负责存储。
-
哨兵 + 主从复制解决的问题是"提高可用性"，不能解决"数据极端情况下写丢失"问题。
-
哨兵 + 主从复制不能提高数据的存储容量，当需要存的数据接近或超过机器的物理内存，这样的结构就难以胜任了。