6.redis sentinel实现高可用读写分离

1. redis sentinel

故障转移的基本原理:

  • 多个sentinel发现并确认master有问题
  • 选举出一个sentinel作为领导
  • 选出一个slave称为新的master的slave
  • 通知其他的slave称为新的master的slave
  • 通知客户端主从变化
  • 等待老的master复活称为新的master的slave

也支持多个master-slave结构:

2. 安装与配置

  1. 配置开启主从节点
  2. 配置开启sentinel监控主节点(sentinel是特殊的redis)
  3. 实际应该多台机器,但是演示方便,只用一台机器来搭建
  4. 详细配置节点

本地安装的结构图:

对于master:redis-7000.conf配置:

port 7000
daemonize yes
pidfile /usr/local/redis/data/redis-7000.pid
logfile "7000.log"
dir "/usr/local/redis/data"

对于slave:redis-7001和redis-7002配置:

port 7001
daemonize yes
pidfile /usr/local/redis/data/redis-7001.pid
logfile "7001.log"
dir "/usr/local/redis/data"
slaveof 127.0.0.1 7000

启动redis服务:

redis-server ../config/redis-7000.conf

访问7000端口的master redis:

redis-cli -p 7000 info replication

显示他有两个从节点:

# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=7002,state=online,offset=99550,lag=1
slave1:ip=127.0.0.1,port=7001,state=online,offset=99816,lag=0
master_repl_offset:99816
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:99815

对于sentinel主要配置:

master sentinel config:

port 26379
daemonize yes
dir "/usr/local/redis/data"
logfile "26379.log"
sentinel monitor mymaster 127.0.0.1 7000 2
...

启动redis sentinel:

redis-sentinel ../config/redis-sentinel-26379.conf

访问26379 redis sentinel master:

redis-cli -p 26379 info sentinel

显示:

# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=127.0.0.1:7000,slaves=2,sentinels=3
查看这六个进程是否都起来了:ps -ef | grep redis

注意,如果上面是配置在虚拟机的话,需要将127.0.0.1改为虚拟机的ip,要不然找不着。

3. 故障转移演练

3.1 java客户端程序

JedisSentinelPool只是一个配置中心,不需要具体连接某个redis,注意它不是代理。

private Logger logger = LoggerFactory.getLogger(AppTest.class);

@Test
public void test4(){
    //哨兵配置,我们访问redis,就通过sentinel来访问
    String masername = "mymaster";
    Set sentinels = new HashSet<>();
    sentinels.add("10.128.24.176:26379");
    sentinels.add("10.128.24.176:26380");
    sentinels.add("10.128.24.176:26381");

    JedisSentinelPool sentinelPool = new JedisSentinelPool(masername,sentinels);

    //一个while死循环,每隔一秒往master塞入一个值,并且日志打印
    while (true){
        Jedis jedis = null;
        try{
            jedis = sentinelPool.getResource();

            int index = new Random().nextInt(100000);
            String key = "k-" + index;
            String value = "v-" + index;
            jedis.set(key,value);
            logger.info("{}  value is {}",key,jedis.get(key));

            TimeUnit.MILLISECONDS.sleep(1000);
        }catch (Exception e){
            logger.error(e.getMessage(),e);
        }finally {
            if(jedis != null){
                jedis.close();
            }
        }
    }
}

maven依赖是:


<dependency>
  <groupId>redis.clientsgroupId>
  <artifactId>jedisartifactId>
  <version>2.9.0version>
dependency>

<dependency>
  <groupId>org.slf4jgroupId>
  <artifactId>slf4j-apiartifactId>
  <version>1.7.6version>
dependency>

<dependency>
  <groupId>ch.qos.logbackgroupId>
  <artifactId>logback-classicartifactId>
  <version>1.1.1version>
dependency>

启动程序,发现是正常写入:

16:16:01.424 [main] INFO  com.njupt.swg.AppTest - k-54795  value is v-54795
16:16:02.426 [main] INFO  com.njupt.swg.AppTest - k-55630  value is v-55630
16:16:03.429 [main] INFO  com.njupt.swg.AppTest - k-70642  value is v-70642
16:16:04.430 [main] INFO  com.njupt.swg.AppTest - k-42978  value is v-42978
16:16:05.431 [main] INFO  com.njupt.swg.AppTest - k-96297  value is v-96297
16:16:06.433 [main] INFO  com.njupt.swg.AppTest - k-4220  value is v-4220
16:16:07.435 [main] INFO  com.njupt.swg.AppTest - k-34103  value is v-34103
16:16:08.436 [main] INFO  com.njupt.swg.AppTest - k-9177  value is v-9177
16:16:09.437 [main] INFO  com.njupt.swg.AppTest - k-24389  value is v-24389
16:16:10.439 [main] INFO  com.njupt.swg.AppTest - k-32325  value is v-32325
16:16:11.440 [main] INFO  com.njupt.swg.AppTest - k-68538  value is v-68538
16:16:12.441 [main] INFO  com.njupt.swg.AppTest - k-36233  value is v-36233
16:16:13.443 [main] INFO  com.njupt.swg.AppTest - k-305  value is v-305
16:16:14.444 [main] INFO  com.njupt.swg.AppTest - k-59279  value is v-59279

我们将现在的端口为7000的redis master 给kill掉

kill -9 master的pid

我们会发现:客户端报异常,但是在大概十几秒之后,就继续正常塞值了。原因是服务端的哨兵机制的选举matser需要一定的时间。

4. 三个定时任务

4.1 每10秒每个sentinel对master和slave执行Info

  • 发现slave节点
  • 确认主从关系

4.2 每2秒每个sentinel通过master节点的channel交换信息(pub/sub)

  • 通过sentinel:hello进行频道交互
  • 交互对节点的“看法”和自身信息

4.3 每1秒每个sentinel对其他sentinel和redis执行ping

  • 心跳监测,失败判定依据

5. 主观下线和客观下线

对于之前的Sentinel配置文件中有两条配置:

监控master redis节点,这里是当超过两个sentinel认为master挂了,则认为master挂了。

sentinel monitor
sentinel monitor mymaster 127.0.0.1 6379 2

这里是每秒sentinel都回去Ping周围的master redis,超过30秒没有任何相应,说明其挂了。

sentinel down-after-milliseconds
sentinel down-after-milliseconds mymaster 300000

5.1 主观下线

主观下线:每个sentinel节点对Redis节点失败的“偏见”

这是一种主观下线。因为在复杂的网络环境下,这个sentinel与这个master不通,但是master与其他的sentinel都是通的呢?所以是一种“偏见”

这是依靠的第三种定时:每秒去ping一下周围的sentinel和redis。对于slave redis,可以使用这个主观下线,因为他不需要进行故障转移。

5.2 客观下线

客观下线:所有sentinel节点对master Redis节点失败“达成共识”(超过quorum个则统一)

这是依靠的第二种定时:每两秒,sentinel之间进行“商量”,传递的消息是:sentinel is-master-down-by-addr

对于master redis的下线,必须要达成共识才可以,因为涉及故障转移,仅仅依靠一个sentinel判断是不够的。

6. 领导者选举

原因:只有一个sentinel节点完成故障转移

选举:通过sentinel is-master-down-by-addr命令都希望成为领导者

  • 每个做主观下线的sentinel节点向其他sentinel节点发送命令,要求将它设置为领导者
  • 收到命令的sentinel节点如果没有同意通过其他semtinel节点发送的命令,那么将同意该请求,否则拒绝
  • 如果该sentinel节点发现自己的票数已经超过sentinel集合半数并且超过quorum,那么它将成为领导者。
  • 如果此过程中多个sentinel节点成为了领导者,那么将等待一段时间重新进行选举

7. 故障转移

  • 从slave节点中选出一个“合适的”节点作为新的master节点
  • 对上述的slave节点执行“slaveof no one”命令使其成为master节点
  • 向剩余的slave节点发送命令,让它们成为新master节点的slave节点,复制规则和parallel-syncs参数一样
  • 更新对原来的master节点配置为slave,并保持着对其“关注”,当恢复后命令他去复制新的master节点

那么,如何选择“合适”的slave节点呢?

  • 选择slave-priority(slave节点优先级)最高的slave节点,如果存在则返回,不存在则继续。
  • 选择复制偏移量对打的slave节点(复制得最完整),如果存在则返回,不存在则继续
  • 选择run_id最小的slave节点(最早的节点)

8. 节点下线

主节点下线:sentinel failover

从节点下线要注意读写分离问题。

9. 总结与思考

redis sentinel是redis高可用实现方案:故障发现、故障自动转移、配置中心、客户端通知。

redis sentinel从redis2.8版本才正式生产可用,之前版本不可生产用。

尽可能在不同物理机上部署redis sentinel所有节点。

redis sentinel中的sentinel节点个数应该大于等于3且最好是奇数。

redis sentinel中的数据节点和普通数据节点没有区别。每个sentinel节点在本质上还是一个redis实例,只不过和redis数据节点不同的是,其主要作用是监控redis数据节点

客户端初始化时连接的是sentinel节点集合,不再是具体的redis节点,但sentinel只是配置中心不是代理。

redis sentinel通过三个定时任务实现了sentinel节点对于主节点、从节点、其余sentinel节点的监控。

redis sentinel在对节点做失败判定时分为主观下线和客观下线。

看懂redis sentinel故障转移日志对于redis sentinel以及问题排查非常有用。

redis sentinel实现读写分离高可用可以依赖sentinel节点的消息通知,获取redis数据节点的状态变化。

redis sentinel可以实现高可用的读写分离,高可用体现在故障转移,那么实现高可用的基础就是要有从节点,主从节点还实现了读写分离,减少master的压力。但是如果是从节点下线了,sentinel是不会对其进行故障转移的,并且连接从节点的客户端也无法获取到新的可用从节点,而这些问题在Cluster中都得到了有效的解决。

对于性能提高、容量扩展的时候,这种方式是比较复杂的,比较推荐的是使用集群,就是下面讨论的redis cluster!

你可能感兴趣的:(redis系统学习,redis系统学习)