Redis主从复制

Redis主从复制

概念

​ 主从复制，指的是将一台Redis服务器的数据，复制到其他的Redis服务器。前者称之为主节点，后者称之为从节点。数据的复制是单向的，只能由主节点到从节点。主节点以写为主，从节点以读为主。

​ 默认情况下，每台Redis服务器都是主节点。

​ 通常我们会使用一主二从。原因有两个：

​ 1.两个从节点才能进行哨兵机制的选举；而为了保证可以高效的进行选举，一般都会部署奇数个从节点（试想一下，如果部署了偶数个节点，一旦主节点挂掉，恰巧投票节点A的一半节点B的也是一般咋办？）

​ 2.如果一主一从，那么它们两个都挂掉的概率还是挺高的，但是如果一主二从，三个服务器都挂掉的机率就会大大降低。

主从复制的作用

数据冗余

​ 主从复制实现了数据的热备份，是持久化以外的一种数据冗余方式

故障恢复

​ 当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复

负载均衡

​ 在主从复制基础上，配合读写分离，可以由主节点提供写服务，从节点提供读服务，分担服务器的负载。尤其在写少读多的场景下，通过多个节点来分担读负载，提高Redis服务器的并发量

高可用基石

​ 主从复制也是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础

环境配置

只需要配置从库，主库不需要。因为Redis默认就是主库

测试方法：在本地启动三个客户端，分别使用6379、6380、6381三个端口，6379做主服务器，另外两个做从服务器

配置文件修改：

首先将redis配置文件copy三个

打开配置文件，修改端口+三个日志文件（因为都是本地，为了防止日志文件冲突，日志文件名称也要修改）

分别打开三个窗口链接79、80、81

修改80为从库，主库为79：

79主库已经能看到80从库

81也是同理

场景测试：

​ 主库可以写入，从库只能读取，写入会报错

​ 主库如果挂了，从库依旧会链接到主库。一旦主库链接成功，会立刻同步数据到从库（因为测试用的命令行配置，没有哨兵配置，所以从库依旧会连接到主库）

​ 从库如果挂了，如果是命令行修改的主从，那么从库重启会丢失这个配置，如果再手动配置主从，就会进行一次全量复制

全量复制

​ 当从库第一次链接到主库，就会进行一次全量复制。

• 1.slave发送sync命令到master。

• 2.master接收到SYNC命令后，执行bgsave命令，生成RDB全量文件。

• 3.master使用缓冲区，记录RDB快照生成期间的所有写命令。

• 4.master执行完bgsave后，向所有slave发送RDB快照文件。

• 5.slave收到RDB快照文件后，载入、解析收到的快照。

• 6.master使用缓冲区，记录RDB同步期间生成的所有写的命令。

• 7.master快照发送完毕后，开始向slave发送缓冲区中的写命令;

• 8.salve接受命令请求，并执行来自master缓冲区的写命令

  redis2.8版本之后，已经使用psync来替代sync，因为sync命令非常消耗系统资源，psync的效率更高。

sync的缺点：

1. 主服务器需要执行bgsave来生成rdb文件，需要耗费主服务器的大量CPU，内存，I/O资源
2. 主服务器将生成的rdb文件发送给从服务器，发送操作会耗费主从服务器大量的网络资源，并对主服务器响应命令请求的时间产生影响
3. 从服务器接受到主库发来的rdb文件，在载入期间，会因为阻塞而无法处理其他命令请求
4. 从库一旦断线，重连后将会再次触发sync，其实只需要断线期间的增量数据

psync

redis自2.8版本以后加入的

psync流程图：

完整重同步

​ 同sync

部分重同步

​ 通过主服务器的服务器运行ID、主服务器与从服务器的复制偏移量、主服务器的复制缓冲区来完成部分重同步，可以查看上面的流程图

增量复制

​ 全量同步之后，如果主库再次发生更新，就会出发增量复制

哨兵模式

​ 当主服务器宕机后，前面通过人工配置，将一台从服务器切换为主服务器，需要人工干预。Redis自2.8版本以后，提供了哨兵模式，能够后台监控主机是否故障，如果主机发生故障无法正常链接，哨兵可以通过投票选举，自动将从库切换为主库。

​ 哨兵模式是一种特殊的模式，哨兵是一个独立的进程，通过发送命令等待Redis服务器响应，来监控运行的多个Redis实例。如果只有一个哨兵进程对Redis服务器进行监控，就可能出现问题，所以一般使用多个哨兵来进行监控，各个哨兵之间也可以互相监控。

​ 一旦主节点发生故障下线，哨兵A观察到了，会先对主节点标记为主观下线，并向其余监视主节点的哨兵进行询问。如果其余的哨兵也认为主节点不可用，并数量超过一定的值（在配置中配置），主节点就会被判定为客观下线，并对主服务器进行故障转移。

​ 首先，检测主节点的哨兵会进行协商，选举出一个领头哨兵，由领头哨兵对主节点进行故障转移操作。

​ 故障转移操作：

1）领头哨兵在从服务器中选举出一个主服务器，并将其切换为主服务器

2）通过发布订阅，将已下线主服务器的从服务器的主服务器改为新的

3）将已下线的主服务器切换为新的主服务器的从服务器

主服务器选举：领头哨兵会保存已下线的主服务器的所有服务器到列表中，从中剔除掉已下线的，5s内没回复过消息的，断开连接的服务器。然后在其中按照优先级对他们进行排序，如果有多个优先级相同的服务器，就按照复制偏移量进行排序，选出其中复制偏移量最大的服务器（保存了最新的数据），如果有多个优先级相同、复制偏移量也相同的服务器，那么就按照他们的容器运行ID进行排序，选举出其中id最小的服务器作为主服务器。