redis主从复制、哨兵和集群
一、redis持久化
1.1持久化的功能
Redis是内存数据库,数据都是存储在内存中,为了避免服务器断电等原因导致Redis进程异常退出后数据的永久丢失,需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘;
当下次Redis重启时,利用持久化文件实现数据恢复。除此之外,为了进行灾难备份,可以将持久化文件拷贝到一个远程位置。
1.2redis持久化方式
RDB持久化(Redis DataBase) :原理是将Reids在内存中的数据库记录定时保存到磁盘上。
AOF持久化(append only file) :原理是将Reids的操作日志以追加的方式写入文件,类似于MySQL的binlog。
二、RDB持久化
2.1
手动触发
save命令和bgsave命令都可以生成RDB文件。
save命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在Redis服务器阻塞期间,服务器不能处理任何命令请求。
而bgsave命令会创建一个子进程,由子进程来负责创建RDB文件,父进程 (即Redis主进程) 则继续处理请求。
bgsave命令执行过程中,只有fork 子进程时会阻塞服务器,而对于save命令,整个过程都会阻塞服务器,因此save已基本被废弃,线上环境要杜绝save的使用。往往生产环境 bgsave 依然不允许轻易使用
自动触发
vim /etc/redis/6379.conf
--219行--以下三个save条件满足任意一个时,都会引起bgsave的调用
save 900 1 :当时间到900秒时,如果redis数据发生了至少1次变化,则执行bgsave
save 300 10 :当时间到300秒时, 如果redis数据发生了至少10次变化,则执行bgsave
save 60 10000 :当时间到60秒时,如果redis数据发生了至少10000次变化, 则执行bgsave
--242行--是否开启RDB文件压缩
rdbcompression yes
--254行--指定RDB文件名
dbfilename dump.rdb
--264行--指定RDB文件和AOF文件所在目录
dir /var/lib/redis/6379
三、AOF持久化
Redis服务器默认开启RDB,关闭AOF: 要开启AOF,需要在配置文件中配置:
vim /etc/ redis/ 6379. conf
- 700行--修改, 开启AOF
appendonly yes
--704行--指定A0F文件名称
appendfilename "appendonly.aof"
--796行--是否忽略最后一条可能存在问题的指令
aof-load-truncated yes
/etc/init.d/redis_6379 restart
ls /var/lib/redis/6379/
RDB持久化 优点:RDB文件紧凑,体积小,网络传输快,适合全量复制;恢复速度比AOF快很多。当然,与AOF相比, RDB最重要的优点之一是对性能的影响相对较小。
缺点:RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化,而在数据越来越重要的今天,数据的大量丢失很多时候是无法接受的,因此AOF持久化成为主流。此
外,RDB文件需要满足特定格式,兼容性差(如老版本的Redis不兼容新版本的RDB文件)。 对于RDB持久化,一方面是bgsave在进行fork操作时Redis主进程会阻塞,另一方面,子进程向硬盘写数据
也会带来IO压力。
AOF持久化 与RDB持久化相对应,AOF的优点在于支持秒级持久化、兼容性好,缺点是文件大、恢复速度慢、对性能影响大。 对于AOF持久化,向硬盘写数据的频率大大提高(everysec策略
下为秒级),IO压力更大,甚至可能造成AOF追加阻塞问题。
故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
负载均衡:在主从复制的基础.上,配合读写分离,可以让主节点提供写服务,由从节点提供读服务〈即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载;
尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。
无论是第一次连接还是重新连接,Master机器都会启动一个后台进程,将数据快
照保存到数据文件中(执行rdb操作),同时Master还会记录修改数据的所有命令并缓存在数据文件中。
后台进程完成缓存操作之后,Master机器就会向Slave机器发送数据文件存储,接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。若slave出现故障导致宕机,则恢复
正常后会自动重新连接。
![](https://i-blog.csdnimg.cn/blog_migrate/09fd6e644dc017a3f45c5f5339169413.png)
master:192.168.224.100
slave1:192.168.224.101
slave2:192.168.224.102
systemctl stop firewalld
#关闭防火墙
setenfroce 0
yum install gcc gcc-c++ make -y
#安装编译工具
cd /opt
tar xf redis-5.0.7.tar.gz
#解压安装包
cd redis-5.0.7/
make && make prefix=/usr/local/redis install
cd utils/
./install_server.sh
.....一直回车
Please select the redis executable path [/usr/local/bin/redis-server] /usr/local/redis/bin/redis-server
#把配置文件改为/usr/local/redis/bin/redis-server
master节点
vim /etc/redis/6379.conf
bind 0.0.0.0
#第70行修改监听地址为0.0.0.0
daemonize yes
#第137行开启守护进程
logfile /var/log/redis_6379.log
#第172行指定日志文件
dir /var/lib/redis/6379
#第264行指定工作目录
appendonly yes
#第700行开启AOF持久化功能
/etc/init.d/redis_6379 restart
#重启服务
slave节点
vim /etc/redis/6379.conf
bind 0.0.0.0
#第70行修改监听地址为0.0.0.0
daemonize yes
#第137行开启守护进程
logfile /var/log/redis_6379.log
#第172行指定日志文件
dir /var/lib/redis/6379
#第264行指定工作目录
replicaof 192.168.224.100 6379
#第288行添加masterIP地址和端口号
appendonly yes
#第700行开启AOF持久化功能
/etc/init.d/redis_6379 restart
#重启服务
4.3.4
tail -f /var/log/redis_6379.log
#查看redis日志文件
Replica 192.168.224.101:6379 asks for synchronization
Replica 192.168.224.102:6379 asks for synchronization
五、redis哨兵模式
5.1
自动故障转移:当主节点不能正常工作时,哨兵会开始自动故障转移操作,它会将失效主节点的其中一个从节点升级为新的主节点,并让其他从节点改为复制新的主节点。
![](https://i-blog.csdnimg.cn/blog_migrate/ba10bb809647c4dd0ac0eb787a700313.png)
master:192.168.224.100
slave1:192.168.224.101
slave2:192.168.224.102
systemctl stop firewalld
#关闭防火墙
setenfroce 0
vim /opt/redis-5.0.7/sentinel.conf
#切换到哨兵配置文件中
protected-mode no
#第17行关闭保护模式
port 26379
#第21行Redis哨兵默认的监听端口
daemonize yes
#第26行指定sentinel为后台启动
logfile "/var/log/sentinel.log"
#第36行指定日志存放路径
dir "/var/lib/redis/6379"
#第65行指定数据库存放路径
sentinel monitor mymaster 192.168.224.100 6379 2
#第84行修改指定该哨兵节点监控192.168.224.100:6379这个主节点。
sentinel down-after-milliseconds mymaster 30000
#第113行判定服务器down掉的时间周期,默认30000毫秒(30秒)
sentinel failover-timeout mymaster 180000
#第146行故障节点的最大超时时间为180000(180秒)
5.3.4启动哨兵模式
先启动master节点,再启东slave节点
cd /opt/redis-5.0.7/
#切换到redis目录下
redis-sentinel sentinel.conf &
#启动哨兵模式
5.3.5
将master节点服务器挂起,到slave1输入命令查看
redis-cli -p 26379 info Sentinel
#查看主节点服务器,已经切换到192.168.224.102为master节点
六、集群模式
6.1集群工作原理
master,从而可以保证redis服务的正常使用,但是无法解决redis单机写入的瓶颈问
题,即单机redis写入性能受限于单机的内存大小、并发数量、网卡速率等因素。
Redis Cluster特点如下:
所有Redis节点使用(PING机制)互联,集群中某个节点的是否失效,是由整个集群中超过半数的节点监测都失效,才能算真正的失效客户端不需要proxy即可直接连接redis,应用
程序中需要配置有全部的redis服务器IPredis cluster把所有的redis node 平均映射到 0-16383个槽位(slot)上,读写需要到指定的redisnode上进行操作,因此有多少个redisnode相当于
redis 并发扩展了多少倍,每个redis node 承担16384/N个槽位Redis cluster预先分配16384个(slot)槽位,当需要在redis集群中写入一个key -value的时候,会使用CRC16(key)取余16384
之后的值,决定将key写入哪一个槽位从而决定写入哪一个Redis节
![](https://i-blog.csdnimg.cn/blog_migrate/850fff14a5df5184416af81a4895fa20.png)
cd /etc/redis/
mkdir -p redis-cluster/redis600{1..6}
for i in {1..6}; do cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis600$i; cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/red
redhat-release redis/
for i in {1..6}; do cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis600$i; cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i
> done
cd redis-cluster/
ls
redis6001 redis6002 redis6003 redis6004 redis6005 redis6006
cd redis6006
ls
redis-cli redis.conf redis-server
6.2.2
cd /etc/redis/redis-cluster/redis6001
vim redis.conf
#69行,注释掉,默认监听所有网卡
#bind 192.168.224.100
#88行,修改,关闭保护模式
protected-mode no
#92行,修改,redis监听端口
port 6001
#136行,以独立进程启动
daemonize yes
#699行,修改,开启AOF持久化
appendonly yes
#832行,取消注释,开启群集功能
cluster-enabled yes
#840行,取消注释,修改,群集名称文件设置
cluster-config-file nodes-6001.conf
#846行,取消注释,群集超时时间设置
cluster-node-timeout 15000
cd /etc/redis/redis-cluster/redis6001
vim redis.conf
vim redis.conf
cp redis.conf /etc/redis/redis-cluster/redis6002
cp redis.conf /etc/redis/redis-cluster/redis6003
cp redis.conf /etc/redis/redis-cluster/redis6004
cp redis.conf /etc/redis/redis-cluster/redis6005
cp redis.conf /etc/redis/redis-cluster/redis6006
cd /etc/redis/redis-cluster/redis6002
vim redis.conf
#92行,修改,redis监听端口
port 6002
#840行,取消注释,修改,群集名称文件设置
cluster-config-file nodes-6002.conf
6.2.3
[root@node2 redis6006]# for d in {1..6}
> do
> cd /etc/redis/redis-cluster/redis600$d
> redis-server redis.conf
> done
ps -ef | grep redis
6.2.4
redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1
#六个实例分为三组,每组一主一从,前面的做主节点,后面的做从节点。下面交互的时候 需要输入 yes 才可以创建。
6.2.5
redis-cli -p 6001 -c
#加-c参数,节点之间就可以互相跳转
cluster slots
#查看节点的哈希槽编号范围
set name xyk
cluster keyslot xyk
#查看name键的槽编号
七、总结
主从复制:主从复制是高可用Redis的基础,哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份,以及对于读操作的负载均衡和简单的故障恢复。
缺陷:故障恢复无法自动化;写操作无法负载均衡;存储能力受到单机的限制。
哨兵:在主从复制的基础上,哨兵实现了自动化的故障恢复。
缺陷:写操作无法负载均衡;存储能力受到单机的限制;哨兵无法对从节点进行自动故障转移,在读写分离场景下,从节点故障会导致读服务不可用,需要对从节点做额外的监控、切换操作。
集群:通过集群,Redis解决了写操作无法负载均衡,以及存储能力受到单机限制的问题,实现了较为完善的高可用方案。