Redis持久方式
聊到redis,给我们的第一印象就是快,因为是纯内存数据库。那么redis到底能否进行持久化呢?答案是肯定的,下面我们就来看一下redis的两种持久化的机制,并且比对一下两者的优缺点。
# RDB模式
RDB模式为redis database,其工作原理是每隔一段时间,把内存数据库的文件同步写入到磁盘中作为快照。恢复的时候再把快照文件读入到内存中。如果宕机,那么内存中的数据会消失,此时重启redis,数据有会恢复。
简而言之:内存备份--->磁盘临时文件,磁盘临时文件--->恢复到内存。
# 优势:
(1)每隔一段时间全量备份。
(2)灾备简单,可以远程传输。
(3)子进程备份的时候,主进程不会有任何的IO操作(不会有修改或者删除),保证备份数据的完整性。
(4)相当于AOF来说,当有大文件的时候可以快速实现重启恢复
# 劣势:
(1)发生故障的时候,有可能丢失最后一次备份的数据。
(2)子进程所占用的内存和父进程所占的内存一样,会造成CPU的 负担。
(3)由于定时全量备份是重量级操作,所以针对于实时备份,其实是做不到的。
# 配置方式
redis配置保存位置,例如:/user/local/redis/working/dump.rdb
保存机制:
save 900 1 **如果一个缓存更新,则15分钟之后进行备份 save 300 10 **如果十个缓存更新,则10分钟之后进行备份 save 60 10000 **如果10000个缓存更新,则1分钟之后进行备份
1
2
3stop-writes-on-bgsave-error
- Yes:如果save过程出错,则停止写操作
- No:可能造成数据不一致
rdbcompression
- Yes:开启RDB压缩模式
- no: 关闭,会节约CPU的损耗,但是文件比较大,类比nginx
Rdbchecksum
- Yes:使用CRC64算法对RDB数据进行校对,有10%的性能损耗。
- no:不校验
# AOF模式
RDB可能会丢失最后一部分缓存数据,但是缓存也无所谓,丢了就丢了。但是如果想要追求redis数据的完整性,那么还是会考虑去使用AOF。
# 特点:
- 以日志的形式来记录用户的写操作,读操作不会进行记录。
- 日志文件以追加的形式,而非修改的形式
- Redis的aof恢复其实就是把追加的文件从头到尾进行读取,然后执行写操作。
# 优点:
- AOF更加耐用,可以以秒级别为单位进行备份,如果发生问题,也只是会丢失最后一秒的数据,大大增加了可靠性和数据的完整性。所以AOF可以每秒备份一次,使fsync操作。
- 以log形式追加,如果磁盘满了,会执行redis-check-aof工具。
- 当数据量太大的时候,redis会在后台自动重写aof。当redis继续把日志追加到老的文件中去的时候,重写也是非常安全的,不会影响客户端的读写操作。
- AOF日志包含的所有的写操作,会更新利于redis进行解析恢复。
# 缺点:
- 相同的数据,同一份数据,AOF的数据会比RDB的数据来得大。
- 针对不同的同步机制,AOF会比RDB慢,因为AOF每秒都会备份做写操作,这样相对于rdb来说就略低。每秒备份fsync没有问题,但是如果客户端每一次写入就做一次fsync的话,那么redis的性能就会下降。
- AOF发生过bug,就是数据恢复的时候数据不完整,这样显得AOF就比较脆弱,容易出bug,因为AOF没有RDB这么简单,但是为了防止bug的产生,AOF就不会根据旧的指令去重构,而是根据当时缓存中存在的指令进行重构,这样就更加健壮和可靠了。
# 配置:
AOF默认关闭,yes可以开启
appendonly no
AOF的文件名
appendfilename "append only.aof"
#no:不同步 #everysec:每秒备份,推荐使用 #always:每次操作都会备份,安全并且数据完整,但是慢,性能差
appendfsync everysec
重写的时候是否要同步,no可以保证数据安全
no-appendfsync-on-rewrite no
重写机制:避免文件越来越大,自动优化压缩指令,会fork一个新的进程去完成重写动作,新进程里的内存数据会被重写,此时旧的aof文件不会被读取使用,类似于RDB。当AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m,满足两者则触发重写。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64m
# 到底采用RDB还是AOF呢?
- 如果能接受一段时间缓存丢失,那么可以使用rdb
- 如果你对实时性的数据比较在意,那么就用aof
- 使用RDB和AOF结合一起做持久化,RDB做冷备,可以在不同时期对不同版本做恢复,AOF做热备,保证数据仅仅只有1秒的损失。当AOF破损不可用了,那么在用RDB进行恢复,这样就做到了两者的相互结合,就是说Redis恢复会先加载aof,如果有问题会再加载RDB,这样就达到了冷热备份的目的