第五章 Redis高可用模式解读笔记

一、Redis复制

1. 主从复制

方式1:

新增redis6380.conf,加入slaveof 192.168.30.156 6379,在6379启动完后再启6380,完成配置;

方式2:redis-server --slaveof 192.168.30.156 6379

1)增加从节点配置文件,设置slave-serve-stale-data yes

slave-serve-stale-data参数设置成yes,主从复制中,从服务器可以响应客户端请求;设置成no,主从复制中,从服务器将阻塞所有请求,有客户端请求时返回“SYNC with master in progress”。

2)查看状态:info replication

192.168.30.156:6380> info replication
# Replication
role:slave
master_host:192.168.30.156
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:1
master_link_down_since_seconds:1573808549
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:4f9015872f6c1e91de4dec4684c3f532de1afce3
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
192.168.30.156:6380>

3)断开主从复制:在slave节点,执行:6380:>slaveof no one

192.168.30.156:6380> info replication
# Replication
role:master
connected_slaves:0
master_replid:6bf7dbe431c4fc1e48054e65c8e6e3349f48fd5d
master_replid2:4f9015872f6c1e91de4dec4684c3f532de1afce3
master_repl_offset:0
second_repl_offset:1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
192.168.30.156:6380>

4)断开后再变成主从复制:

6380:> slaveof 192.168.30.156 6379

5)数据较重要的节点,主从复制时使用密码验证:requirepass

6)从节点建议用只读模式slave-read-only=yes

若从节点修改数据,主从数据不一致。

7)传输延迟:

主从一般部署在不同机器上,复制时存在网络延时问题,redis提供repl-disable-tcp-nodelay参数决定是否关闭TCP_NODELAY,默认为关闭。

参数关闭时:无论大小都会及时发布到从节点,占带宽,适用于主从网络好的场景;

参数启用时:主节点合并所有数据成TCP包节省带宽,默认为40毫秒发一次,取决于内核,主从的同步延迟40毫秒,适用于网络环境复杂或带宽紧张,如跨机房。

2、主从拓扑——支持单层或多层

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

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

 

第五章 Redis高可用模式解读笔记_第1张图片

3)树状主从:一主多从的缺点(主节点推送次数多压力大)可用此方案解决,主节点只推送一次数据到从节点1,再由从节点2推送到11,减轻主节点推送的压力。

 

第五章 Redis高可用模式解读笔记_第2张图片

3、复制原理

执行slave master port后,与主节点连接,同步主节点的数据。

6380:>info replication:查看主从及同步信息

 

第五章 Redis高可用模式解读笔记_第3张图片

4、数据同步

redis 2.8版本以上使用psync命令完成同步,过程分“全量”与“部分”复制。

全量复制:一般用于初次复制场景(第一次建立SLAVE后全量)。

部分复制:网络出现问题,从节占再次连主时,主节点补发缺少的数据,每次数据增加同步。

心跳:主从长连接心跳,主节点默认每10S向从节点发ping命令,repl-ping-slave-period控制发送频率。

二、哨兵机制

1、为什么要讲哨兵机制?

1)我们学习了redis的主从复制,但如果说主节点出现问题不能提供服务,需要人工重新把从节点设为主节点,还要通知我们的应用程序更新了主节点的地址,这种处理方式不是科学的,耗时费事。

2)同时主节点的写能力是单机的,能力能限。

3)而且主节点是单机的,存储能力也有限。

其中 2,3 的问题在后面 redis 集群课会讲,第 1 个问题我们用哨兵机制来解决

2、主从故障如何故障转移(不满足高可用)

  • 主节点(master)故障,从节点 slave-1 端执行 slaveof no one 后变成新主节点
  • 其它的节点成为新主节点的从节点,并从新节点复制数据

3、哨兵机制(sentinel)的高可用

哨兵原理:

当主节点出现故障时,由redis sentinel自动完成故障发现和转移,并通知应用方,实现高可用性。

 第五章 Redis高可用模式解读笔记_第4张图片

其实整个过程只需要一个哨兵节点来完成,首先使用Raft算法(感兴趣的可以查一下,其实就是个选举算法)实现选举机制,选出一个哨兵节点来完成转移和通知哨兵有三个定时监控任务完成对各节点的发现和监控:

任务1

每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图,哨兵配置时只要配置对主节点的监控即可,通过向主节点发送info,获取从节点的信息,并当有新的从节点加入时可以马上感知到。

 

第五章 Redis高可用模式解读笔记_第5张图片

任务2

每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息,同时每个哨兵节点也会订阅该频道,来了解其它哨兵节点的信息及对主节点的判断,其实就是通过消息publish和subscribe来完成的。

 

第五章 Redis高可用模式解读笔记_第6张图片

任务3

每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测,这个也是哨兵用来判断节点是否正常的重要依据。

 

第五章 Redis高可用模式解读笔记_第7张图片

4、主观下线和客观下线:

主观下线:

刚我知道知道哨兵节点每隔1秒对主节点和从节点、其它哨兵节点发送ping做心跳检测,当这些心跳检测时间超过down-after-milliseconds时,哨兵节点则认为该节点错误或下线,这叫主观下线;这可能会存在错误的判断。

 

第五章 Redis高可用模式解读笔记_第8张图片

客观下线:

当主观下线的节点是主节点时,此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断,当超过quorum(法定人数)个数,此时哨兵节点则认为该主节点确实有问题,这样就客观下线了,大部分哨兵节点都同意下线操作,也就说是客观下线。

 

第五章 Redis高可用模式解读笔记_第9张图片

5、领导者哨兵选举流程

1)每个在线的哨兵节点都可以成为领导者,当它确认(比如哨兵 3)主节点下线时,会向其它哨兵发is-master-down-by-addr命令,征求判断并要求将自己设置为领导者,由领导者处理故障转移。

2)当其它哨兵收到此命令时,可以同意或者拒绝它成为领导者。

3)如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时,将成为领导者,如果没有超过,继续选举。

 

第五章 Redis高可用模式解读笔记_第10张图片

6、故障转移机制

6.1、由Sentinel节点定期监控发现主节点是否出现了故障

sentinel会向master发送心跳PING来确认master是否存活,如果master在“一定时间范围”内不回应PONG或者是回复了一个错误消息,那么这个sentinel会主观地(单方面地)认为这个master已经不可用了。

 

第五章 Redis高可用模式解读笔记_第11张图片

6.2、当主节点出现故障

此时3个Sentinel节点共同选举了Sentinel3节点为领导,负责处理主节点的故障转移。

 

6.3、由Sentinel3领导者节点执行故障转移

过程和主从复制一样,但是自动执行。

 

第五章 Redis高可用模式解读笔记_第12张图片

流程:

1)将slave-1脱离原从节点,升级主节点

2)将从节点slave-2指向新的主节点

3)通知客户端master主节点已更换

4)将原主节点oldMaster变成从节点,指向新的主节点

6.4、故障转移后的redis sentinel的拓扑结构图

 

第五章 Redis高可用模式解读笔记_第13张图片

7、哨兵机制-故障转移详细流程

1)过滤掉不健康的(下线或断线),没有回复过哨兵ping响应的从节点。

2)选择slave-priority从节点优先级最高(redis.conf)。

3)选择复制偏移量最大,指复制最完整的从节点。

 

第五章 Redis高可用模式解读笔记_第14张图片

8、如何安装和部署Reids Sentinel?

我们以3个Sentinel节点、2个从节点、1个主节点为例进行安装部署

 

第五章 Redis高可用模式解读笔记_第15张图片

1、前置条件

先搭好一主两从redis的主从复制,和之前复制搭建一样,搭建方式如下:

A主节点6379节点(/usr/local/bin/conf/redis6379.conf

修改requirepass 12345678,注释掉#bind 127.0.0.1

B从节点redis6380.confredis6381.conf

修改 requirepass 12345678,注释掉#bind 127.0.0.1

加上 masterauth 12345678,加上 slaveof 192.168.30.156 6379

注意:当主从起来后,主节点可读写,从节点只可读不可写。

2redis sentinel哨兵机制核心配置(也是3个节点)

/usr/local/redis/sentinel/sentinel_26379.conf

/usr/local/redis/sentinel/sentinel_26380.conf

/usr/local/redis/sentinel/sentinel_26381.conf

将三个文件的端口改成: 26379 26380 26381

然后修改配置:

sentinel monitor mymaster 192.168.30.156 6379 2  //监听主节点6379

sentinel auth-pass mymaster 12345678  //连接主节点时的密码

三个配置除端口外,其它一样。

3、哨兵其它的配置:

1)只要修改每个sentinel.conf的这段配置即可:

sentinel monitor mymaster 192.168.1.10 6379 2

  • 监控主节点的IP地址端口,sentinel监控的master的名字叫做mymaster
  • 2代表,当集群中有2个sentinel认为master死了时,才能真正认为该master已经不可用了。

sentinel auth-pass mymaster 12345678  //sentinel连主节点的密码

sentinel config-epoch mymaster 2  //故障转移时最多可以有2从节点同时对新

2)主节点进行数据同步:

sentinel leader-epoch mymaster 2

sentinel failover-timeout mymasterA 180000 //故障转移超时时间180s

A)如果转移超时失败,下次转移时时间为之前的2倍。

B)从节点变主节点时,从节点执行slaveof no one命令一直失败的话,当时间超过180S 时,则故障转移失败。

C)从节点复制新主节点时间超过180S转移失败。

sentinel down-after-milliseconds mymasterA 300000  //sentinel节点定期向主节点

ping命令,当超过了300S时间后没有回复,可能就认定为此主节点出现故障了……

sentinel parallel-syncs mymasterA 1 //故障转移后,1代表每个从节点按顺序排队一个一个复制主节点数据,如果为3,指3个从节点同时并发复制主节点数据,不会影响阻塞,但存在网络和IO开销。

4、启动sentinel服务:

./redis-sentinel sentinel/sentinel_26379.conf &

./redis-sentinel sentinel/sentinel_26380.conf &

./redis-sentinel sentinel/sentinel_26381.conf &

关闭:

./redis-cli -h 192.168.30.156 -p 26379 shutdown

5、测试

1)当前master节点信息:

192.168.30.156:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.30.156,port=6380,state=online,offset=27042,lag=0
slave1:ip=192.168.30.156,port=6381,state=online,offset=26897,lag=1
master_replid:e9e1e52efe01231a12e54a637991c811cf94a46d
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:27042
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:27042
192.168.30.156:6379>

2)kill -9 6379杀掉6379redis服务

 

第五章 Redis高可用模式解读笔记_第16张图片

第五章 Redis高可用模式解读笔记_第17张图片

 

看日志是分配6380还是6381做为主节点,当6379服务再启动时,已变成从节点。

192.168.30.156:6379> info replication
# Replication
role:slave
master_host:192.168.30.156
master_port:6381

3)假设6381升级为主节点:

进入6381>info replication可以看到 role:master

 

第五章 Redis高可用模式解读笔记_第18张图片

4)打开sentinel_26379.conf等三个配置

sentinel monitor mymaster 192.168.30.156 6381 2
sentinel known-slave mymaster 192.168.30.156 6379
sentinel known-slave mymaster 192.168.30.156 6380
sentinel known-sentinel mymaster 192.168.30.156 26380 9f362e06d93bce599a66d46a2e8ccc31478371e8
sentinel known-sentinel mymaster 192.168.30.156 26381 01744cc11a00f8eed23cce518daad1451e34b09f
[root@localhost sentinel]#

5)打开redis6379.conf等三个配置,slaveof 192.168.30.156 6381,也变成了6381

 

第五章 Redis高可用模式解读笔记_第19张图片

注意:生产环境建议让redis Sentinel部署到不同的物理机上。

重要sentinel monitor mymaster 192.168.30.156 6379 2  //切记将IP不要写成127.0.0.1

不然使用JedisSentinelPool取jedis连接的时候会变成取127.0.0.1 6379的错误地址。

备注:

我们稍后要启动四个redis实例,其中端口为6379的redis设为master,其他两个设为slave。所以mymaster后跟的是master的ip和端口,最后一个2’代表只要有2个sentinel认为master下线,就认为该master客观下线,选举产生新的master。

通常最后一个参数不能多于启动的sentinel实例数,哨兵sentinel个数为奇数,选举嘛,奇数哨兵个才能选举成功,一般建议3个。

6RedisSentinel如何监控2redis主节点呢?

 

第五章 Redis高可用模式解读笔记_第20张图片

sentinel monitor mymasterB 192.168.1.20 6379 2  //与上面一样

7部署建议 

1)sentinel节点应部署在多台物理机(线上环境)。

2)至少三个且奇数个sentinel节点。

3)通过以上我们知道,3个sentinel可同时监控一个主节点或多个主节点,监听N个主节点较多时,如果sentinel出现异常,会对多个主节点有影响,同时还会造成sentinel节点产生过多的网络连接,一般线上建议还是3个sentinel监听一个主节点。

8sentinel哨兵的API

命令:redis-cli -p 26379 //进入哨兵的命令模式,使用redis-cli进入:

1)查看redis主节点相关信息:26379>sentinel masters或sentinel master mymaster

[root@localhost redis]# ./redis-cli -p 26379
127.0.0.1:26379> sentinel masters
1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "192.168.30.156"
    5) "port"
    6) "6381"

2)查看从节点状态与相关信息:26379>sentinel slaves mymaster

127.0.0.1:26379> sentinel slaves mymaster
1)  1) "name"
    2) "192.168.30.156:6379"
    3) "ip"
    4) "192.168.30.156"
    5) "port"
    6) "6379"
    7) "runid"
    8) "8c10c18a1aaeb838d1a70df6de59b19eba44d551"
    9) "flags"
   10) "slave"
2)  1) "name"
    2) "192.168.30.156:6380"
    3) "ip"
    4) "192.168.30.156"
    5) "port"
    6) "6380"
    7) "runid"
    8) "d075241b9706a2fd0bbdd9f555f058b8844712b1"
    9) "flags"
   10) "slave"

3)查看sentinel节点集合信息(不包括当前26379)

26379>sentinel sentinels mymaster

4) 对主节点强制故障转移,没和其它节点协商:

26379>sentinel failover mymaster 

9、客户端连接(redis-sentinel例子工程)

远程客户端连接时,要打开protected-mode no

指令:./redis-cli -p 26380 shutdown //关闭

在使用工程 redis-sentinel,调用 jedis 查询的流程如下:

1)将三个sentinel的IP和地址加入JedisSentinelPool

2)根据IP和地址创建JedisSentinelPool池对象

3)在这个对象创建完后,此时该对象已把redis的主节点(此时sentinel monitor mymaster必须写成192.168.30.156 6379 2,不能为127.0.0.1,不然查询出来的主节点的IP在客户端就变成了127.0.0.1,拿不到连接了)。查询出来了,当客户准备发起查询请求时,调用pool.getResource()借用一个jedis对象,内容包括主节点的IP和端口。

4)将得到jedis对象后,可执行jedis.get(“age”)指令了。

9、Redis哨兵代码示例

代码见:https://gitee.com/hankin_chj/redis-platform.git(redis-sentinel模块)

1)maven依赖:


    redis.clients
    jedis
    2.9.0


    org.springframework.data
    spring-data-redis
    1.8.3.RELEASE


    org.apache.commons
    commons-lang3
    3.5



    junit
    junit
    4.12
    test


    org.springframework
    spring-test
    4.3.2.RELEASE
    test

2)application.xml配置:

 
<context:component-scan base-package="com." />
<context:property-placeholder location="classpath:redis.properties" />  
<bean id="poolConfig" class="redis.clients.jedis.JedisPoolConfig">  
    <property name="maxTotal" value="${im.hs.server.redis.maxTotal}" />  
    <property name="minIdle" value="${im.hs.server.redis.minIdle}" />  
    <property name="maxWaitMillis" value="${im.hs.server.redis.maxWaitTime}" />  
    <property name="maxIdle" value="${im.hs.server.redis.maxIdle}" />  
    <property name="testOnBorrow" value="${im.hs.server.redis.testOnBorrow}" />  
    <property name="testOnReturn" value="true" />  
    <property name="testWhileIdle" value="true" />  
bean>  
<bean id="sentinelConfiguration"  
    class="org.springframework.data.redis.connection.RedisSentinelConfiguration">  
    <property name="master">  
        <bean class="org.springframework.data.redis.connection.RedisNode">  
            <property name="name" value="${im.hs.server.redis.sentinel.masterName}">property>  
        bean>  
    property>  
    <property name="sentinels">  
        <set> 
            <bean class="org.springframework.data.redis.connection.RedisNode">  
                <constructor-arg name="host" value="${im.hs.server.redis.sentinel1.host}">constructor-arg>
                <constructor-arg name="port" value="${im.hs.server.redis.sentinel1.port}">constructor-arg>
            bean>  
            <bean class="org.springframework.data.redis.connection.RedisNode">  
                <constructor-arg name="host" value="${im.hs.server.redis.sentinel2.host}">constructor-arg>
                <constructor-arg name="port" value="${im.hs.server.redis.sentinel2.port}">constructor-arg>
            bean>  
            <bean class="org.springframework.data.redis.connection.RedisNode">  
                <constructor-arg name="host" value="${im.hs.server.redis.sentinel3.host}">constructor-arg>
                <constructor-arg name="port" value="${im.hs.server.redis.sentinel3.port}">constructor-arg>
            bean>  
        set>  
    property>  
bean>  
<bean id="connectionFactory" class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory"
      p:password="${im.hs.server.redis.sentinel.password}">
    <constructor-arg name="sentinelConfig" ref="sentinelConfiguration">constructor-arg>  
    <constructor-arg name="poolConfig" ref="poolConfig">constructor-arg>  
bean>  
<bean id="redisTemplate" class="org.springframework.data.redis.core.StringRedisTemplate">  
    <property name="connectionFactory" ref="connectionFactory" />  
bean>  

3)RedisTemplate工具类代码:

@Component
public class SentinelTemplateUtil {
   // spring 对redis操作的封装,使用了模板模式
   @Resource
    private RedisTemplate redisTemplate;
    private Logger logger = LoggerFactory.getLogger("SentinelTemplateUtil");
    public void set(final String key, final String value) {
       redisTemplate.execute(new RedisCallback() {  
           @Override  
           public Object doInRedis(RedisConnection connection) throws DataAccessException {
               connection.set(redisTemplate.getStringSerializer().serialize(key),
                       redisTemplate.getStringSerializer().serialize(value));  
               logger.debug("save key:" + key + ",value:" + value);  
               return null;  
           }  
       });  
   }
   public String get(final String key) {  
      @SuppressWarnings("rawtypes")
      BoundValueOperations bvo = redisTemplate.boundValueOps(key);
      return bvo.get().toString();
     
   }
   public void delete(final String key) {  
       redisTemplate.execute(new RedisCallback() {  
           public Object doInRedis(RedisConnection connection) {  
               connection.del(redisTemplate.getStringSerializer().serialize(key));
               return null;  
           }  
       });  
   }
} 
  

4)测试代码

通过jedis工具类访问:

RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("classpath:applicationContext.xml")
public class SentinelTest {
   @Resource
   private SentinelTemplateUtil service;
   @Test
   public void testSet() throws InterruptedException{
       service.set("hankin", "hankin test");
        String str = service.get("hankin");
        System.out.println("====="    +str);
   }  
   @Test
   public void testGet() throws InterruptedException{
      System.out.println("============="+service.get("age1"));
   }
}

直接访问哨兵JedisSentinel测试:

public class JedisSentinel {
   @Test
   public void testJedis() throws InterruptedException {
      Set sentinels = new HashSet();
      String hostAndPort1 = "192.168.30.156:26379";
      String hostAndPort2 = "192.168.30.156:26380";
      String hostAndPort3 = "192.168.30.156:26381";
      sentinels.add(hostAndPort1);
      sentinels.add(hostAndPort2);
      sentinels.add(hostAndPort3);
      String clusterName = "mymaster";
      String password = "12345678";
      JedisSentinelPool redisSentinelJedisPool = new JedisSentinelPool(clusterName, sentinels, password);
      Jedis jedis = null;
      try {
         jedis = redisSentinelJedisPool.getResource();
         jedis.set("name", "hankin007");
         System.out.println(jedis.get("name"));
      } catch (Exception e) {
         e.printStackTrace();
      } finally {
         redisSentinelJedisPool.returnBrokenResource(jedis);
      }
      redisSentinelJedisPool.close();
   }
}

 

你可能感兴趣的:(Redis进阶,Redis高可用模式解读)