持久化
redis默认开启的持久化策略是RDB。如果两个都开启了,重启时默认用AOF。一般来说AOF数据更全。
RDB
在redis.conf中配置多个策略 ,其中一个条件被触发,就将内存中的全部数据写入dump.rdb二进制文件。也可以在客户端使用save或bgsave命令进行内存快照。RDB每次快照会覆盖原有数据。
save 900 1 # 900秒内有一次修改
save 300 10 # 300秒内有10次修改
save 60 1000 #60秒内有1000次修改
save是主线程执行的命令,会造成阻塞,默认使用bgsave进行异步保存。
缺点
数据丢失。做一个持久化会把内存中所有的数据快照,频繁快照影响性能,且配置的触发保存的条件也不能频繁执行,如果配置半分钟保存一次,宕机后,最后半分钟数据因未保存而丢失。
什么是写时复制COW?
Copy-On-write,在生成快照的同时,可以正常处理写命令。
主线程fork生成bgsave子进程,可以共享主线程的所有内存数据。
bgsave子进程将主线程的内存数据写入RDB的同时,如果主线程在修改数据,这个数据会被复制一份,由bgsave子进程把该副本写入RDB文件,主线程依然可以直接修改原来的数据。
AOF
Append Only File 追加保存指令。
在redis.conf文件中开启aof功能。 将修改的每一条指令,追加到appendonly.aof文件中。恢复服务时,重新将文件中的指令逐条执行。
appendonly yes
持久化策略
- 每秒执行一次 【默认采用,兼顾速度和安全性】
- 每执行一条命令 影响性能
- 将数据交给操作系统处理
appendfsync always #每当有新命令追加到AOF文件时就执行一次fsync,非常慢,但也很安全
appendfsync everysec #每秒fsync一次,足够快,并且在故障时只会丢失1秒的数据
appendfsync no #从不fsync,将数据交给操作系统来处理。更快,也更不安全
缺点
如果redis长时间运行,那么aof文件会很大。恢复数据时,要重新将aof的命令全部执行,恢复慢。【文件大,恢复慢】
宕机时,也会丢失一秒数据。
AOF重写
对于INCR readcount 累加操作,如果在AOF中记录每一次INCR命令,在恢复数据时,会要重新执行N遍。如果记录一个最终的累加值,恢复数据时只需要一次读取。
auto-aof-rewrite-min-size 64mb //aof文件达到64MB才会自动重写,文件太小恢复速度本来就很快,重写意义不大
auto-aof-rewrite-percentage 100 //aof文件自上一次重启后文件大小增长100%则再次触发重写
也可以在客户端执行命令手动重写 bgrewriteaof
注:AOF重写时,redis会fork出一个子进程去做,不会对redis正常命令处理有太多影响。
RDB与AOF对比
混合持久化
Redis4.0后,结合了RDB和AOF优点,新增了混合持久化方式。它其实就是在AOF的基础上进行了优化。 必须先开启AOF,可以关闭RDB。
aof-use-rdb-preamble yes
工作原理
AOF重写时,会将这一刻之前的内存做RDB快照处理,并将RDB快照内容和增量的AOF修改内存数据的命令存放在一起,重写完成才会将文件名改为appendonly.aof覆盖原文件。
Redis重启时,可以先加载RDB的内容,然后再重放增量AOF日志,就可以完全替代之前的AOF全量文件重放,效率大幅提升。
Redis数据备份策略
- 写crontab定时调度脚本,每小时都copy一份rdb或aof的备份到一个目录中去,仅仅保留最近48小时的备份
- 每天保留一份当日的数据备份到一个目录中去,可以保留最近一个月的备份
- 每次copy备份的时候,都把太旧的备份删掉,避免占用空间。
- 多机器备份,以防机器损坏。每天晚上,将当前机器上的备份复制一份到其他机器上。
主从架构
只有主节点提供写服务。从节点备份,也可以提供读操作,缓解主节点压力
搭建主从的配置信息
首先复制一份redis.config文件
Redis主从工作原理
master配置了slave之后,不管这个slave是不是第一次连接上master,它都会发送一个PSYNC命令给master请求复制数据。
master收到PSYNC命令后,会在后台进行数据持久化,通过bgsave命令生成最新的rdb快照文件。
持久化期间master会继续接收客户端的请求,并把这些修改请求命令缓存在内存中。当持久化完成后,master会把之前缓存在内存中的命令发送给slave。
当master与slave的连接中断时,slave能够自动重连master。 如果maser收到多个slave并发连接请求,它只会进行一次持久化,再把这一份持久化数据发送给多个并发连接的slave。
全量复制
repl backlog buffer 增量日志缓冲区默认是1MB
replica-backlog-size 1mb
部分复制
主从复制风暴
多个从节点同时复制主节点导致主节点压力过大。采用阶梯式节点复制。
优化措施:部分从节点与主节点同步完成后,让其他的从节点去复制已完成同步的从节点。
哨兵架构
单纯的主从架构,从节点只是用来备份或读操作,主节点宕机后,不能自动进行主节点的选举。
哨兵是用来监听主从节点的状态的,客户端不再直接连主从节点,而是连接哨兵节点。主从节点宕机后,哨兵能选举出新的主节点。
因为哨兵知道所有的主从节点信息,所以哨兵会把主节点信息返回给客户端。客户端第一次连接哨兵成功之后,拿到了主节点信息,第二次之后直接访问主节点。 选举完成后,哨兵会把新的主节点信息推送给客户端。
哨兵本身也是redis实例。
管道 Pipeline
redis执行命令的时间很短,但从客户端发到服务端的时间比执行命令的时间更长,所以可以用管道,客户端一次性发送N条命令,节省N-1次命令发送的网络传输的开销
管道没有事务原子性,第一条执行失败后,会继续执行剩下的命令。全部执行完成后返回一个结果集