vlambda博客
学习文章列表

走进redis 主从复制

上一篇文章讲述了Redis 持久化机制，，这是保证了Redis中出现故障后，可以保证数据不丢失；这篇我们一起看看Redis的主从复制，也是我们平时接触到最后的一种模式。

Redis 主从复制

主从复制模式算是我们平时接触比较多的模式了，比如数据库，很多都是一台主库，两台备库

Redis主从复制：主机数据更新后根据配置和策略，自动同步到备机的master/slave机制，master以写为主，slave以读为主；

结构图：

Redis 主从复制过程：

1：当一个从数据库启动时，会向主数据库发送sync命令，

2：主数据库接收到sync命令后会开始在后台保存快照（执行rdb操作），并将保存期间接收到的命令缓存起来

3：当快照完成后，redis会将快照文件和所有缓存的命令发送给从数据库。

4：从数据库收到后，会载入快照文件并执行收到的缓存的命令。

主从复制优点

• 数据冗余，实现数据的热备份
• 故障恢复，避免单点故障带来的服务不可用
• 读写分离，负载均衡。主节点负载读写，从节点负责读，提高服务器并发量
• 高可用基础，是哨兵机制和集群实现的基础

主从复制部署

主从复制的部署，基本完全是在从节点发起的，主节点不需要任何配置；

从节点配置方式：

（1）配置文件

在从服务器的配置文件中加入：slaveof

（2）启动命令

redis-server启动命令后加入 --slaveof

（3）客户端命令

Redis服务器启动后，直接通过客户端执行命令：slaveof

我们可以输入info Replication来命令分别查看从服务器和主服务器的主从信息；

具体实际操作大家可以自己尝试，比较简单。

主从复制问题

上面介绍了从节点连接主节点，那么出现这两种情况会发生什么事：

1、主机挂了之后，从节点会不会自动升为主节点？

根据实际操作得知，我们主机挂掉之后，从节点会保持现状，俗话说的装死，等待主机恢复之后，恢复原来一主两备的现状，可以正常运行。

2、从机挂了之后，再次恢复，会不会自动连接到主机上？

从机挂了之后，再次恢复不会自动连接主机，需要重新配置。

主从复制过程

主从复制过程分为全量复制和部分复制；

全量复制：

Redis通过psync命令进行全量复制的过程如下：

（1）从节点判断无法进行部分复制，向主节点发送全量复制的请求；或从节点发送部分复制的请求，但主节点判断无法进行部分复制；具体判断过程需要在讲述了部分复制原理后再介绍。

（2）主节点收到全量复制的命令后，执行bgsave，在后台生成RDB文件，并使用一个缓冲区（称为复制缓冲区）记录从现在开始执行的所有写命令

（3）主节点的bgsave执行完成后，将RDB文件发送给从节点；从节点首先清除自己的旧数据，然后载入接收的RDB文件，将数据库状态更新至主节点执行bgsave时的数据库状态

（4）主节点将前述复制缓冲区中的所有写命令发送给从节点，从节点执行这些写命令，将数据库状态更新至主节点的最新状态

（5）如果从节点开启了AOF，则会触发bgrewriteaof的执行，从而保证AOF文件更新至主节点的最新状态

全量复制缺点：

（1）主节点通过bgsave命令fork子进程进行RDB持久化，该过程是非常消耗性能；

（2）主节点通过网络将RDB文件发送给从节点，对主从节点的带宽都会带来很大的消耗；

（3）从节点清空老数据、载入新RDB文件的过程是阻塞的，无法响应客户端的命令；如果从节点执行bgrewriteaof，也会带来额外的消耗

部分复制：

runid(replication ID)，主服务器运行id，Redis实例在启动时，随机生成一个长度40的唯一字符串来标识当前节点；

offset，复制偏移量。主服务器和从服务器各自维护一个复制偏移量，记录传输的字节数。当主节点向从节点发送N个字节数据时，主节点的offset增加N，从节点收到主节点传来的N个字节数据时，从节点的offset增加N；

replication backlog buffer，复制积压缓冲区。是一个固定长度的FIFO队列，大小由配置参数repl-backlog-size指定，默认大小1MB。需要注意的是该缓冲区由master维护并且有且只有一个，所有slave共享此缓冲区，其作用在于备份最近主库发送给从库的数据；

从机连接主机后，会主动发起 PSYNC 命令，从机会提供 master 的 runid(机器标识，随机生成的一个串) 和 offset（数据偏移量，如果offset主从不一致则说明数据不同步），主机验证 runid 和 offset 是否有效，runid 相当于主机身份验证码，用来验证从机上一次连接的主机，如果 runid 验证未通过则，则进行全同步，如果验证通过则说明曾经同步过，根据 offset 同步部分数据。

哨兵模式

上述讲到，如果主机挂掉之后，会出现主从模式失效，无法工作的现象；哨兵模式可以很好的解决这个问题，哨兵监控，会选举出新的主节点，保证主从能够正常工作。

sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。

哨兵配置过程：

1、在redis.conf目录下新增sentinel.conf文件；

2、配置文件中填写内容：

• sentinel monitor 监控数据库名字（自己起名字）127.0.01 6379 1
• 案例   sentinel monitor host6379 127.0.0.1 6379 1
• 上面最后一个数字1，表示主机挂掉后slave投票看让谁接替成为主机，得票数多少后成为主机

3、启动哨兵

redis-sentinel sentinel.conf

如果主机挂掉，哨兵会进行投票选举，确定新的主节点；

注意：如果主节点挂掉之后，重新归来之后，会变成从节点；

总结

主从模式会有复制延时的情况发生，由于所有的写操作都是在master上操作，然后同步更新到slave上，措意master同步到slave机器上有一定的延时，当系统很繁忙的时候，延时问题会加重，slave机器数量的增加也会使这个问题更加严重；