Redis 详解 (八) 主从复制

- 日理万妓 2021-10-29 12:00 341阅读 0赞

**目录**

*  [1、修改配置文件][1]
 *  [2、设置主从关系][2]
 *  [3、测试主从关系][3]
 *  [4、哨兵模式][4]
 *  [5、主从复制原理][5]
 *  [6、主从复制的缺点][6]

--------------------

前面介绍Redis，我们都在一台服务器上进行操作的，也就是说读和写以及备份操作都是在一台Redis服务器上进行的，那么随着项目访问量的增加，对Redis服务器的操作也越加频繁，虽然Redis读写速度都很快，但是一定程度上也会造成一定的延时，那么为了解决访问量大的问题，通常会采取的一种方式是主从架构Master/Slave，Master 以写为主，Slave 以读为主，Master 主节点更新后根据配置，自动同步到从机Slave 节点。

接下来我们就来介绍如何进行主从架构的搭建。

ps:这里我是在一台机器上模拟多个Redis服务器，与实际生产环境中相比，基本配置都是一样，仅仅是IP地址和端口号变化。

![1120165-20180609091604246-1031058549.png][]

[回到顶部][Link 1]

### 1、修改配置文件 ###

首先将redis.conf 配置文件复制三份，通过修改端口分别模拟三台Redis服务器。

![1120165-20180609085725666-1104732076.png][]

然后我们分别对这三个redis.conf 文件进行修改。

**①、修改 daemonize yes**

![1120165-20180609091855397-2067943530.png][]

表示指定Redis以守护进程的方式启动（后台启动）

**②、配置PID文件路径 pidfile**

![1120165-20180609092154310-1305076236.png][]

表示当redis作为守护进程运行的时候，它会把 pid 默认写到 /var/redis/run/redis\_6379.pid 文件里面

**③、配置端口 port**

![1120165-20180609092445295-1994256190.png][]

**④、配置log 文件名字**

![1120165-20180609092701160-1155649756.png][]

**⑤、配置rdb文件名**

![1120165-20180609092830634-1425851330.png][]

依次将 6380redis.conf 、6381redis.conf 配置一次，则配置完毕。

接下来我们分别启动这三个服务。

![1120165-20180609093944771-2019394726.png][]

通过命令查看Redis是否启动：

![1120165-20180609094017041-86471770.png][]

接下来通过如下命令分别进入到这三个Redis客户端：

<table> 
 <tbody> 
  <tr> 
   <td> 
    <div>
      1 
    </div> 
    <div>
      2 
    </div> 
    <div>
      3 
    </div> </td> 
   <td> 
    <div> 
     <div> 
      <code>redis-cli -p 6379</code> 
     </div> 
     <div> 
      <code>redis-cli -p 6380</code> 
     </div> 
     <div> 
      <code>redis-cli -p 6381</code> 
     </div> 
    </div> </td> 
  </tr> 
 </tbody> 
</table>

[回到顶部][Link 1]

### 2、设置主从关系 ###

①、通过  info replication 命令查看节点角色

![1120165-20180609101412335-153915154.png][]    ![1120165-20180609101437538-230419038.png][]

![1120165-20180609101524636-615003527.png][]

我们发现这三个节点都是扮演的 Master 角色。那么如何将 6380 和 6381 节点变为 Slave 角色呢？

②、选择6380端口和6381端口，执行命令：SLAVEOF 127.0.0.1 6379

![1120165-20180609101856672-864209230.png][]    ![1120165-20180609101929567-1129365566.png][]

我们再看 6379 节点信息：

![1120165-20180609102748989-1069185503.png][]

这里通过命令来设置主从关系，一旦服务重启，那么角色关系将不复存在。想要永久的保存这种关系，可以通过配置redis.conf 文件来配置。

<table> 
 <tbody> 
  <tr> 
   <td> 
    <div>
      1 
    </div> </td> 
   <td> 
    <div> 
     <div> 
      <code>slaveof 127.0.0.1 6379</code> 
     </div> 
    </div> </td> 
  </tr> 
 </tbody> 
</table>

[回到顶部][Link 1]

### 3、测试主从关系 ###

**①、增量复制**

主节点执行 set k1 v1 命令，从节点 get k1 能获取吗？

![1120165-20180609103015550-1540768100.png][]

![1120165-20180609103025375-1770149870.png][]

![1120165-20180609103035826-1776357162.png][]

由上图可知是可以获取的。

**②、全量复制**

通过执行 SLAVEOF 127.0.0.1 6379，如果主节点 6379 以前还存在一些 key，那么执行命令之后，从节点会将以前的信息也都复制过来吗？

答案也是肯定的，这里我就不贴测试结果了。

**③、主从读写分离**

主节点能够执行写命令，从节点能够执行写命令吗？

![1120165-20180609103401928-2080123469.png][]

这里的原因是在配置文件 6381redis.conf 中对于 slave-read-only 的配置

![1120165-20180609103517626-624965587.png][]

如果我们将其修改为 no 之后，执行写命令是可以的。

![1120165-20180609103818134-1183260636.png][]

但是从节点写命令的数据从节点或者主节点都不能获取的。

**④、主节点宕机**

主节点 Maste 挂掉，两个从节点角色会发生变化吗？

![1120165-20180609103955833-743445340.png][]

![1120165-20180609104125503-425233081.png][]

上图可知主节点 Master 挂掉之后，从节点角色还是不会改变的。

**⑤、主节点宕机后恢复**

主节点Master挂掉之后，马上启动主机Maste，主节点扮演的角色还是 Master 吗？

![1120165-20180609104846730-1063167999.png][]

也就是说主节点挂掉之后重启，又恢复了主节点的角色。

[回到顶部][Link 1]

### 4、哨兵模式 ###

通过前面的配置，主节点Master 只有一个，一旦主节点挂掉之后，从节点没法担起主节点的任务，那么整个系统也无法运行。如果主节点挂掉之后，从节点能够自动变成主节点，那么问题就解决了，于是哨兵模式诞生了。

哨兵模式就是不时地监控redis是否按照预期良好地运行（至少是保证主节点是存在的），若一台主机出现问题时，哨兵会自动将该主机下的某一个从机设置为新的主机，并让其他从机和新主机建立主从关系。

![1120165-20180609120427138-1351876841.png][]

哨兵模式搭建步骤：

①、在配置文件目录下新建 sentinel.conf 文件，名字绝不能错，然后配置相应内容

![1120165-20180609114532397-1341362330.png][]

<table> 
 <tbody> 
  <tr> 
   <td> 
    <div>
      1 
    </div> </td> 
   <td> 
    <div> 
     <div> 
      <code>sentinel monitor 被监控机器的名字(自己起名字) ip地址 端口号 得票数</code> 
     </div> 
    </div> </td> 
  </tr> 
 </tbody> 
</table>

![1120165-20180609115554622-767506410.png][]

分别配置被监控的名字，ip地址，端口号，以及得票数。上面的得票数为1表示表示主机挂掉后salve投票看让谁接替成为主机，得票数大于1便成为主机

②、启动哨兵

<table> 
 <tbody> 
  <tr> 
   <td> 
    <div>
      1 
    </div> </td> 
   <td> 
    <div> 
     <div> 
      <code>redis-sentinel /etc/redis/sentinel.conf</code> 
     </div> 
    </div> </td> 
  </tr> 
 </tbody> 
</table>

启动界面：

![1120165-20180609115644617-2138551559.png][]

接下来，我们干掉主机 6379，然后看从节点有啥变化。

![1120165-20180609115951576-1912696729.png][]

干掉主节点之后，我们查看后台打印日志，发现 6381投票变为主节点了。

![1120165-20180609115939823-1544997489.png][]

这时候我们查看从节点 6381的节点信息：

![1120165-20180609120102216-1580070378.png][]

6381 节点自动变为主节点了。

PS：哨兵模式也存在单点故障问题，如果哨兵机器挂了，那么就无法进行监控了，解决办法是哨兵也建立集群，Redis哨兵模式是支持集群的。

[回到顶部][Link 1]

### 5、主从复制原理 ###

Redis的复制功能分为同步（sync）和命令传播（command propagate）两个操作。

**①、旧版同步**

当从节点发出 SLAVEOF 命令，要求从服务器复制主服务器时，从服务器通过向主服务器发送 SYNC 命令来完成。该命令执行步骤：

1、从服务器向主服务器发送 SYNC 命令

2、收到 SYNC 命令的主服务器执行 BGSAVE 命令，在后台生成一个 RDB 文件，并使用一个缓冲区记录从开始执行的所有写命令

3、当主服务器的 BGSAVE 命令执行完毕时，主服务器会将 BGSAVE 命令生成的 RDB 文件发送给从服务器，从服务器接收此 RDB 文件，并将服务器状态更新为RDB文件记录的状态。

4、主服务器将缓冲区的所有写命令也发送给从服务器，从服务器执行相应命令。

**②、命令传播**

当同步操作完成之后，主服务器会进行相应的修改命令，这时候从服务器和主服务器状态就会不一致。

为了让主服务器和从服务器保持状态一致，主服务器需要对从服务器执行命令传播操作，主服务器会将自己的写命令发送给从服务器执行。从服务器执行相应的命令之后，主从服务器状态继续保持一致。

总结：通过同步操作以及命令传播功能，能够很好的保证了主从一致的特性。

但是我们考虑一个问题，如果从服务器在同步主服务器期间，突然断开了连接，而这时候主服务器进行了一些写操作，这时候从服务器恢复连接，如果我们在进行同步，那么就必须将主服务器从新生成一个RDB文件，然后给从服务器加载，这样虽然能够保证一致性，但是其实断开连接之前主从服务器状态是保持一致的，不一致的是从服务器断开连接，而主服务器执行了一些写命令，那么从服务器恢复连接后能不能只要断开连接的哪些写命令，而不是整个RDB快照呢？

同步操作其实是一个非常耗时的操作，主服务器需要先通过 BGSAVE 命令来生成一个 RDB 文件，然后需要将该文件发送给从服务器，从服务器接收该文件之后，接着加载该文件，并且加载期间，从服务器是无法处理其他命令的。

为了解决这个问题，Redis从2.8版本之后，使用了新的同步命令** PSYNC** 来代替 SYNC 命令。该命令的部分重同步功能用于处理断线后重复制的效率问题。也就是说当从服务器在断线后重新连接主服务器时，主服务器只将断开连接后执行的写命令发送给从服务器，从服务器只需要接收并执行这些写命令即可保持主从一致。

[回到顶部][Link 1]

### 6、主从复制的缺点 ###

主从复制虽然解决了主节点的单点故障问题，但是由于所有的写操作都是在 Master 节点上操作，然后同步到 Slave 节点，那么同步就会有一定的延时，当系统很繁忙的时候，延时问题就会更加严重，而且会随着从节点slave的增多而愈加严重。

转载于:https://www.cnblogs.com/hankyoon/p/11354634.html

[1]: https://www.cnblogs.com/ysocean/p/9143118.html#_label0
[2]: https://www.cnblogs.com/ysocean/p/9143118.html#_label1
[3]: https://www.cnblogs.com/ysocean/p/9143118.html#_label2
[4]: https://www.cnblogs.com/ysocean/p/9143118.html#_label3
[5]: https://www.cnblogs.com/ysocean/p/9143118.html#_label4
[6]: https://www.cnblogs.com/ysocean/p/9143118.html#_label5
[1120165-20180609091604246-1031058549.png]: /images/20211029/d26672e21bd148c09da65ba3d119b0bb.png
[Link 1]: https://www.cnblogs.com/ysocean/p/9143118.html#_labelTop
[1120165-20180609085725666-1104732076.png]: /images/20211029/19d7fbf8eee64493bc61480dd6c2ea40.png
[1120165-20180609091855397-2067943530.png]: /images/20211029/68c1c45ae63342be8822a8f8f96691a0.png
[1120165-20180609092154310-1305076236.png]: /images/20211029/e06695588d554935a05e26e7e7c3b566.png
[1120165-20180609092445295-1994256190.png]: /images/20211029/bea02059ec9246b1bad75ea75352d2d6.png
[1120165-20180609092701160-1155649756.png]: /images/20211029/2f791e60c902441bb840a2c6e1805383.png
[1120165-20180609092830634-1425851330.png]: /images/20211029/4b9a6b71f259497293dfbe712e8b854d.png
[1120165-20180609093944771-2019394726.png]: /images/20211029/328fd062516344a58c1daba572d40017.png
[1120165-20180609094017041-86471770.png]: /images/20211029/e59f23c944a14255b11254e43f832b35.png
[1120165-20180609101412335-153915154.png]: https://images2018.cnblogs.com/blog/1120165/201806/1120165-20180609101412335-153915154.png
[1120165-20180609101437538-230419038.png]: /images/20211029/06ff231466e94f10804ef364a8e02a97.png
[1120165-20180609101524636-615003527.png]: /images/20211029/ce8db5057a2e4e4b8b86e2e6d3cbd319.png
[1120165-20180609101856672-864209230.png]: https://images2018.cnblogs.com/blog/1120165/201806/1120165-20180609101856672-864209230.png
[1120165-20180609101929567-1129365566.png]: /images/20211029/1294ae90540844b0b13effde603fb9b6.png
[1120165-20180609102748989-1069185503.png]: /images/20211029/d8b36c0fcab44748879c7e7d2cee0bb8.png
[1120165-20180609103015550-1540768100.png]: /images/20211029/f6bfc04c2451430d85365d405ade9a26.png
[1120165-20180609103025375-1770149870.png]: /images/20211029/d0e9cb98d5dd42a591b581ce7e56f926.png
[1120165-20180609103035826-1776357162.png]: /images/20211029/0b95a932e7f44a52af3ce94ff02232cb.png
[1120165-20180609103401928-2080123469.png]: /images/20211029/a0fa6844ede54e58a4a622dc235e2e0d.png
[1120165-20180609103517626-624965587.png]: /images/20211029/393d028df1cd48deb43a53fb0bc4510d.png
[1120165-20180609103818134-1183260636.png]: /images/20211029/cbeecd8d47fc47d1a9dcf4a6a1bda3bd.png
[1120165-20180609103955833-743445340.png]: /images/20211029/657def6210f3404eb527a8fccee98ca4.png
[1120165-20180609104125503-425233081.png]: /images/20211029/023bb62cd75c4b3480131baf34789ccd.png
[1120165-20180609104846730-1063167999.png]: /images/20211029/8503b40eab894367bc0e23a35ea02b1e.png
[1120165-20180609120427138-1351876841.png]: /images/20211029/a1ef8572281049b1ba5cd55fbc1138f9.png
[1120165-20180609114532397-1341362330.png]: /images/20211029/7bd1682a08cd4cf78960531a413d51c9.png
[1120165-20180609115554622-767506410.png]: /images/20211029/dea906678378482585fd78fd0e086c5f.png
[1120165-20180609115644617-2138551559.png]: /images/20211029/dbbe61c2f17e43ec96957307c9f89ea2.png
[1120165-20180609115951576-1912696729.png]: /images/20211029/a4119ef9f14c4dd4919ffe13e4c981c3.png
[1120165-20180609115939823-1544997489.png]: /images/20211029/8b9a12c8b88c40789a7ec5a02c7a40d0.png
[1120165-20180609120102216-1580070378.png]: /images/20211029/cf77c9499b7a4b5a8bf8356b4b24eb2e.png