redis中的哨兵机制

Redis 哨兵 (Sentinel) 机制是 Redis 高可用性 (High Availability) 的核心解决方案。

简单来说，如果主从复制（Master-Slave）是"备份 "，那么哨兵机制就是"自动救灾"。

在没有哨兵的情况下，如果 Master 挂了，你需要手动把一个 Slave 提升为 Master，还需要修改应用连接配置，这在生产环境是不可接受的。哨兵就是一个运行在后台的"智能机器人"，全天候监控 Redis 集群，一旦发现 Master 挂了，自动把 Slave 扶上位。

以下是哨兵机制的详细拆解：

哨兵本身也是一个 Redis 进程，但它不存储数据，只负责干活。它的工作可以总结为三个词：监控、通知、故障转移。

监控 (Monitoring)：

哨兵会不断地检查你的 Master 和 Slave 是否运作正常。它每秒都会向节点发送 PING 命令。
通知 (Notification)：

当被监控的某个 Redis 节点出现问题时，哨兵可以通过 API 向管理员或者其他应用程序发送通知。
自动故障转移 (Automatic Failover)：

如果 Master 挂了，哨兵会启用"选举流程"，在剩下的 Slave 中选出一个作为新的 Master，并让其他 Slave 改去侍奉这位新主子。当旧 Master 醒来（重启）后，哨兵会命令它变成 Slave，不再是从前的老大。
配置提供者 (Configuration Provider)：

客户端应用在连接 Redis 时，连接的不是 Redis 真实 IP，而是哨兵的 IP。客户端向哨兵询问："谁是现在的 Master？"，哨兵会返回当前 Master 的地址。这样发生故障转移后，客户端能自动感知到新地址。

这个过程非常严谨，分为以下几个阶段：

沟通：觉得 Master 挂了的哨兵，会跑去问其他哨兵："哎，你们看 Master 还在吗？"
判定：如果超过半数（或者配置的 Quorum 数量）的哨兵都说"我也连不上 Master"，那么 Master 就被正式判定为"死透了"。这就叫"客观下线"。
意义：这一步是为了防止误判（比如只是单个哨兵网络波动）。只有到了 ODOWN 状态，才会触发故障转移。

Leader 哨兵会在剩下的 Slave 中挑选一个新的 Master。挑选规则极其严格（按顺序判断）：

Quorum (法定人数)：

这是在配置哨兵时的一个核心参数（例如 sentinel monitor mymaster 127.0.0.1 6379 2 中的 2）。

它表示：至少需要几个哨兵认为 Master 挂了，才能标记为 ODOWN 并发起故障转移。
- 注意：Quorum 只是用来判断"是否需要报警"。真正执行故障转移时，还需要半数以上的哨兵投票选举 Leader。

优点	缺点
高可用性：故障自动恢复，不需要人工介入。	配置复杂：相比单机，配置项和维护成本增加。
自动发现：客户端只需要连哨兵，不需要硬编码 Redis 地址。	无法解决容量限制：哨兵依然是主从架构，存储容量受限于单台 Master 的内存。如果数据量特别大，哨兵解决不了，需要用 Redis Cluster。
健壮性：由多台哨兵组成的集群，即使哨兵挂了一两个，系统依然能工作。	主从切换有瞬间卡顿：在选举新 Master 的几秒钟内，Redis 集群是无法写入数据的。

Master 是 CEO，负责决策（写入）。
Slave 是经理，负责执行（读取/备份）。
Sentinel 是董事会/监事会。
- 他们平时不干活，就盯着 CEO 干没干活。
- 一个董事觉得 CEO 没来上班（SDOWN），不算数。
- 大家开会都觉得 CEO 跑路了（ODOWN），就投票把一个经理提拔成新 CEO。
- 外部客户（Client）想找 CEO 谈生意，必须先问董事会"现在谁是 CEO？"。