Redis主从复制——一主二仆、薪火相传、反客为主和哨兵模式

news/2024/7/10 2:30:06 标签: nginx, 负载均衡, 服务器

文章目录

  • Redis主从复制——常用3招
    • 1. 一主二仆
    • 2. 薪火相传
    • 3. 反客为主
    • 哨兵模式
    • 解决Next failover delay: I will not start a failover before问题

Redis主从复制——常用3招

1. 一主二仆

假设现在我们6379端口的redis服务器是主服务器,6380端口和6381端口的redis服务器为6379服务器的从服务器

主从复制中,如果从机中途宕机后重启,数据是否还会同步?
答:这个要分两种情况来讲:

1、如果我们的连接不是直接在配置文件中写好的,而是启动6380端口和6381端口后使用SLAVEOF 127.0.0.1 6379命令,让他成为6379服务器的从机的话。那么,当他们发生宕机之后,再次启动,他们将作为主机重启,且数据不会自动跟6379进行同步。此时,我们要想让数据同步,需要重新调用命令SLAVEOF 127.0.0.1 6379来让其重新成为6379的从机,如此,数据才会进行同步。

2、如果我们的主从关系,在从机的配置文件中写好了。那么,从机重启后,将会自动作为主机的从机启动,且同步彼此的数据。

主从复制中,如果主机宕机,两台从机 会怎么样?
答:不做任何操作,他们仍然会将6379服务器认作自己的大哥(主机),不过此时当我们在从机使用命令info replication的时候,他会显示主机down掉了。等主机再次复活(重启)后,从机会继续将6379当做大哥(主机)来对待。

2. 薪火相传

之前我们演示的都是一个主机,两个从机的形式,但是,如果现在我们有20个从机,200个从机呢?这个时候,要是我们让所有从机的数据同步都直接跟主机对接,那还得了。

所以,我们就引出了薪火相传这个概念了,就是,假如我们现在有20个从机,那么我们可以让主机跟其中三个直接对接,再让这三个每个跟另外3个对接,以此类推。这么做的好处了,减轻了主机的负担,但是,也有个缺点就是,前面的如果宕机的话,那么后边的将无法跟主机同步数据。

怎么操作呢?
很简单,还是以3个为例,6379作为主服务器,6380作为6379的从服务器,6381作为6380的从服务器。那么,我们只需要配置6381的主服务器的端口号为6380即可。使用命令SLAVEOF 127.0.0.1 6380或者在配置文件redis6381.conf中修改replicaof 127.0.0.1 6380即可。

3. 反客为主

前面我们讲过,如果主机宕机的话,从机不会做任何操作,但是,这明显不是我们想要的,我们会想,群龙不能无首啊,要是因为主服务器宕机,我们就没法继续进行写操作,那不是裂开了吗,所以,我们肯定希望,有没有哪个大能可以顶上,当一下临时的龙头大哥也好。

当Master宕机后,后面的Slave可以立刻升级为Master,且后面的slave不用做任何修改,这就是反客为主

实现也很简单,在主服务器后面的从服务器中执行命令:SLAVEOF NO ONE即可。至于哪一台从服务器,那肯定是越近越好。毕竟越近的服务器后面的小弟越多。
举个例子,帮派的等级制度是 帮主 —— 长老 —— 核心弟子 —— 内门弟子 —— 外门弟子。 现在帮主挂掉了,肯定是让长老顶一下,毕竟他能号令的人多呀。

但是,这种自己揭竿起义就当老大的做法,明显不是我们要的,我们要的是人心所向,老大一走,马上根据长老的权望立刻推最高的上去做老大。也就是主机挂了,我们希望从机能自动上去,而不是我们人为的让他执行SLAVEOF NO ONE命令。毕竟我们不可能派人24小时盯着我们的主服务器有没有宕机。

这,就要讲到我们的哨兵模式了。

哨兵模式

哨兵模式:反客为主的自动版。能够后台监控主机是否故障,如果故障了,根据投票数自动将从机转换为主机。

哨兵模型选择从服务器的条件优先顺序依次为:
1、优先级靠前的(redis.conf中replica-priority 的值越小,优先级越高)
2、偏移量最大的(获得原主机数据最全的)
3、runid最小的(每个redis实例启动后都会随机生成一个40位的runid)

下面,我们直接演示怎么用:
首先,打开我们的三个服务器(6379,6380,6381)。为了直观,我们这次让6380和6381作为6379的从服务器

然后我们在我们的 /myredis/ 目录下新建一个文件 sentinel.conf (必须是这个名,不能自定义):

sentinel monitor mymaster 127.0.0.1 6379 1

解释一下,这里mymaster是为监控对象起的服务器的名称,1是至少有多少个哨兵同意就可以迁移 的数量。

开启我们的哨兵模型,我们需要用命令:

redis-sentinel sentinel.conf

运行后显示如下:
在这里插入图片描述
此时,我们让6379shutdown,我们可以看到,6380或者6381服务器会自动变更为主机,且当主机再次启动后,他将作为新主机的从机启动。可以通过6380端口执行info replication看到6379变成了6380的slave。
在这里插入图片描述

复制延时:由于所有的写操作都在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器的数量也会使这个问题更加严重。

在Java中配置哨兵模式代码如下:(192.168.123.123 是服务器的ip地址,26379是端口号)

    private static JedisSentinelPool jedisSentinelPool = null;

    public static Jedis getJedisFromSentinel(){
        if(jedisSentinelPool == null){
            Set<String> sentinelSet = new HashSet<>();
            sentinelSet.add("192.168.123.123:26379");
            JedisPoolConfig config = new JedisPoolConfig();
            config.setMaxTotal(10); //最大可用连接数
            config.setMaxIdle(5);   //最大闲置连接数
            config.setMinIdle(5);   //最小闲置连接数
            config.setBlockWhenExhausted(true);
            config.setMaxWaitMillis(2000);  //等待时间
            config.setTestOnBorrow(true);   //取连接的时候进行一下测试ping pone

            jedisSentinelPool = new JedisSentinelPool("mymaster", sentinelSet, config);
        }
        return jedisSentinelPool.getResource();
    }

解决Next failover delay: I will not start a failover before问题

如果主机宕机后,哨兵模式显示Next failover delay: I will not start a failover before,且无法将从机主动切换为主机,那么需要注意两个点。
1、防火墙是否有把从机的端口号开启。开启代码如下:

firewall-cmd --add-port=6380/tcp --permanent
firewall-cmd --add-port=6381/tcp --permanent

#切记要reload才能生效。
firewall-cmd --reload

2、主机是否有设置密码,有的话,需要在sentinel.conf文件中添加这个参数。(mymaster是为监控对象起的服务器的名称,**********是主机的密码)

sentinel auth-pass mymaster *********

http://www.niftyadmin.cn/n/1733342.html

相关文章

Hibernate多对多关联映射的HQL中的in条件查询问题

http://www.blogjava.net/rongxh7/archive/2009/06/21/283479.htmlHibernate多对多关联映射的HQL中的in条件查询问题 群里有朋友求解一个问题&#xff0c;高分求一条HQL多对多查询语句 。 问题描述见 http://topic.csdn.net/u/20090621/16/4eac6fe0-bf3e-422e-a697-f7584732f66…

创建oracle的job

一个简单例子&#xff1a; 创建测试表SQL> create table a(a date);表已创建。创建一个自定义过程SQL> create or replace procedure test as2 begin3 insert into a values(sysdate);4 end;5 /过程已创建。创建JOBSQL> variable job1 number;SQL> SQL> beg…

Redis主从复制超详细好用搭建方案

Redis主从复制最佳搭建方案 为了方便学习&#xff0c;我们将本该搭建在三台不同服务器上的Redis放在一台虚拟机上通过启动三个不同端口号的Redis运行。 这里我们以简单的一主二仆为例&#xff0c;并假设我们所有服务器的密码都是password123。 首先&#xff0c;我们在根目录…

Redis集群超详细教程及其实战(附带各种问题解决)

文章目录Redis集群超详细教程及其实战简介搭建Redis集群实战槽&#xff08;Slot&#xff09;把玩集群故障恢复集群的Jedis开发Redis集群超详细教程及其实战 简介 Redis集群实现了对Redis的水平扩容&#xff0c;即启动N个redis节点&#xff0c;将整个数据库分布存储在这N个节点…

Redis解决缓存穿透问题

文章目录Redis解决缓存穿透问题什么是缓存穿透解决方法Redis解决缓存穿透问题 什么是缓存穿透 请看图&#xff0c;当我们用户访问我们的服务器的时候&#xff0c;服务器一般会先访问我们的redis&#xff0c;查看我们的缓存是否有需要的数据&#xff0c;如果没有我们再去访问数…

Redis解决缓存击穿问题

文章目录Redis解决缓存击穿问题什么是缓存击穿解决方案Redis解决缓存击穿问题 什么是缓存击穿 缓存击穿&#xff1a;数据库的压力瞬时增大&#xff0c;且redis中并无大量的key过期&#xff0c;redis正常运行的情况下&#xff0c;数据库奔溃了。&#xff08;他跟缓存穿透的区别…

Redis解决缓存雪崩问题

文章目录Redis解决缓存雪崩问题什么是缓存雪崩怎么解决Redis解决缓存雪崩问题 什么是缓存雪崩 缓存雪崩&#xff1a;在极少时间内&#xff0c;查询大量key的批量过期&#xff0c;导致不停访问数据库&#xff0c;加大服务器的压力&#xff0c;最终服务器奔溃的情况。&#xff…

Redis解决分布式锁

文章目录Redis解决分布式锁什么是分布式锁上锁的解决方案Redis解决分布式锁上锁实战Redis解决分布式锁 什么是分布式锁 随着业务发展的需要&#xff0c;原先单机部署的系统现在已经演化成了分布式集群系统。即&#xff0c;原先我们用一个服务器就啥也扔进去了&#xff0c;啥也…