Redis数据库笔记——Sentinel哨兵机制

大家好,这里是编程Cookbook,关注公众号「编程Cookbook」,获取更多面试资料。本文详细介绍Redis的Sentinel哨兵机制,包括其原理,哨兵选举,配置等内容。



Redis 哨兵机制(Redis Sentinel)

关注公众号「编程Cookbook」,获取更多编程学习/面试资料!

什么是 Redis 哨兵机制?

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

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

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

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

关注公众号「编程Cookbook」,获取更多编程学习/面试资料!

为什么需要 Redis 哨兵机制?

  1. 单点故障(SPOF)
    Redis 在主从复制模式下,主节点通常处理写操作,而从节点负责读操作。如果主节点发生故障,Redis 就会进入不可用状态,导致整个系统无法正常工作。没有 Redis 哨兵机制,系统无法自动进行恢复,需要手动介入,这会增加运维成本,并导致服务中断。

  2. 故障恢复能力
    在出现主节点故障时,如果没有自动故障转移机制,应用程序将无法继续使用 Redis 数据库。哨兵机制能在故障发生时快速将某个从节点提升为新的主节点,保证数据持续可用

哨兵机制的核心功能

  1. 故障监控

    • 哨兵通过不断检测 Redis 实例的健康状态(主节点和从节点),判断它们是否正常运行
    • 每个哨兵实例定期向主节点和从节点发送 PING 命令,检查其可达性和响应状态。【这点和主从复制的心跳机制相似】
    • 如果一个 Redis 实例(主节点或从节点)超过了指定的超时时间没有响应,哨兵会认为该节点出现故障。
  2. 自动故障转移

    • 当哨兵检测到主节点出现故障时,会启动故障转移机制。
    • 哨兵会选举一个从节点,并将其提升为新的主节点。这个过程是自动化的,不需要人工干预。
    • 所有其他的从节点会重新连接新的主节点,并开始同步数据。这样,系统可以保持数据的可用性和一致性。
  3. 通知机制

    • 哨兵会在故障检测和故障转移过程中,向外部系统(如管理平台或通知服务)发送事件通知。
    • 这些通知可以帮助管理员及时了解系统状态,进行进一步的维护和操作。
  4. 配置提供

    • 哨兵可以作为配置提供者,告诉客户端主节点的地址。
    • 客户端通过与哨兵通信,获取当前主节点的信息,并连接到新的主节点。这对于故障转移后的自动恢复至关重要。

哨兵的工作流程

关注公众号「编程Cookbook」,获取更多编程学习/面试资料!

故障转移示意图:

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

    • 哨兵通过定期向 Redis 实例发送 PING 命令来监控 Redis 节点的健康状态。每个哨兵都有一个默认的监控时间间隔(通常是每 1 秒一次)。
    • 如果哨兵没有收到来自某个节点的响应,则该节点会被认为是不可用的。
  2. 故障检测

    • 主观下线 (SDOWN):当一个节点没有响应时,哨兵会将该节点标记为“主观下线”。这表示(某)哨兵认为该节点有问题,但还需要进一步确认。
    • 客观下线 (ODOWN)多个哨兵验证同一节点不可用时,节点将被标记为“客观下线”,此时触发故障转移过程。为了提高容错能力,至少需要超过半数的哨兵认为节点故障才能进行此标记
  3. 故障转移

    • 领导者哨兵选举:在故障转移过程中,多个哨兵需要协调选择新的主节点。为避免冲突,哨兵会选举出一个“领导者哨兵”,由其来负责选择新的主节点,并协调整个故障转移的过程。领导者哨兵负责所有的故障检测、决策和通知工作,确保系统的同步和一致性。
    • 选举新主节点:当主节点被标记为 ODOWN,领导者哨兵会通过 选举机制 来选择一个新的主节点。通常,选举机制会选择与故障节点同步进度最新的从节点作为新的主节点。也就是会选择同步进度(复制偏移量)最接近的从节点作为新的主节点。所有其他从节点都会开始同步新的主节点的数据。
  4. 通知客户端

    • 一旦故障转移完成,哨兵会通知所有相关的 Redis 客户端,让它们知道新的主节点的地址。客户端可以通过与哨兵通信来获取新的主节点地址。
    • 哨兵还可以向外部监控系统发送事件通知,告知管理员发生了故障转移。
  5. 持续监控和恢复

    • 哨兵会持续监控新的主节点和所有从节点,确保它们的健康状况。
    • 如果新主节点再次出现故障,哨兵会重复故障转移过程,保证系统的高可用性。
  6. 故障修复

    • 故障修复通常需要人工干预,修复过程包括恢复故障主节点、将其重新加入集群、以及必要时将其恢复为主节点。这个过程在一些情况下可以部分自动化,但总体上仍然依赖人工配置或手动操作。
领导者哨兵选举

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

  1. 第一个发现该master挂了的哨兵,向每个哨兵发送命令,让对方选举自己成为领头哨兵。

  2. 其他哨兵如果没有选举过他人,就会将这一票投给第一个发现该master挂了的哨兵。

  3. 第一个发现该master挂了的哨兵如果发现由超过设定的quoram参数(法定人数,通常是 哨兵节点数量的一半+1 )个哨兵,那么该哨兵就成了领头哨兵。

  4. 如果多个哨兵同时参与这个选举,那么就会重复该过程,直到选出一个领头哨兵。

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

新主节点选举

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

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

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

  • 复制偏移量(replication offset)

    • Redis 使用复制偏移量来表示主节点和从节点之间的数据同步进度。领头哨兵会选择复制偏移量最接近故障主节点的从节点,确保新主节点的数据同步进度尽可能接近故障的主节点,减少数据丢失。
    • 如果多个从节点的复制偏移量相同,哨兵可能会选择其他因素来决定(例如从节点的健康状况、复制延迟等)。
  • 从节点的健康状态

    • 哨兵会检查所有从节点的健康状态。只有那些没有任何问题、能够正常启动的从节点才能被选为新的主节点。
  • 从节点数量和选举机制

    • 如果有多个从节点符合条件,哨兵会进一步选举出其中一个作为新的主节点。

哨兵配置

关注公众号「编程Cookbook」,获取更多编程学习/面试资料!

  1. 启用哨兵模式
    要启用哨兵模式,需要在 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:指定故障转移过程的超时时间。
  2. 客户端连接哨兵
    客户端可以通过连接到哨兵来获取当前的主节点地址,哨兵会返回主节点的 IP 和端口信息。

    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 集群中提供可靠的自动化管理和故障恢复能力,适用于生产环境中对高可用性有要求的场景。

关注公众号「编程Cookbook」,获取更多编程学习/面试资料!

历史文章

MySQL数据库

  1. MySQL数据库笔记——数据库三范式
  2. MySQL数据库笔记——存储引擎(InnoDB、MyISAM、MEMORY、ARCHIVE)
  3. MySQL数据库笔记——常见的几种锁分类
  4. MySQL数据库笔记——索引介绍
  5. MySQL数据库笔记——事务介绍
  6. MySQL数据库笔记——索引结构之B+树
  7. MySQL数据库笔记——索引潜规则(回表查询、索引覆盖、索引下推)
  8. MySQL数据库笔记——索引潜规则(最左前缀原则)
  9. MySQL数据库笔记——常见慢查询优化方式
  10. MySQL数据库笔记——日志介绍
  11. MySQL数据库笔记——多版本并发控制MVCC
  12. MySQL数据库笔记——主从复制

Redis

  1. Redis数据库笔记——数据结构类型
  2. Redis数据库——Redis雪崩、穿透、击穿
  3. Redis数据库——内存淘汰机制
  4. Redis数据库笔记——内存分配器
  5. Redis数据库笔记——内存预分配
  6. Redis数据库笔记—— Hash(哈希)的扩容机制(rehash)
  7. Redis数据库笔记——ZSet的底层实现(跳表)
  8. Redis数据库笔记——布隆过滤器(BloomFilter)
  9. Redis数据库笔记——持久化机制
  10. Redis数据库笔记——部署模式
  11. Redis数据库笔记——主从复制
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值