Redis数据库——Sentinel哨兵机制

2025-01-09 来源：个人技术集锦

Redis 哨兵机制（Redis Sentinel）

什么是 Redis 哨兵机制？

Redis 哨兵（Sentinel）是 Redis 提供的高可用性解决方案，旨在确保 Redis 服务的高可用性和自动故障转移。它通过监控 Redis 主节点和从节点的运行状态，自动检测故障并实现故障转移，保证系统在出现故障时能够自动恢复，避免单点故障导致的服务中断。

Redis 哨兵机制由多个哨兵实例组成，这些实例彼此协作来监控 Redis 节点的状态。每个哨兵实例都可以独立工作，但它们之间会交换信息，以确保整个系统的一致性。其由下面的内容组成：

哨兵节点：每个哨兵节点独立运行并执行监控、故障检测、故障转移等任务，并不负责读写数据。Redis 哨兵需要至少三个哨兵节点，并且最好是奇数个哨兵节点来参与选举投票。
主节点：负责处理写请求的 Redis 节点。
从节点：负责复制主节点的数据，并可以处理部分读请求。

哨兵节点之间通过 quorum（多数投票机制）来决定一个 Redis 节点是否故障。当哨兵发现一个节点不可用时，只有在超过半数的哨兵节点确认该节点故障时，才会触发故障转移。

为什么需要 Redis 哨兵机制？

哨兵机制的核心功能

故障监控：
- 哨兵通过不断检测 Redis 实例的健康状态（主节点和从节点），判断它们是否正常运行。
- 每个哨兵实例定期向主节点和从节点发送 PING 命令，检查其可达性和响应状态。【这点和主从复制的心跳机制相似】
- 如果一个 Redis 实例（主节点或从节点）超过了指定的超时时间没有响应，哨兵会认为该节点出现故障。
自动故障转移：
- 当哨兵检测到主节点出现故障时，会启动故障转移机制。
- 哨兵会选举一个从节点，并将其提升为新的主节点。这个过程是自动化的，不需要人工干预。
- 所有其他的从节点会重新连接新的主节点，并开始同步数据。这样，系统可以保持数据的可用性和一致性。
通知机制：
- 哨兵会在故障检测和故障转移过程中，向外部系统（如管理平台或通知服务）发送事件通知。
- 这些通知可以帮助管理员及时了解系统状态，进行进一步的维护和操作。
配置提供：
- 哨兵可以作为配置提供者，告诉客户端主节点的地址。
- 客户端通过与哨兵通信，获取当前主节点的信息，并连接到新的主节点。这对于故障转移后的自动恢复至关重要。

哨兵的工作流程

故障转移示意图：

主节点故障 → 哨兵检测到故障 → 选举领头哨兵
领头哨兵选择新主节点 → 新主节点开始接管主节点的职责
其他从节点同步数据 → 系统恢复正常。

监控：
- 哨兵通过定期向 Redis 实例发送 PING 命令来监控 Redis 节点的健康状态。每个哨兵都有一个默认的监控时间间隔（通常是每 1 秒一次）。
- 如果哨兵没有收到来自某个节点的响应，则该节点会被认为是不可用的。
故障检测：
- 主观下线 (SDOWN)：当一个节点没有响应时，哨兵会将该节点标记为“主观下线”。这表示哨兵认为该节点有问题，但还需要进一步确认。
- 客观下线 (ODOWN)：多个哨兵验证同一节点不可用时，节点将被标记为“客观下线”，此时触发故障转移过程。为了提高容错能力，至少需要超过半数的哨兵认为节点故障才能进行此标记。
故障转移：
- 领导者哨兵选举：在故障转移过程中，多个哨兵需要协调选择新的主节点。为避免冲突，哨兵会选举出一个“领导者哨兵”，由其来负责选择新的主节点，并协调整个故障转移的过程。领导者哨兵负责所有的故障检测、决策和通知工作，确保系统的同步和一致性。
- 选举新主节点：当主节点被标记为 ODOWN，领导者哨兵会通过 选举机制 来选择一个新的主节点。通常，选举机制会选择与故障节点同步进度最新的从节点作为新的主节点。也就是会选择同步进度（复制偏移量）最接近的从节点作为新的主节点。所有其他从节点都会开始同步新的主节点的数据。
通知客户端：
- 一旦故障转移完成，哨兵会通知所有相关的 Redis 客户端，让它们知道新的主节点的地址。客户端可以通过与哨兵通信来获取新的主节点地址。
- 哨兵还可以向外部监控系统发送事件通知，告知管理员发生了故障转移。
持续监控和恢复：
- 哨兵会持续监控新的主节点和所有从节点，确保它们的健康状况。
- 如果新主节点再次出现故障，哨兵会重复故障转移过程，保证系统的高可用性。
故障修复：
- 故障修复通常需要人工干预，修复过程包括恢复故障主节点、将其重新加入集群、以及必要时将其恢复为主节点。这个过程在一些情况下可以部分自动化，但总体上仍然依赖人工配置或手动操作。

领导者哨兵选举

在 Redis 哨兵机制 中，领导者哨兵（Leader Sentinel）是一个在故障转移（failover）过程中起关键作用的哨兵节点。为了避免多个哨兵同时执行故障转移操作，哨兵节点需要通过选举选出一个领导者哨兵，来负责选择新的主节点，并协调整个故障转移的过程。其过程如下：

第一个发现该master挂了的哨兵，向每个哨兵发送命令，让对方选举自己成为领头哨兵。
其他哨兵如果没有选举过他人，就会将这一票投给第一个发现该master挂了的哨兵。
第一个发现该master挂了的哨兵如果发现由超过设定的quoram参数（法定人数，通常是哨兵节点数量的一半+1 ）个哨兵，那么该哨兵就成了领头哨兵。
如果多个哨兵同时参与这个选举，那么就会重复该过程，直到选出一个领头哨兵。

选出领头哨兵后，就开始了主节点的故障转移，会从选出一个从数据库作为新的master。

新主节点选举

从节点出现故障时，Redis 哨兵并不需要进行选举投票。因为从节点的角色是只读的，不会影响到整个系统的主从复制架构。

如果一个从节点出现故障，哨兵 检测到从节点的不可用性，并将其标记为 “下线”（SLAVE DOWN），根据从节点的健康状态来判断是否需要将其恢复或替换。

主节点出现故障时，领头哨兵才会触发选举过程。新的主节点会从所有的从节点中选择，并基于以下几个标准进行判断：

复制偏移量（replication offset）：
- Redis 使用复制偏移量来表示主节点和从节点之间的数据同步进度。领头哨兵会选择复制偏移量最接近故障主节点的从节点，确保新主节点的数据同步进度尽可能接近故障的主节点，减少数据丢失。
- 如果多个从节点的复制偏移量相同，哨兵可能会选择其他因素来决定（例如从节点的健康状况、复制延迟等）。
从节点的健康状态：
- 哨兵会检查所有从节点的健康状态。只有那些没有任何问题、能够正常启动的从节点才能被选为新的主节点。
从节点数量和选举机制：
- 如果有多个从节点符合条件，哨兵会进一步选举出其中一个作为新的主节点。

哨兵配置

启用哨兵模式：
要启用哨兵模式，需要在 Redis 配置文件中使用 sentinel 配置项。例如：
```
sentinel monitor mymaster <master-ip> <master-port> <quorum>
sentinel auth-pass mymaster <password>    # 如果主节点启用了认证
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
```
- monitor：指定主节点的 IP 地址和端口，并设置哨兵节点需要达成的确认数量（quorum），即多少个哨兵需要同意主节点故障才能触发故障转移。
- auth-pass：指定主节点的认证密码（如果启用认证的话）。
- down-after-milliseconds：指定主节点连续失去联系的时间（毫秒）。
- parallel-syncs：指定故障转移时，从节点同步数据的并行数。
- failover-timeout：指定故障转移过程的超时时间。

import redis

sentinel = redis.StrictRedis(host='sentinel_ip', port=26379)
master = sentinel.master_for('mymaster', db=0)  # 获取主节点
slave = sentinel.slave_for('mymaster', db=0)    # 获取从节点

哨兵机制的优缺点

优点：

高可用性：Redis 哨兵能够在主节点故障时自动切换到从节点，保证 Redis 服务不间断。
自动故障转移：无需人工干预，哨兵会自动处理节点故障。
故障通知：哨兵会向外部系统发送通知，帮助管理员了解系统状态。
客户端透明：客户端可以通过哨兵获取主节点信息，无需知道故障转移的细节。

缺点：

复杂性：需要配置多个哨兵节点进行协作，配置和管理较为复杂。
故障转移延迟：在发生故障时，哨兵需要一定的时间来检测故障并执行故障转移。
对网络的要求高：哨兵和 Redis 实例之间需要保持可靠的网络连接，网络不稳定时可能影响故障检测和转移的效率。

总结

Redis 哨兵机制是实现 Redis 高可用性的关键组件，它通过监控 Redis 主节点和从节点的状态，自动进行故障检测和故障转移，确保系统的持续可用性。虽然配置和管理相对复杂，但它能够在 Redis 集群中提供可靠的自动化管理和故障恢复能力，适用于生产环境中对高可用性有要求的场景。

显示全文

全部栏目