Redis主从复制与读写分离的实现

1、为什么要主从复制、读写分离

Redis在作为缓存的时候，随着项目访问量的增加，对Redis服务器的操作也越加频繁，虽然Redis读写速度都很快，但是一定程度上也会造成一定的延时，甚至出现宕机的可能性，这时候就出现了“单点故障”，那么为了解决访问量大的问题，通常会采取的一种方式是主从架构Master/Slave，Master 以写为主，Slave 以读为主，并且会伴随哨兵进行监控

主从复制机制说明：

• 主redis中的数据有两个副本(replication)即从redis1和从redis2，即使一台redis服务器宕机其他两台redis服务也可以继续提供服务。
• 主redis中的数据和从redis上的数据保持实时同步，当主redis写入数据时通过主从复制机制会复制到两个从redis服务上。
• 只有一个主redis，可以有多个从redis。
• 主从复制不会阻塞master，在同步数据时，master可以继续处理client请求。

一个 Redis 可以即是主又是从，如下图：

2、主从配置实践，修改配置文件

[root@localhost ~]# cd /usr/local/redis/bin/
[root@localhost bin]# cp redis.conf redis6379.conf
[root@localhost bin]# cp redis.conf redis6380.conf
[root@localhost bin]# cp redis.conf redis6381.conf

然后对这3个配置文件redis6379.conf、redis6380.conf、redis6381.conf分别进行修改（每个配置文件都要修改）

①、修改配置端口，分别改成对应的端口即可

注：我用的是FinalShell工具，挺方便的，推荐。

②、修改daemonize为yes

③、配置pid文件路径 pidfile

④、配置log 文件名字

⑤、配置rdb文件名

⑥、看情况选择：如果redis配置了密码（requirepass 123456），则还需在从redis服务中设置这一项，如果没有设置密码则忽略这一项

问题介绍：如果我们在主redis服务器上设置了密码，即：在redis.conf配置文件中使用了requirepass 123456（你设置的密码）；那么我们在从redis服务器上的配置文件redis.conf中使用了slaveof 127.0.0.1 6379后发现：主从复制失败。

解决方案：在从redis服务器上的配置文件redis.conf中找到：masterauth <master-password>这一行，然后在这一行的下面写上masterauth 123456(主redis服务器密码)。这时候我们再分别重启主redis服务器和从redis服务器，则发现主从复制成功！

当三份都配置完成后，分别启动这三个服务：

使用ps -ef | grep redis 查看：

然后通过如下命令选择不同的端口进入到这三个Redis客户端：

redis-cli -p 6379

3、设置主从关系

①、设置一主二从：

通过 INFO replication 命令查看发现，三个默认的都是Master角色，

然后我们将 6380 和 6381设置为Slave角色，可以使用如下命令：

SLAVEOF 127.0.0.1 6379
或
REPLICAOF 127.0.0.1 6379

这时 6380 和 6381成为了Slave，然后查看一下主机(Master)信息：

可以发现主机下面有两个Slave节点。

注：通过这种方式来设置主从关系，一旦服务重启，那么角色关系将不复存在。想要保存这种关系，可以通过Slave的 配置文件来进行配置。

分别编辑 redis6380.conf 和 redis6381.conf 配置文件，加入(约在286行)：

replicaof 127.0.0.1 6379

4、测试数据

①、给主节点设置值：set k1 v1

从节点也可以获取到值，说明没问题。

在没有设置主从关系之前，如果主节点内有数据，那么在设置主从关系后，Slave从节点也能获取到主节点原来的数据。

如果Master主节点挂掉了，Slave从节点的角色不会发生变化，一直处于等待状态，直到Master主节点重新启动。

如果要将Slave从节点变成Master节点，可以使用如下命令：

SLAVEOF no one

5、Redis配置文件解析

下面是redis主从复制场景的一些可调参数，需要根据实际环境调整

• slave-serve-stale-data yes ： 是否可以把不新鲜的数据服务与客户端
• slave-read-only yes ： 从节点只读，启用slaveof定义后才生效
• repl-diskless-sync no ：是否同时向多个从节点同时发数据
• repl-diskless-sync-delay 5 ：发送的延迟时间
• repl-ping-slave-period 10 探测从节点状态
• repl-timeout 60 探测节点超时时间
• repl-disable-tcp-nodelay no ： 启用nodelay
• repl-backlog-size 1mb
• slave-priority 100 ： 从节点优先级,复制集群中，主节点故障时，sentinel应用场景中的主节点选举时使用的优先级；数字越小优先级越高，但0表示不参与选举；
• min-slaves-to-write 3：主节点仅允许其能够通信的从节点数量大于等于此处的值时接受写操作；
• min-slaves-max-lag 10：从节点延迟时长超出此处指定的时长时，主节点会拒绝写入操作；

6、主从复制的优点(特点)与缺点

6.1、优点(特点)

主从采用异步复制数据

主数据库可以进行读写操作，当写操作时会自动将数据同步给从数据库

从数据库一般只读的，并且接收主数据库同步过来的数据

一个master可以拥有多个slave，但是一个slave只能对应一个master

一个slave也可以连接多个slave

slave意外退出，不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来

master意外退出，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务

master挂了以后，不会在slave节点中重新选一个master

6.2、缺点

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

7、Redis主从复制之原理介绍

Slave启动成功连接到Master后会发送一个sync命令，Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，Master将传送整个数据文件到Slave,以完成一次完全同步

• 全量同步：而Slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
• 增量同步：Master继续将新的所有收集到的修改命令依次传给slave,完成同步。

但是只要是重新连接Master,一次完全同步（全量同步）将被自动执行。

--详细介绍：

①、全量同步

Redis 的全量同步过程主要分三个阶段：

同步快照阶段： Master 创建并发送快照给 Slave ， Slave 载入并解析快照。 Master 同时将此阶段所产生的 新的写命令存储到缓冲区。

同步写缓冲阶段： Master 向 Slave 同步存储在缓冲区的写操作命令。

同步增量阶段： Master 向 Slave 同步写操作命令。

②、增量同步

Redis 增量同步主要指 Slave 完成初始化后开始正常工作时， Master 发生的写操作同步到 Slave 的过程。

通常情况下， Master 每执行一个写命令就会向 Slave 发送相同的写命令，然后 Slave 接收并执行。

到此这篇关于Redis主从复制与读写分离的实现的文章就介绍到这了,更多相关Redis主从复制与读写分离内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！