一、Redis主从复制
1 Redis主从复制简介
主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(Master),后者称为从节点(Slave);数据的复制是单向的,只能由主节点到从节点。
默认情况下,每台Redis服务器都是主节点;且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。
Master以写为主,Slave以读为主。
主从复制的作用:
1. 数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。
2. 故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
3. 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。
4. 高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是
Redis高可用的基础。
一般来说,要将Redis运用于工程项目中,只是用一台Redis是万万不能的,原因如下:
1. 从结构上,单个redis服务器会发生单点故障,并且一台服务器需要处理所有的请求负载,压力较大;
2. 从容量上,单个redis服务器内存容量有限,就算一台Redis服务器内容容量为256G,也不能将所有内存用做Redis存储内存,一般来说,单台Redis最大使用内存不应该超过20G。
2 Redis主从复制-一主多从
搭建一主二从的Redis服务器
环境搭建
1. 在同一台虚拟机上配置一主二从Redis服务器,由于单台机器,同一个端口只允许一个进程占用,所以需要修改其他两台Redis的端口。
2. 在/usr/local/myredis文件夹下,新创建三个redis的配置文件,分别为redis6379.conf、
redis6380.conf、redis6381.conf,由文件名可知,redis的端口号分别为6379、6380、6381。
创建出3个空文件,redis.conf是原有的配置文件。
3. 在三个配置文件写入内容
可以通过include /usr/local/myredis/redis.conf将公共基础配置直接引入文件。
将include /usr/local/myredis/redis.conf统一添加到这三个文件中
在各个文件中,添加对应的pidfile、port、dbfilename
如:
redis6379.conf中添加 pidfile /var/run/redis_6379.pid port 6379 dbfilename dump6379.rdb
redis6380.conf中添加 pidfile /var/run/redis_6380.pid port 6380 dbfilename dump6380.rdb
redis6381.conf中添加 pidfile /var/run/redis_6381.pid port 6381 dbfilename dump6381.rdb
4. 通过不同的redis.conf文件,分别启动3个redis服务
./redis-server /usr/local/myredis/redis6379.conf ./redis-server /usr/local/myredis/redis6380.conf ./redis-server /usr/local/myredis/redis6381.conf
通过ps -ef | grep redis命令查看redis服务,3个服务均已启动
5. 在redis客户端中,通过info replication命令可以查看Redis服务器当前状态
可以给redis-cli命令添加-p参数,来指定链接哪个服务器
./redis-cli -p 6379 ./redis-cli -p 6380 ./redis-cli -p 6381
所有的服务器目前都是master
6. 配从(6380、6381)不配主(6379)
slaveof ip port成为某个实例的从服务器。
在从机6380和6381上执行:slaveof 127.0.0.1 6379
在主库(6379)中再次执行info replication
有两个从库,分别为6380和6381。
7. 在主库(6379)中写数据,可以在从库(6380、6381)中读取到。
注意:
在从库中进行写操作,会报错。
由于该主从复制在同一台虚拟机上搭建,所以需要修改端口号,如果在多台服务器上搭建主从复制,则需要修改相对应的ip。
如果在多台服务器上搭建主从复制,一定要开放远程链接。
3 Redis主从复制-复制原理
3.1 主从复制的一些问题
1. 如果Master断开(宕机),Slave依然连接着Master,可以正常使用读操作,但是没有写操作。如果Master恢复正常,Slave依旧可以直接获取Master写的信息。
2. 如果Slave断开(宕机),当该Slave重启成功,则会变为Master,需要通过slaveof 恢复成Slave,只要变为Slave,立刻可以从Master同步所有数据。
3.2 复制原理
- Slave启动成功连接到Master后会主动发送一个同步(sync)命令。
- Master接到Slave的命令,把Master数据进行持久化,把rdb文件发送给Slave,Slave拿到rdb进行读取。
- 每次Master进行写操作之后,会和Slave进行数据同步。
- 全量复制:一般发生在Slave初始化阶段,这时Slave需要将Master上的所有数据都复制一份。
- 增量复制:指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
3.3 薪火相传
上一个Slave(从机)是下一个Slave(从机)的Master(主机)。
优点:Slave同样可以接收其他Slave的连接和同步请求,那么该Slave作为了链条中下一个的Master, 可以有效减轻Master的压力,去中心化降低风险。
缺点:一旦某个Slave宕机,后面的Slave都无法备份。
注意:
- 也是通过slaveof ip port命令修改Master。
- 中途变更转向:会清除之前的数据,重新建立拷贝最新的。
- Slave6380本质上仍然是从库,只能读、不能写。
3.4 反客为主
当一个Master宕机后,后面的Slave可以立刻升为Master,其后面的Slave不用做任何修改。
通过slaveof no one 将Slave变为Master。
4 Redis主从复制-哨兵模式(Sentinel)
反客为主的自动版,能够后台监控Master是否故障,如果故障了,根据投票数自动将Slave转换为
Master。
哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。