redis哨兵模式的功能-以及主从选举算法

对于哨兵模式而言，主要负责的内容有

1、监控
2、选主（选择主库）
3、通知

哨兵工作流程：

1、监控：节点发现和配置
2、心跳检测： 哨兵会定期向监控的节点发送PING命令来检测节点是否存活
3、节点状态变更： 当哨兵连续多次无法连接到一个节点时，它会将该节点标记为主观下线
4、故障判断和选举： 当主节点被标记为客观下线时，哨兵会执行故障判断。它会从剩余的健康主节点中选举一个作为新的主节点，并将该信息广播给其他哨兵和客户端。故障判断的逻辑考虑了多个因素，包括优先级、最近一次复制偏移量等。

5、自动故障切换： 如果主节点被标记为客观下线，哨兵会通知从节点晋升为新的主节点。同时，哨兵会更新其他从节点的配置，使其复制新的主节点。这确保了即使主节点发生故障，集群仍然可以继续提供服务。

6、监控从节点： 哨兵还会监控从节点的状态，包括从节点是否与主节点保持同步，以及从节点的复制延迟情况。如果从节点无法同步或者复制延迟过高，哨兵会将其标记为不健康。

7、节点恢复： 如果一个节点从客观下线状态恢复，哨兵会将其标记为健康，并将其重新纳入集群中。从节点恢复后，它会重新同步主节点的数据。

8、配置更新： 如果集群的拓扑发生变化，例如添加或移除节点，哨兵会自动更新配置，以便客户端能够正确连接到集群。

9、事件通知： 哨兵通过发布订阅机制向订阅者（通常是客户端）发送有关集群状态变化的消息。这使得应用程序能够根据实时的集群状态做出相应的决策。

10、持续监控： 哨兵会持续地监控集群中的节点，定期执行心跳检测、状态更新和故障判断，以确保集群的稳定运行。

哨兵数量上怎么设置

哨兵最小是3或者5为什么是奇数，主要是为了考虑平票的问题。

选举流程-如何选定新主库

什么情况下选新库

主观下线（Subjectively Down，简称SDOWN）

定义：当一个哨兵实例自己判断主节点不可达（例如，在配置的down-after-milliseconds时间内没有收到主节点的有效回复），该哨兵就会认为主节点处于主观下线状态。
判断主体：单个哨兵实例。
判断标准：哨兵自己与主节点的网络连接状况或响应时间。
特点：主观下线是哨兵个体的判断，可能由于网络抖动或哨兵与主节点之间的网络问题导致误判。

客观下线（Objectively Down，简称ODOWN）

定义：当足够数量的哨兵（通常需要达到哨兵配置中设定的法定人数，即quorum）都认为主节点主观下线，那么哨兵集群会认为主节点处于客观下线状态。
判断主体：多个哨兵实例（哨兵集群）。
判断标准：由多个哨兵共同判断，通常需要达到quorum个哨兵同意。 quorum=总数除以2+1
特点：客观下线是哨兵集群的共识，减少了误判的可能性，更可靠。

哨兵中选举Leader

当主节点客观下线，那么就需要一个哨兵，在多个从节点中，选择一个从节点作为主节点。那么哪个哨兵来做呢？ 这就涉及到哨兵选举，选择一个哨兵作为Leader。

Redis哨兵模式中选举Leader是为了防止脑裂（split-brain）和确保故障转移的原子性

哨兵选举原理：基于Raft的选举机制

选举触发
1. 主节点被标记为客观下线
2. 当前没有正在进行的选举
3. 触发新选举周期

进入选举周期（Epoch）
1、每个选举周期都有唯一的epoch编号
2、全局递增的纪元号
3、当前投票给哪个哨兵

投票请求和响应
1、向其他哨兵发送投票请求

投票规则：
1. 每个哨兵在每个epoch只能投一票
2. 投票给配置更新（epoch更大）的候选者
3. 先到先得

3个哨兵的选举过程-案例：

3个哨兵节点
哨兵A (运行ID: sentinel-a)
哨兵B (运行ID: sentinel-b)  
哨兵C (运行ID: sentinel-c)

# 主节点 master1 客观下线
# quorum = 2 (需要至少2票)

选举时间线示例

# T+0秒: 主节点客观下线，所有哨兵检测到
# 每个哨兵等待随机时间（避免同时发起选举）

# T+1秒: 哨兵A等待时间最短，首先发起选举
哨兵A → 广播: "我是候选者，epoch=101，请投我一票！"

# T+1.1秒: 哨兵B收到请求
哨兵B检查: "我还没投过票，epoch=101 ≥ 我的当前epoch(100)"
哨兵B → 哨兵A: "我投给你！"

# T+1.2秒: 哨兵C收到请求  
哨兵C检查: "我还没投过票，epoch=101 ≥ 我的当前epoch(100)"
哨兵C → 哨兵A: "我投给你！"

# T+1.3秒: 哨兵A统计票数
已获票数: 自己1票 + 哨兵B1票 + 哨兵C1票 = 3票
总哨兵数: 3，需要多数票: 2票 ✅
哨兵A成为Leader！

# T+1.4秒: 哨兵A广播选举结果
哨兵A → 所有哨兵: "选举完成！我是Leader，epoch=101"

当2个哨兵并发，都发出了选举动作会怎么样？

# 假设哨兵A和哨兵B同时发起选举，注意如果是并发的情况下，epoch一定是一样的，
这个没关系。：
T+0秒: 哨兵A发起选举，epoch=101
T+0秒: 哨兵B也发起选举，epoch=101

T+0.1秒: 哨兵C先收到A的请求
哨兵C → 哨兵A: "我投给你！"

T+0.2秒: 哨兵C收到B的请求，但已经投过票
哨兵C → 哨兵B: "抱歉，已投票给A"

# 票数统计：
哨兵A: 自己1票 + 哨兵C1票 = 2票 → 达到quorum(2) → 获胜
哨兵B: 自己1票 = 1票 → 未达到quorum → 失败

# 哨兵B接受结果，承认哨兵A为Leader

从节点成为主节点

从节点选择逻辑

健康状态过滤
1、检查从节点是否在线且与主节点断开时间不超过阈值，拿到满足条件的从节点。

优先级排序

# 从节点配置文件中的优先级设置
# redis.conf
配置从节点的优先级：slave-priority 100 # 默认值，数值越小优先级越高


按优先级升序排列（数值小的优先级高），选择优先级最高的，如果优先级一样，进行下一步，否则结束

复制偏移量比较
# 选择复制偏移量最大的（数据最新的），如果复制偏移量都一样。进行下一步。

运行ID作为最后裁决

如果所有条件都相同，选择运行ID最小的

案例

案例-3个从节点的选择过程

# 3个从节点信息
从节点S1: 
  - IP: 192.168.1.101, Port: 6380
  - slave-priority: 100 (默认)
  - 复制偏移量: 105000
  - 运行ID: redis-s1-aaa

从节点S2:
  - IP: 192.168.1.102, Port: 6381  
  - slave-priority: 50 (更高优先级)
  - 复制偏移量: 104500
  - 运行ID: redis-s2-bbb

从节点S3:
  - IP: 192.168.1.103, Port: 6382
  - slave-priority: 100 (默认)
  - 复制偏移量: 105200 (最新)
  - 运行ID: redis-s3-ccc

最终选择：192.168.1.102作为主节点。

其他案例场景

场景1：优先级不同
节点A: priority=50, offset=1000
节点B: priority=100, offset=2000
节点C: priority=100, offset=1500

结果: ✅ 选择节点A（优先级最高）


场景2：优先级相同，偏移量不同
节点A: priority=100, offset=2000
节点B: priority=100, offset=1500  
节点C: priority=100, offset=1000

结果: ✅ 选择节点A（偏移量最大，数据最新）

完全相同的节点
节点A: priority=100, offset=1000, runid=redis-aaa
节点B: priority=100, offset=1000, runid=redis-bbb
节点C: priority=100, offset=1000, runid=redis-ccc

结果: ✅ 选择节点A（运行ID最小，字母顺序）

旧主节点会变成新主节点的一个从节点。其他从节点会重新配置，指向新的主节点。这个过程会保证尽量不丢失数据，并且保证整个集群的高可用性。

Redis哨兵模式选举用的是Redis Sentinel自主选举
redis哨兵模式详细介绍：跳转

问题

1.脑裂问题
出现在主节点和哨兵之间网络原因，而且有多数以上的哨兵认为主节点宕机，则再从会从节点现在一个主，这个时候客户端代码还是可以连接到之前的主节点的可以写数据，此时哨兵选举了新的主节点，然后之前的主节点网络恢复了，然后之前的主节点，备份现在的主节点数据，造成数据不完整

1、配置防护（最重要）
# 主节点中，必须配置的参数
min-slaves-to-write 1    # 至少1个从节点
min-slaves-max-lag 10    # 最大延迟10秒

# 含义：主节点至少需要1个从节点正常连接，作用：确保数据同步到至少1个从节点后才认为写入"安全"
# 含义：从节点的复制延迟不能超过10秒，作用：定义"正常连接"的标准（延迟在10秒内）


2、架构设计
部署至少3个哨兵在不同网络区域
主从节点分布在不同可用区
客户端通过哨兵发现主节点，不直连主节点IP

2. 异步复制数据丢失问题,
   因为是异步复制数据，如果主节点和从节点直接数据同步太慢，在这之间主节点宕机，而且是真的宕机，这个时候从节点替换主节点，丢失了数据。哨兵-不管怎么样配置，都没有办法保证数据百分之白不丢失，只能尽可能少量丢数据

Redis的异步复制架构确实无法保证100%数据不丢失，这是CAP定理中在分区容忍性(P)和
可用性(A)前提下对一致性(C)的权衡。但我们可以通过多种方案来最大限度减少数据丢失风险。

1、最大化安全配置
# 持久化强化
appendonly yes
appendfsync always           # 每个命令都刷盘（性能代价大）
auto-aof-rewrite-percentage 0 # 关闭AOF重写，避免阻塞


2、客户端层防护机制
WAIT命令的合理使用，重要数据写入，使用WAIT命令确认

1、主节点先执行写入
2、等待从节点确认（至少2个从节点，超时5秒）
3、从节点确认数量大于2，那就认为数据已同步，否则就记录日志或告警。