Redis详解（八）------ 主从复制

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

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

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

　　

 

一、修改配置文件

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

　　

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

　　①、修改 daemonize yes

　　

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

　　②、配置PID文件路径 pidfile

　　

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

　　③、配置端口 port

　　

　　④、配置log 文件名字

　　

　　⑤、配置rdb文件名

　　

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

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

　　

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

　　

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

redis-cli -p 6379
redis-cli -p 6380
redis-cli -p 6381

二、设置主从关系

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

　　    

　　

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

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

　　    

　　咱们再看 6379 节点信息：

　　

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

slaveof 127.0.0.1 6379

三、测试主从关系

　　①、增量复制

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

　　

　　

　　

　　由上图可知是能够获取的。

　　②、全量复制

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

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

　　③、主从读写分离

　　主节点可以执行写命令，从节点可以执行写命令吗？

　　

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

　　

　　若是咱们将其修改成 no 以后，执行写命令是能够的。

　　

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

　　④、主节点宕机

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

　　

　　

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

　　⑤、主节点宕机后恢复

　　主节点Master挂掉以后，立刻启动主机Maste，主节点扮演的角色仍是 Master 吗？

　　

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

四、哨兵模式

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

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

　　

 

　　哨兵模式搭建步骤：

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

　　　

 sentinel monitor 被监控机器的名字(本身起名字) ip地址 端口号 得票数

　　

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

　　②、启动哨兵

redis-sentinel /etc/redis/sentinel.conf

　　启动界面：

　　

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

　　

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

　　

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

　　

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

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

五、主从复制原理

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

　　①、旧版同步

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

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

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

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

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

　　②、命令传播

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

　　为了让主服务器和从服务器保持状态一致，主服务器须要对从服务器执行命令传播操做，主服务器会将本身的写命令发送给从服务器执行。从服务器执行相应的命令以后，主从服务器状态继续保持一致。

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

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

　　同步操做实际上是一个很是耗时的操做，主服务器须要先经过 BGSAVE 命令来生成一个 RDB 文件，而后须要将该文件发送给从服务器，从服务器接收该文件以后，接着加载该文件，而且加载期间，从服务器是没法处理其余命令的。

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

六、主从复制的缺点

　　主从复制虽然解决了主节点的单点故障问题，可是因为全部的写操做都是在 Master 节点上操做，而后同步到 Slave 节点，那么同步就会有必定的延时，当系统很繁忙的时候，延时问题就会更加严重，并且会随着从节点slave的增多而越发严重。