Redis的复制
复制概述
在使用Redis的过程中,我们可能会遇到如下问题:
Redis的读并发量太大怎么办?单机版的Redis挂掉怎么办?我们需要并发又要安全,在Redis3.0后,官方发布了集群方案。
官网说明
在Redis复制的基础上(不包括由Redis Cluster或Redis Sentinel作为附加层提供的高可用性功能),有一个非常简单的使用和配置领导者跟随者(主从)复制:它允许从属Redis实例连接主实例的副本。每次链接断开时,从站将自动重新连接到主站,并且无论主站发生什么情况,它都会尝试成为它的精确副本。
该系统使用三种主要机制:
1、当主实例和从属实例连接良好时,主设备通过向从设备发送命令流来保持从设备更新,以便复制对主设备端发生的数据集的影响,原因是:客户端写入,密钥已过期或驱逐,更改主数据集的任何其他操作。
2、当主设备和从设备之间的链路中断时,对于网络问题或者由于主设备或从设备中检测到超时,从设备重新连接并尝试继续部分重新同步:这意味着它将尝试仅获取部件它在断开连接时错过的命令流。
3、当无法进行部分重新同步时,从站将要求完全重新同步。这将涉及一个更复杂的过程,其中主机需要创建其所有数据的快照,将其发送到从机,然后在数据集更改时继续发送命令流。
Redis默认使用异步复制,即低延迟和高性能,是绝大多数Redis用例的自然复制模式。但是,Redis从站异步确认它们与主站定期收到的数据量。因此主设备不会每次等待从设备处理命令,但是如果需要,它知道哪个从设备已经处理了什么命令。这允许具有可选的同步复制。
总结:复制,也就是我们说的主从复制,主机数据更新后根据配置和策略,自动同步到从机的master/slaver机制,Master以写为主,Slave以读为主。
使用主从复制可以实现读写分离、容灾恢复。
定义
主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(master),后者称为从节点(slave);数据的复制是单向的,只能由主节点到从节点。
默认情况下,每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。
主从复制的作用
主从复制的作用主要包括:
-
数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。
-
故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
-
负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。
-
高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。
主从配置原理
Slave启动成功连接到master后会发送一个sync命令。
Master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令, 在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步。
全量复制:slaver服务在接收到数据库文件数据后,将其存盘并加载到内存中。
增量复制:Master继续将新的所有收集到的修改命令依次传给slave,完成同步,但是只要是重新连接master,一次完全同步(全量复制)将被自动执行。
全量复制
Redis全量复制一般发生在Slave初始化阶段,这时Slave需要将Master上的所有数据都复制一份。具体步骤如下:
1、从服务器连接主服务器,发送SYNC命令;
2、主服务器接收到SYNC命名后,开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令;
3、主服务器BGSAVE执行完后,向所有从服务器发送快照文件,并在发送期间继续记录被执行的写命令;
4、从服务器收到快照文件后丢弃所有旧数据,载入收到的快照;
5、主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令;
6、从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令;
完成上面几个步骤后就完成了从服务器数据初始化的所有操作,从服务器此时可以接收来自用户的读请求。
增量同步
Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令。
Redis主从同步策略
主从刚刚连接的时候,进行全量同步;全同步结束后,进行增量同步。当然,如果有需要,slave 在任何时候都可以发起全量同步。redis 策略是,无论如何,首先会尝试进行增量同步,如不成功,要求从机进行全量同步。
注意点
如果多个Slave断线了,需要重启的时候,因为只要Slave启动,就会发送sync请求和主机全量同步,当多个同时出现的时候,可能会导致Master IO剧增宕机。
使用主从复制
原则:配从不配主。
配置命令
SLAVEOF 主库IP 主库端口
每次与master断开之后,都需要重新连接,除非你配置进redis.conf文件。
#配置主从复制,参数:主机的ip、端口
replicaof <masterip> <masterport> #redis5.x后 之前为slaveof
info replication
可以查看:
一主二仆
配置一个Redis主机附带两个从机,需要开启3台Redis服务。
详细操作:
1、拷贝多个redis.conf文件
2、在配置文件中开启daemonize yes,修改pid文件名字
3、指定端口
4、log文件名字
5、dump.rdb名字
此时开启3台redis服务后,这3个redis都是主机。可以使用info replication
查看主从信息。
直接使用SLAVEOF 主库IP 主库端口
配置从机就行了。
薪火相传
上一个Slaver可以是下一个slaver的Master,Slaver同样可以接收其他 slavers的连接和同步请求,那么该slaver作为了链条中下一个的master, 可以有效减轻master的写压力。
中途变更转向:会清除之前的数据,重新建立拷贝最新的。Slaveof 新主库IP 新主库端口
。
反客为主
当主节点挂掉后,可以手动将一个从节点升级为Master,使用命令:slaveof no one。
具体操作:
1、Master节点:shutdowm 关闭节点 (模拟挂掉)
2、Slaver1节点:slaveof no one 将其升级为Master节点
3、Slaver2节点:使用slaveof Slaver1节点ip port 重连Slaver1将其视为Master节点
4、原来的Master节点:重新启动后,使用slaveof Slaver1节点ip port 连接Slaver1将其视为Master节点,自己变成Slaver节点
哨兵模式
哨兵模式为反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库。
一组sentinel能同时监控多个Master。
使用步骤
1、自定义的/myredis目录下新建sentinel.conf文件,名字绝不能错。
[root@localhost myredis]# touch sentinel.conf
[root@localhost myredis]# vim sentinel.conf
2、配置哨兵,填写内容
#sentinel monitor 被监控主机名字(自己起名字) 127.0.0.1 6379 1
sentinel monitor hos6379 127.0.0.1 6379 1
上面最后一个数字1,表示主机挂掉后salve投票看让谁接替成为主机,得票数多少后成为主机。
3、启动哨兵
[root@localhost myredis]# /usr/local/redis/bin/redis-sentinel ./sentinel.conf
4、正常主从演示,原有的master挂了会投票新选,重新主从继续开工。
如果之前的master重启回来,会变成slaver。即原来的slaver会反客为主。
复制的缺点
由于所有的写操作都是先在Master上操作,然后同步更新到Slaver上,所以从Master同步到Slaver机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slaver机器数量的增加也会使这个问题更加严重。
所以使用Redis时一般会搭建Redi集群的方式,在Redis集群中可以使用主从复制的模式。