Redis 主从、哨兵Sentinel、Jedis

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u010297957/article/details/55050098

上篇说到了Redis安装、运行。今天来看一看Redis的主从复制、Sentinel;


一、主从复制

1. 配置

Master上修改redis.conf

// 不想用密码,所以把保护模式设置为no
protected-mode no
// 其实master上不需要配置什么,这里只是取消了保护模式

Slave1Slave2上修改redis.conf

// 同样关闭保护模式
protected-mode no
// 设置本机是谁的slave
slaveof master的ip 6379
// 当配置了slaveof后,下面这条控制本机只能读
slave-read-only yes

2. Jedis操作

    // 简单设置3个连接池
    private static final JedisPool masterPool;
    private static final JedisPool slavePool1;
    private static final JedisPool slavePool2;
    static {
        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
        // 最多可以有10个连接
        jedisPoolConfig.setMaxTotal(10);
        jedisPoolConfig.setMaxIdle(5);
        jedisPoolConfig.setMinIdle(5);
        masterPool = new JedisPool(jedisPoolConfig, "111.111.111.111");
        slavePool1 = new JedisPool(jedisPoolConfig, "111.111.111.112");
        slavePool2 = new JedisPool(jedisPoolConfig, "111.111.111.113");
    }

    public static void main(String[] args) throws Exception {
        // 简单使用,通过try-with-resource
        try (Jedis jedis = masterPool.getResource()) {
            jedis.get("key1");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

3. 主从的意义

  1. Redis需要读写分离吗?
    可能大家会思考过这样一个问题,在MySQL中常用的读写分离,在Redis这种内存DB中是否还会需要?

    反对者的观点是:Redis是内存存储,读写都非常快,如果将读且分离到MasterSlaves上不仅可能造成主从不同步的麻烦,甚至不见得会提升整个DB的处理能力和速度。

    赞成者的观点是:Redis提供的MasterSlave复制功能;官网中的介绍

    Replication can be used both for scalability, in order to have multiple slaves for read-only queries (for example, slow O(N) operations can be offloaded to slaves), or simply for data redundancy.

    甚至配置文件中的参数slave-read-only yes都在提示着使用者,Redis给你提供了读写分离的功能。所以,为什么不要用呢?

    经过思考过后,我觉得:

    1 如果使用者的业务数据量不大,则完全不必做读写分离,读写均在Master上做即可。但是主从复制还是需要的,可将Slave作为简单的数据转储。
    2 如果使用者的业务数据量比较大,只用一个物理机Master承担读写已不能满足业务或性能的需求,那么则可以做读且分离。即,在项目代码中封装一下对Redis的操作(如封装Jedis操作),将写操作映射给Master,将读操作按照你自己定义的分配策略,映射给某个Slave


一个企业级系统最重要的指标就是“可用性”和“高性能”。

显然,上面的主从复制、读写分离能够简单的提供“高性能”,但也只是提升了“读”的性能,并不能扩展“写”。(写的扩展这里暂且不表)

另一方面,“可用性”也是极其重要的。如上结构可用性并不高,一旦Master宕机则Redis将立即不可写,Slave将只剩下旧数据,系统随即不可用。
必然的,Redis提供了高可用(High Availability)方案,其中之一就是Sentinel-哨兵。


二、Sentinel - 高可用

1. 什么是Sentinel?

见名知意,它是Redis提供的哨兵程序,它是分布式程序,可以这样描述它们:

哨兵一般是好几个一起站岗,他们共同监视一个Master以及其Slaves。当哨兵看到Master挂掉了,他们就会互相确认有没有看走眼,一旦多数哨兵都说它挂了,那么他们就能得出结论:Master挂了。
此时第一个发现的Sentinel会负责进行自动故障迁移,它会立即在Slaves中选出一个担任Master,所有Slaves从属于新Master,所有客户端对Master的操作转而到这台新Master上。

Sentinel的主要工作如下:

  1. 监控(Monitoring): Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

  2. 提醒(Notification): 当被监控的某个 Redis 服务器出现问题时, Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

  3. 自动故障迁移(Automatic failover): 当一个主服务器不能正常工作时, Sentinel 会开始一次自动故障迁移操作, 它会将失效主服务器的其中一个从服务器升级为新的主服务器, 并让失效主服务器的其他从服务器改为复制新的主服务器; 当客户端试图连接失效的主服务器时, 集群也会向客户端返回新主服务器的地址, 使得集群可以使用新主服务器代替失效服务器。

2. 配置Sentinel

哨兵应该被放在独立的服务器上,最好最少应该有3个哨兵(3台服务器)。

  1. 配置文件sentinel.conf

    // 26379模式是sentinel的运行端口,6379是redis-server的
    port 26379
    // 作为守护进程
    daemonize yes
    // 工作目录,设置到你统一规划的地方
    dir /tmp
    // log文件
    dir /....
    
    // protected-mode必须要设置的,不设置不行
    protected-mode no
    
    // 配置监视的Master,注意无需配置其Slave,Sentinel会自己去询问Master
    // sentinel monitor master-name ip redis-port quorum
    // quorum 哨兵们认为master客观死亡(Objectively Down)所需要的法定人。无论是否设置这个值,想要启动failover都必须有多数哨兵同意
    sentinel monitor yewu01 127.0.0.1 6379 2
    
    // 如果30000 ms后master还是不回应,就说明Master处于主观死亡(Subjectively Down)
    sentinel down-after-milliseconds yewu01 30000
    
    // 当发生failover的同时,1个slave开始与新master进行同步。意思是:此slave开始接收master的RDB文件而不能对外提供服务了,而其它slave还能对外服务(具体能否对外服务看第二个//),所以越少意味着redis能越快恢复对外服务
    // 同时还要搭配配置slave的redis.conf中的 slave-serve-stale-data参数,指定是否可用过期数据
    sentinel parallel-syncs yewu01 1
    
    // 执行failover多久算failover超时
    sentinel failover-timeout yewu01 180000
  2. 运行sentinel
    虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel , 但实际上它只是一个运行在特殊模式下的 Redis 服务器, 你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动 Redis Sentinel 。

    // 1. 用redis-server加参数 --sentinel的方式启动
    redis-server /path/to/sentinel.conf --sentinel
    // 2. 用redis-sentinel 方式启动
    redis-sentinel /path/to/sentinel.conf
    
    //注意!注意!注意!不要忘记在防火墙添加端口,我的是CentOS7,所以如下
    firewall-cmd --zone=public --add-port=26379/tcp --permanent
    
  3. 查看状态
    redis-cli -h <hostname> -p 26379登录到Sentinel;

    Sentinel 可接受的命令(官网页面搜索Sentinel API):

    • PING :返回 PONG 。
    • SENTINEL masters :列出所有被监视的主服务器,以及这些主服务器的当前状态。
    • SENTINEL master <master name>:特定主服务器的当前状态。
    • SENTINEL slaves <master name>:列出给定主服务器的所有从服务器,以及这些从服务器的当前状态。
    • SENTINEL sentinels <master name> Show a list of sentinel instances for this master, and their state.
    • SENTINEL get-master-addr-by-name <master name> : 返回给定名字的主服务器的 IP 地址和端口号。 如果这个主服务器正在执行故障转移操作, 或者针对这个主服务器的故障转移操作已经完成, 那么这个命令返回新的主服务器的 IP 地址和端口号。
    • SENTINEL reset <pattern>: 重置所有名字和给定模式 pattern 相匹配的主服务器。 pattern 参数是一个 Glob 风格的模式。 重置操作清楚主服务器目前的所有状态, 包括正在执行中的故障转移, 并移除目前已经发现和关联的, 主服务器的所有从服务器和 Sentinel 。
    • SENTINEL failover : 当主服务器失效时, 在不询问其他 Sentinel 意见的情况下, 强制开始一次自动故障迁移 (不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置,其他 Sentinel 会根据这个配置进行相应的更新)。
  4. sentinel.conf配置被改变

    每当一个Sentinel启动后,它就会修改并通知其它Sentinel同时修改自身的sentinel.conf文件,例如:

    生成一个myid

    sentinel myid 0f9bd55b18aa54a5f5efc6fb7b3371da56d48d4a

    文件最后会加上如下:

    
    # Generated by CONFIG REWRITE
    
    sentinel known-sentinel yewu01 192.168.0.1 26379 58a141a0f97669925bcc84e3a3b3dbc8602dea99
    sentinel known-sentinel yewu01 192.168.0.2 26379 a0fbf10df21374f8b5cac1f410d9df3b26618575
    sentinel current-epoch 0

3. failover - 故障转移

  1. 执行pkill redis-sever关掉Master观察Sentinel日志如下:

    这是一个被选为failover执行者的sentinel的日志,英文挺清晰明了的就不翻译了:

    6480:X 14 Feb 19:46:54.746 # +sdown master yewu01 10.173.244.98 6379
    6480:X 14 Feb 19:46:54.798 # +odown master yewu01 10.173.244.98 6379 #quorum 3/2
    6480:X 14 Feb 19:46:54.798 # +new-epoch 1
    6480:X 14 Feb 19:46:54.798 # +try-failover master yewu01 10.173.244.98 6379
    6480:X 14 Feb 19:46:54.807 # +vote-for-leader 214bd3df8363327488cd8c430166cf48cd2ab33a 1
    6480:X 14 Feb 19:46:54.819 # f7462491e6881da2c1efbfd6465ece6380c653cf voted for 214bd3df8363327488cd8c430166cf48cd2ab33a 1
    6480:X 14 Feb 19:46:54.823 # 6c95942bbcc39a0703ec5d54a76d6a696a500a17 voted for 214bd3df8363327488cd8c430166cf48cd2ab33a 1
    6480:X 14 Feb 19:46:54.907 # +elected-leader master yewu01 10.173.244.98 6379
    6480:X 14 Feb 19:46:54.907 # +failover-state-select-slave master yewu01 10.173.244.98 6379
    6480:X 14 Feb 19:46:54.974 # +selected-slave slave 10.174.249.145:6379 10.174.249.145 6379 @ yewu01 10.173.244.98 6379
    6480:X 14 Feb 19:46:54.974 * +failover-state-send-slaveof-noone slave 10.174.249.145:6379 10.174.249.145 6379 @ yewu01 10.173.244.98 6379
    6480:X 14 Feb 19:46:55.057 * +failover-state-wait-promotion slave 10.174.249.145:6379 10.174.249.145 6379 @ yewu01 10.173.244.98 6379
    6480:X 14 Feb 19:46:55.534 # +promoted-slave slave 10.174.249.145:6379 10.174.249.145 6379 @ yewu01 10.173.244.98 6379
    6480:X 14 Feb 19:46:55.534 # +failover-state-reconf-slaves master yewu01 10.173.244.98 6379
    6480:X 14 Feb 19:46:55.581 * +slave-reconf-sent slave 10.251.22.210:6379 10.251.22.210 6379 @ yewu01 10.173.244.98 6379
    6480:X 14 Feb 19:46:55.957 # -odown master yewu01 10.173.244.98 6379
    6480:X 14 Feb 19:46:56.041 * +slave-reconf-inprog slave 10.251.22.210:6379 10.251.22.210 6379 @ yewu01 10.173.244.98 6379
    6480:X 14 Feb 19:46:56.042 * +slave-reconf-done slave 10.251.22.210:6379 10.251.22.210 6379 @ yewu01 10.173.244.98 6379
    6480:X 14 Feb 19:46:56.096 # +failover-end master yewu01 10.173.244.98 6379
    6480:X 14 Feb 19:46:56.096 # +switch-master yewu01 10.173.244.98 6379 10.174.249.145 6379
    6480:X 14 Feb 19:46:56.097 * +slave slave 10.251.22.210:6379 10.251.22.210 6379 @ yewu01 10.174.249.145 6379
    6480:X 14 Feb 19:46:56.097 * +slave slave 10.173.244.98:6379 10.173.244.98 6379 @ yewu01 10.174.249.145 6379
    6480:X 14 Feb 19:47:26.148 # +sdown slave 10.173.244.98:6379 10.173.244.98 6379 @ yewu01 10.174.249.145 6379

    这是非failover执行者的Sentinel的日志:

    30052:X 14 Feb 19:46:54.725 # +sdown master yewu01 10.173.244.98 6379
    30052:X 14 Feb 19:46:54.816 # +new-epoch 1
    30052:X 14 Feb 19:46:54.823 # +vote-for-leader 214bd3df8363327488cd8c430166cf48cd2ab33a 1
    30052:X 14 Feb 19:46:55.584 # +config-update-from sentinel 214bd3df8363327488cd8c430166cf48cd2ab33a 10.251.22.210 26379 @ yewu01 10.173.244.98 6379
    30052:X 14 Feb 19:46:55.584 # +switch-master yewu01 10.173.244.98 6379 10.174.249.145 6379
    30052:X 14 Feb 19:46:55.584 * +slave slave 10.251.22.210:6379 10.251.22.210 6379 @ yewu01 10.174.249.145 6379
    30052:X 14 Feb 19:46:55.584 * +slave slave 10.173.244.98:6379 10.173.244.98 6379 @ yewu01 10.174.249.145 6379
    30052:X 14 Feb 19:47:25.602 # +sdown slave 10.173.244.98:6379 10.173.244.98 6379 @ yewu01 10.174.249.145 6379

    日志显示,其中一个Slave被提升为了Master

  2. failover后配置被变更

    Sentinel首先通过命令的方式来做redis-serversentinel的配变更。之后会将配置持久化到redis.confsentinel.conf文件中。

    1. redis.conf
      被选为Master的,其slaveof键值被直接删除;
      仍然还是Slave的,其slaveof值被指定为新Master的地址;

    2. 所有Sentinel的sentinel.conf
      sentinel monitor 被指定为新Master的地址;

      // epoch “时期”(版本的意思)被自增1
      sentinel current-epoch 1

4. Jedis操作

显然,经过故障转移后,主从结构已经发生了改变且主已经死亡,如果还按照之前那样写死IP的方式连接Redis的话,势必会出现错误。可以想到,在Sentinel结构下,你必须向哨兵询问来获取谁是Master

    private static final JedisSentinelPool pool;
    static {
        JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
        jedisPoolConfig.setMaxTotal(10);
        jedisPoolConfig.setMaxIdle(5);
        jedisPoolConfig.setMinIdle(5);

        Set<String> sentinels = new HashSet<>(Arrays.asList(
                "111.111.111.111:26379",
                "111.111.111.112:26379",
                "111.111.111.113:26379"
        ));
        GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig();
        poolConfig.setMaxTotal(10);
        poolConfig.setMaxIdle(5);
        poolConfig.setMinIdle(5);
        pool = new JedisSentinelPool("yewu01", sentinels, jedisPoolConfig);
    }

    public static void main(String[] args) throws Exception {
        String key1 = "key1";
        try (Jedis jedis = pool.getResource()) {
            jedis.set(key1, "222");
            System.out.println(jedis.get(key1));
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

以上。


参考文献:

[ 1 ] https://redis.io/topics/sentinel
[ 2 ] http://www.redis.cn/topics/sentinel.html

阅读更多
换一批

没有更多推荐了,返回首页