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

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 ponejedisSentinelPool = 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 *********