进阶的Redis之Sentinel原理及实战

Redis作为一款高效的内存数据库,可作用于方方面面,相信如今项目的开发都离不开它。大家可能都知道Redis是高可用的,但很少知道具体高可用是利用什么去实现的。

抛两个问题:

  1. 只部署一个Redis实例,如果这个实例挂了就无法读写数据了,那怎么做实例备份?
  2. 部署了两个Redis,一主一从做复制,从只读,如果主挂了,那这个服务还怎么正常对外服务?

显然,要做到高可用,首先要有足够多的Redis实例(最好三台以上),一主多从。然后再主挂了的时候,要有机制让其他实例替代主的位置。

哨兵服务Sentinel,就是这套题的答案,它是一个检查redis服务下线并补偿的服务。下面我们来完整了解下Sentinel的作用和工作原理,最后实验下它的效果。

Sentinel简介

直接看下最新版的官方的介绍

大致意思是,Sentinel为Redis提供高可用。利用Sentinel,在无人干预的情况下,可用让Redis服务抵御一定程度的故障。

宏观层面,Sentinel拥有以下几个功能:

  • 监控(Monitoring),Sentinel可用持续不断地检查主从实例是否如期运行。
  • 通知(Notification),当某个被监控的Redis实例出问题的时候,可以通过API接口向系统管理员和其他应用服务发通知。
  • 自动故障转移(Automatic failover),当主出现故障时,Sentinel会自动启动故障转移流程,把其中一个从库提升为主库,然后其他从库重新认新主。集群也会返回新的地址给客户端。
  • 配置提供(Configuration provider),Sentinel可以作为服务注册中心,让客户端直接连接请求Sentinel去获取主库的地址。如果出现自动故障转移,Sentinel也会提供新的主库地址。

P.S. 文中所描述的库和服务器都是指Redis的server实例。

高可用工作原理

下面我们以Sentinel的故障转移为核心,来看看它具体是怎么实现Sentinel的。

  • 启动并初始化Sentinel
    执行 redis-sentinel /usr/local/etc/redis-sentinel.conf
    Sentinel是Redis的特殊模式,执行redis-server /usr/local/etc/redis-sentinel.conf --sentinel命令也是完全一样的。其实在启动Sentinel的时候,redis只是把运行代码切换到sentinel模式。
    Sentinel模式下,具体的功能如图,
  • 初始化master属性
    配置文件中是需要指定了监控的主库,然后再初始化阶段把Sentinel实例中的master属性初始化。
  • Sentinel向主库建立网络连接
    在master属性初始化后,Sentinel首先就需要和该主库建立网络连接。Sentinel会对每个被监视的主库建立两个链接。一个命令链接,用于给主库发送操作命令的。另一个是订阅链接,订阅主库的__sentinel__:hello频道,主要用于发现其他Sentinel的存在(后面会说到)。
  • 获取主库信息
    Sentinel默认以十秒一次,通过命令链接,给主库发送INFO命令,来获取主库的当前信息。信息包括该主库的运行id以及该主库下所有从库的ip端口。
  • 根据主库信息,获取从库信息
    如果Sentinel在获取主库信息时候,发现有新未链接的从库,会与该从库同样建立两条链接。建立链接后,Sentinel同样会给从库通过命令链接发送INFO命令,从而获取该从库的服务器信息。
  • 向主和从发送服务器消息
    Sentinel默认以两秒一次,通过命令链接,对__sentinel__:hello频道发送Sentinel自身信息与被监控的主库信息。该频道是之前Sentinel与所有主从库都建立的频道链接。所以被监视的主从库都会收到发送消息的Sentinel信息与主库信息。
  • 接收主从频道消息,找出其他Sentinel
    因为Sentinel订阅了__sentinel__:hello的消息,所以在之前向主从库发送消息的时候,同时会通过订阅链接收到订阅的内容。这个作用在于,部署多个Sentinel时,其他Sentinel就会知道发送消息的那个Sentinel的存在。
  • 与其他Sentinel创建连接
    当Sentinel发现有其他Sentinel存在的时候,就会与其他Sentinel建立一条命令链接,用于在后续情况发送命令。但Sentinel之间不会建立订阅链接,因为订阅链接是用于发现其他Sentinel的存在的。
  • 主观下线
    Sentinel默认以一秒一次,通过命令链接,对所有服务器(包括主从、其他Sentinel)发送PING命令来检测服务是否在线。如果一个服务在参数down-after-millisecond内连续返回无效回复,那么Sentinel会对该服务标记为主观下线状态。所谓的主观下线,就是Sentinel自己认为该服务下线了。
  • 主库客观下线
    当Sentinel将一个主库主观下线后,为了判断是否其他Sentinel都认为该主库下线了,会通过is-master-down-by-addr命令询问。当认为下线的Sentinel数据大于配置中的quorum数时,Sentinel会标记该主库为客观下线。
  • 选举Sentinel leader
    当Sentinel将主库客观下线后,会与其他Sentinel进行协商,选举出一个leader来执行后续的Failover(故障转移)。
  • 选出新主库
    leader按从库优先级配置、复制偏移量、运行id来选举出新的主库。leader会向挑选出来的从库发送SLAVEOF no one命令,将从库提升为master角色,成为主库。
  • 让从库复制新主库
    在选出新主库后,就是让原来的从库去复制新主库。leader Sentinel通过给剩余旧从库发送SLAVEOF命令即可。
  • 旧主库变为新主库的从库
    当原来故障的主库再次上线的时候,Sentinel会发送SLAVEOF命令,让其成为新主库的从库。

实验实战

  1. 启动三个Redis实例

    1
    2
    3
    redis-server --port 6379 &
    redis-server --port 6380 &
    redis-server --port 6381 &

    注意最好各个实例的priority不同,用于故障转移选主。否则可能会找不到新主。

  2. 把80与81的实例作为79的从服务器
    在80与81上执行

    1
    SLAVEOF 127.0.0.1 6379
  3. 启动sentinel

    1
    redis-sentinel /usr/local/etc/redis-sentinel.conf

    其中的Sentinel配置包含

    1
    sentinel monitor mymaster 127.0.0.1 6379 1

    可以观察到sentinel已经添加了一主两从的监控。

  4. 把主库的实例关掉

    1
    127.0.0.1:6379> SHUTDOWN
  5. 故障转移
    redis-cli连上sentinel可以看到,当sentinel检测到主库下线,后面根据一些列操作把81替换为主库,其他库为81的从库,并且79是下线的新从库。


    更多技术文章、精彩干货,请关注
    博客:zackku.com
    微信公众号:Zack说码

听说你想请我喝下午茶?~