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

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

主从复制机制说明

1. 主redis中的数据有两个副本(replication)即从redis1和从redis2即使一台redis服务器宕机其他两台redis服务也可以继续提供服务。

2. 主redis中的数据和从redis上的数据保持实时同步当主redis写入数据时通过主从复制机制会复制到两个从redis服务上。

3. 只有一个主redis可以有多个从redis。

4. 主从复制不会阻塞master在同步数据时master可以继续处理client请求。

5. 一个 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,以完成一次完全同步

1. 全量同步而Slave服务在接收到数据库文件数据后将其存盘并加载到内存中。

2. 增量同步Master继续将新的所有收集到的修改命令依次传给slave,完成同步。

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

--详细介绍

①、全量同步

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

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

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

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

②、增量同步

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

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

8、相关文章

一、Redis简介、数据类型和命令

二、Redis数据类型介绍、使用场景及其操作命令

三、Redis事务的概述、设计与实现

四、Redis 发布订阅模式的深度解析与实现消息队列

五、Redis持久化RDB的三种触发机制及其优缺点

六、Redis主从复制与读写分离

七、Redis持久化RDB的三种触发机制及其优缺点