• 四、redis系列之主从复制与哨兵机制


    1. 绪言

      在现实应用环境中,出于数据容量、容灾、性能等因素的考虑,往往不会只使用一台服务器,而是使用集群的方式。Redis 中也有类似的维持一主多从的方式提高 Redis 集群的高可用性的方案,而其中不可避免的则是如何保证主从实例间的数据一致性,复制(Replication)是其解决办法。本篇介绍redis的主从复制及哨兵机制。

    2. redis主从复制

    2.1 主从拓扑

      Redis 支持简单且易用的主从复制(master-slave replication)功能, 这一功能可以让从服务器(slave server)成为主服务器(master server)的精确复制品,实现了数据的备份。一个主服务器可以有多个从服务器,而且不仅主服务器可以有从服务器, 从服务器也可以有自己的从服务器, 多个从服务器之间可以构成一个图状结构。
    下图为redis多种主从模式的拓扑结构:
    1)一主一从:

      这一拓扑结构主要用于主节点故障转移从节点,当主节点的“写”命令并发高且需要持久化,可以只在从节点开启AOF(主节点不需要),这样即保证了数据的安全性,也避免持久化对主节点的影响
    2)一主多从:

      这一结构主要针对“读”较多的场景,“读”由多个从节点来分担,但节点越多,主节点同步到多节点的次数也越多,影响带宽,也加重主节点的稳定。
    3)树状主从

      这一拓扑结构是对一主多从的补充,主节点只推送一次数据到slave1和slave2,再由从slave2推送到slave3和 slave4,减轻主节点推送的压力。

    2.2 配置

      我在virtualBox上配置了4服务器,机器名分别为chb、chb1、chb2、chb3,ip地址如图所示,且都已经安装配置好了redis数据库。我们要将chb设为主服务器,其他三台配置为从服务器,该如何配置呢?

      Redis主从服务器配置有一条规律叫做“配主不配从”,也就是说,进行主从服务器配置时,对于主服务器,我们不需要进行配置,只要配置从服务器即可。所以,在上图的4台机器中,我们只需要对chb1、chb2、chb3进行配置即可。出于安全考虑,在配置前,我们在系统根目录下新建一个myredis目录,并将redis的配置文件(redis.conf)拷贝一份到该目录下,本篇主从复制操作我们主要基于该配置文件进行(当然你也可以直接在安装目录配置下进行,非硬性要求)。对从服务器(chb1、chb2、chb3)刚拷贝好的配置文件添加如下配置:

    slaveof 192.168.56.100 6379

      也就是:slaveof 主服务器ip 端口号。

      然后修改配置中的bind属性,bind属性默认绑定127.0.0.1,如果redis主服务器绑定了127.0.0.1,那么跨服务器IP的访问就会失败,从服务器用IP和端口访问主的时候,主服务器发现本机6379端口绑在了127.0.0.1上,也就是只能本机才能访问,外部请求会被过滤,这是Linux的网络安全策略管理的。所以我们要进行修改(注:为方便下面的哨兵部分内容测试,4台服务器都要修改):

    bind 0.0.0.0

      这是在测试环境上的配置,如果在生产环境中,就要绑定主服务器的实际ip和端口。

      然后如下图所示,我们分别启动了4台服务器上的redis:


      然后,可以通过info replication命令查看主从信息:

      可以看到,chb(主服务器)上有了3台从服务器,在从服务器(chb1、chb2、chb3)上可以看到从属于chb。
    上面使用的是在配置文件中进行主从服务器配置,还有一种方法就是通过命令行的方式配置,这种方式直接在从服务器上运行命令slaveof 192.168.56.100 6379就可以了(当然,也要去配置文件中修改bind属性)。通过命令行的方式修改是一次性的,也就是说,当redis服务关闭后,下次重启就无效了。

    2.3 功能

      主从复制有什么作用呢?
      第一:容灾恢复。当主服务器发生故障时,从服务器还有数据备份,亦可转换为主服务器使用。
      我们尝试分别在主从服务器上分别进行数据操作:

      我们现在chb主服务器上新建了k1、k2,然后分别在三台从服务器上获取k1、k2的值,发现时可以成功获取的。证明从服务器可以成功复制主服务器上的数据,而且复制的是主服务器上的所有数据,可不单单是主从关系建立之后才新建的数据。
      第二:读写分离。对于读占比较高的场景,可以通过把一部分流量分摊导出从服务器 来减轻主主服务器压力,同时需要主要只对主节点执行写操作。

      如上图所示,只能在主服务器上进行写操作,在从服务器上的写操作都失败了,这就实现了读写分离。

    3. 哨兵(sentinel)

      上面说到容灾恢复是提到主服务器出现故障(宕机)或者关机时,从服务器可以转换成主服务器来用,从服务器怎么结束之前的主从关系,转换为主服务器呢?

    slaveof no one

      如上图所示,我们先把chb主服务器上的redis服务关闭,然后在chb1上执行slaveof no one
    命令,可以看到,chb1已经变成了master,chb2和chb3还是从属于之前的chb。如果我们现在想要chb2和chb3从属于chb1,就需要重新进行配置。
    但是,在实际生产环境中,不可能时时刻刻都人为得进行监控主服务器是否正常工作,所以,主服务器如果发生故障,最好让服务器自动完成主从转换,并修改其他从服务器的从属。这就涉及到redis的哨兵(sentinel)了。

    3.1 Sentinel的主要任务

      Redis 的 Sentinel 系统用于管理多个 Redis 服务器(instance), 该系统执行以下三个任务:
      1)监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
      2)提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
      3)自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。
      Redis Sentinel 是一个分布式系统, 我们可以在一个架构中运行多个 Sentinel 进程(progress), 这些进程使用流言协议(gossip protocols)来接收关于主服务器是否下线的信息, 并使用投票协议(agreement protocols)来决定是否执行自动故障迁移, 以及选择哪个从服务器作为新的主服务器。

    3.2 配置sentinel

      在chb、chb1、chb2三台服务器/myredis目录下新建一个名为sentinel.conf的文件,并在文件中输入一下内容:

    #哨兵端口 
    port 26379
    #2表示在sentinel集群中最少需要有两个节点检测到redis主节点出故障就进行主从切换
    sentinel monitor mymaster
    192.168.56.100 6379 2

    #如果3s内mymaster无响应,则认为mymaster宕机了
    sentinel down-after-milliseconds mymaster 3000
    #如果10秒后,mysater仍没活过来,则启动failover
    sentinel failover
    -timeout mymaster 10000

    #后台执行
    daemonize yes
    #指定工作目录
    dir
    "/myredis"

    protected-mode no
    #制定日志文件
    logfile
    "/myredis/sentinel.log"
    #redis主节点密码,本篇中并未对主服务器设置密码,故省略 #sentinel auth
    -pass mymaster 123456

      第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器, 这个主服务器的 IP 地址为 192.168.56.100 , 端口号为 6379 , 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 (只要同意 Sentinel 的数量不达标,自动故障迁移就不会执行)。

      不过要注意, 无论你设置要多少个 Sentinel 同意才能判断一个服务器失效, 一个 Sentinel 都需要获得系统中多数(majority) Sentinel 的支持, 才能发起一次自动故障迁移。换句话说, 在只有少数(minority) Sentinel 进程正常运作的情况下, Sentinel 是不能执行自动故障迁移的。
      上述配置中各个选项的功能如下:
    down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。
    如果服务器在给定的毫秒数之内, 没有返回 Sentinel 发送的 PING 命令的回复, 或者返回一个错误, 那么 Sentinel 将这个服务器标记为主观下线(subjectively down,简称 SDOWN,指的是单个 Sentinel 实例对服务器做出的下线判断 )。
      不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁移: 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后, 服务器才会被标记为客观下线(objectively down, 简称 ODOWN ,指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断, 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后, 得出的服务器下线判断), 这时自动故障迁移才会执行。将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。
      parallel-syncs 选项指定了在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长。

    3.3 启动 Sentinel

      对于 redis-sentinel 程序, 你可以用以下命令来启动 Sentinel 系统:

    redis-sentinel /path/to/sentinel.conf

      对于 redis-server 程序, 你可以用以下命令来启动一个运行在 Sentinel 模式下的 Redis 服务器:

    redis-server /path/to/sentinel.conf --sentinel

      两种方法都可以启动一个 Sentinel 实例。

      启动sentinel后,还要一次启动个服务器的redis服务,然后我们再次查看主从关系如下图所示:



      同时,我们也可以在日志文件/myreids/sentinel.log中查看到信息:

    2057:X 01 Dec 2018 10:43:57.026 * +slave slave 192.168.56.101:6379 192.168.56.101 6379 @ mymaster 192.168.56.100 6379
    2057:X 01 Dec 2018 10:44:17.115 * +slave slave 192.168.56.102:6379 192.168.56.102 6379 @ mymaster 192.168.56.100 6379
    2057:X 01 Dec 2018 10:44:37.166 * +slave slave 192.168.56.103:6379 192.168.56.103 6379 @ mymaster 192.168.56.100 6379

      哨兵日志说明主从关系已建立。

      然后我们关闭chb(主服务器)上的reids服务,然后在查看主从关系:

      从上图中可以看到,主从关系已经发生了改变,关闭主服务器chb后,chb3变成了主服务器,且chb1和chb2也纷纷开始从属于chb3。那么,如果此时chb又开机上线了,是否会再次变成主服务器呢?

    从上图看出,chb就算继续上线,chb3也还是主机,chb1、chb2和新上线的chb都会从属于chb3。

  • 相关阅读:
    安装PyExecJS出现问题
    常用模块
    python2和python3的区别
    正则表达式
    MySQL之表的关系
    Python与MySQL的交互
    select 查询
    MySQL之表的连接
    bug
    黑盒测试-判定表驱动法
  • 原文地址:https://www.cnblogs.com/chenhuabin/p/10048854.html
Copyright © 2020-2023  润新知