Redis集群配置之一主多从

在上一节中，我们实践了《Redis单机安装及环境搭建》,对Redis有了基本的认知，但是在实际开发中，更多地是使用主从复制的方式，甚至是集群的方式，所以很有必要对这两种方式分别地进行讲解和学习。

一、为什么要使用主从复制

读写分离；主机主要负责写，同时支持读；从机主要负责读，不可写；从而降低主机的读取压力。当读取操作爆发式增长时，可以很方便地横向扩展，均摊读取压力。但是不能分摊写入的压力。
容灾恢复；任意一台机器都存有全量的数据，方便快速切换主从服务器，快速恢复服务。

二、如何配置主从结构

我们假设需要一个一主双从的结构，因为三个redis都将运行在同一台机器上，所以需要对redis.conf做如下的修改，如果你是分别运行在三台不同的服务器上，那么就不要这个步骤。

主服务器redis-6379.conf

修改配置文件中的如下内容：
```
pidfile /var/run/redis-6379.pid
port 6379
dbfilename dump-6379.rdb
appendonly no
```
然后以该配置文件启动一个redis-server，监听端口6379；
从服务器redis-6380.conf

修改配置文件中的如下内容：
```
pidfile /var/run/redis-6380.pid
port 6380
dbfilename dump-6380.rdb
appendonly no
```
然后以该配置文件启动一个redis-server，监听端口6380；
从服务器redis-6381.conf

修改配置文件中的如下内容：
```
pidfile /var/run/redis-6381.pid
port 6381
dbfilename dump-6381.rdb
appendonly no
```
然后以该配置文件启动一个redis-server，监听端口6381；

如上启动三个redis服务后，我们可以使用命令ps -ef | grep redis来查看是否全部启动成功。此时它们相互之间是没有主从关系的，我们可以通过命令info replication来查看各自的主从关系信息。

为了实现主从关系，我们需要在配置文件中进行指定。

修改从服务器redis-6380.conf
```
replicaof 127.0.0.1 6379
```
然后以该配置文件重启redis-server，监听端口6380；
修改从服务器redis-6381.conf
```
replicaof 127.0.0.1 6379
```
然后以该配置文件重启redis-server，监听端口6381；

此时，我们分别为三个redis-server建立redis-cli：

redis-cli -h 127.0.0.1 -p 6379
redis-cli -h 127.0.0.1 -p 6380
redis-cli -h 127.0.0.1 -p 6381

再次输入命令info replication查看各自的主从关系信息。发现一主二从的关系已经配置成功了。

如下是在主节点上显示的集群信息：

# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=5448,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=5315,lag=1
master_replid:66c7a61108a110e0a4276cc50aa81f61b26fe294
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:5448
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:5448

此时为了验证主从关系数据的同步是否正常，我们可以在6379的命令行中set k1 v1，然后分别在6380和6381两个命令行中get k1，发现都可以正常获取到值，说明主从结构的集群已经搭建成功了。

其它情况的说明：

主从服务器不管何时，都持有全量的数据备份。比如从服务器在某一时间段内宕机了，此时主服务器连续写入多个数据后，从服务器再次恢复上线，此时从服务器也会获得它不在线时所有写入的数据，不用担心主从之间数据不一致的问题。
主服务器一般提供写服务，也可以读；从服务器只能读，不能写；
主服务器宕机后，从服务器会原地待命，等待主服务器的恢复；
薪火相传模式下，一个从节点A可以作为另一个从节点B的主节点，即在B节点中配置replicaof A，在主节点不宕机的情况下，和上面一主二从没有区别；但是当主节点宕机后，我们可以通过设置A节点replicaof no one，来快速地使得A变为一个主节点，如此能接受写入操作，具有很好的容灾特性，但是缺点是，一旦A节点宕机，B节点不是主节点的从节点，无法同步主节点的写入数据，必须等到A节点恢复。

三、哨兵模式的使用

在如上一主二从的集群中，我们必须手动来切换主服务器，比较麻烦，不够智能。所以哨兵模式为我们提供了当主节点宕机后，自动切换从节点为主节点的方案。

其大致原理就是我们单独再启动n个哨兵，这n个哨兵都监控主节点的运行，当主节点宕机后，n个哨兵中的m个都认为主节点不可用了，那么就会重新选举一个从节点为新的主节点，当后续原来的主节点再恢复后，它也只能作为新的主节点的从节点了。

在我们当前的例子中，我们设置n为1，m也为1。怎么设置的呢？

我们新建一个哨兵配置文件sentinel.conf：

sentinel monitor mymaster 127.0.0.1 6379 1

意思是，哨兵监控名称为mymaster的主节点，其中mymaster为名称可以随意取名，最后的1表示当有1个哨兵投票表示主节点不可用的时候，就启动重新选举主节点的机制。

然后，我们以这个哨兵配置文件启动哨兵进行监控：

redis-sentinel /path/sentinel.conf

启动后，我们可以看到打印了如下语句：

4699:X 10 May 2020 00:15:59.356 # Sentinel ID is 41ccc8bc94a40f457e67c250f55c1656aae89080
4699:X 10 May 2020 00:15:59.356 # +monitor master mymaster 127.0.0.1 6379 quorum 2
4699:X 10 May 2020 00:15:59.364 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
4699:X 10 May 2020 00:15:59.366 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379

说明哨兵已经在监控我们的一主二从集群的情况了。

现在我们将主节点故意宕机试试，然后，过了一会，就会发现哨兵的打印信息如下：

4986:X 10 May 2020 00:28:37.218 # +sdown master mymaster 127.0.0.1 6379
4986:X 10 May 2020 00:28:37.218 # +odown master mymaster 127.0.0.1 6379 #quorum 1/1
4986:X 10 May 2020 00:28:37.218 # +new-epoch 1
4986:X 10 May 2020 00:28:37.218 # +try-failover master mymaster 127.0.0.1 6379
4986:X 10 May 2020 00:28:37.220 # +vote-for-leader 470162e3fa2422964bd50e04f374b8f689dc7b2f 1
4986:X 10 May 2020 00:28:37.220 # +elected-leader master mymaster 127.0.0.1 6379
4986:X 10 May 2020 00:28:37.220 # +failover-state-select-slave master mymaster 127.0.0.1 6379
4986:X 10 May 2020 00:28:37.273 # +selected-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
4986:X 10 May 2020 00:28:37.273 * +failover-state-send-slaveof-noone slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
4986:X 10 May 2020 00:28:37.358 * +failover-state-wait-promotion slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
4986:X 10 May 2020 00:28:38.012 # +promoted-slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379
4986:X 10 May 2020 00:28:38.012 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379
4986:X 10 May 2020 00:28:38.100 * +slave-reconf-sent slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
4986:X 10 May 2020 00:28:39.048 * +slave-reconf-inprog slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
4986:X 10 May 2020 00:28:39.048 * +slave-reconf-done slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379
4986:X 10 May 2020 00:28:39.156 # +failover-end master mymaster 127.0.0.1 6379
4986:X 10 May 2020 00:28:39.156 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6381
4986:X 10 May 2020 00:28:39.156 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6381
4986:X 10 May 2020 00:28:39.156 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381
4986:X 10 May 2020 00:29:09.157 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381

大致的过程就是，哨兵发现主节点6379宕机了，然后进行投票启动了重新选举主节点的机制，然后选出了原来的从节点6381作为新的主节点，并且设置6379和6380为新的主节点6381的从节点。

此时我们可以在6381上使用命令info replication确认其主节点的角色。

然后，我们再次恢复6379的运行，发现，一段时间后，它自动变成了6379的从节点。哨兵输出的信息如下：

4986:X 10 May 2020 00:33:50.668 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381

此时我们如果查看三台机器的配置文件的话，会发现其中的replicaof内容都已经被哨兵进行了更新。

虽然我们的哨兵起到了自动切换主节点的作用，但是它是怎么选出新的主节点的呢？我们是否能够指定某个从节点被优先选举为从节点？

条件一：选择配置文件中replica-priority比较小的，默认值都是100，值越小优先级越高，否则看条件二；
条件二：选择偏移量最大的，即获取主节点同步数据最多的，否则看条件三；
条件三：选择redis实例runid最小的，这个不可能都一样；