Redis 持久化方式
redis作为nosql也支持良好的持久化方式,这也是备受青睐的原因之一
RDB持久化方式
- 这是一种快照形式的持久化方式,在配置后每隔一段时间都会去对当前redis的数据进行快照
- 优点:快照效率高,占用资源少,恢复数据速度快
- 缺点:
1 快照每隔一段时间更新一次,在宕机后恢复数据,可能到造成部分数据的丢失
2 在事务的执行中如果服务器停机,会导致数据的不一致性 - 有两个Redis命令可以生成RDB文件,一个是SAVE,另一个是BGSAVE,SAVE
1 SAVE 命令在生成快照的时候,会从阻塞主进程,直到快照文件生成完毕
2 BGSAVE 命令在生成快照事,会另起一个子进程进行文件的生成
redis.conf 配置文件
# save ""
save 60 10000 #60秒内如果有超过1000个key被修改则发起保存快照
save 300 10 #300秒内如果有超过10个key被修改则发起保存快照
save 900 1 #900秒内如果有超过1个key被修改则发起保存快照
AOF持久化方式
- 这是一种日志形式的持久化方式,在redis每次进行操作时,redis内部都会另起线程将操作日志写入到aof日志文件中
- 优点:
1 详细的记录的redis的操作日志,保证了数据的完整性
2 即使处理事务当中宕机,也不会影响事务的一致性 - 缺点:由于操作日志过多,很容易导致aof日志文件过大,并且数据恢复回比RDB形式慢很多
- ******AOF默认关闭,开启方法,修改配置文件reds.conf:appendonly yes
##此选项为aof功能的开关,默认为“no”,可以通过“yes”来开启aof功能
##只有在“yes”下,aof重写/文件同步等特性才会生效
appendonly yes
##指定aof文件名称
appendfilename appendonly.aof
##指定aof操作中文件同步策略,有三个合法值:always everysec no,默认为everysec
appendfsync everysec
##在aof-rewrite期间,appendfsync是否暂缓文件同步,"no"表示“不暂缓”,“yes”表示“暂缓”,默认为“no”
no-appendfsync-on-rewrite no
##aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite,默认“64mb”,建议“512mb”
auto-aof-rewrite-min-size 64mb
##相对于“上一次”rewrite,本次rewrite触发时aof文件应该增长的百分比。
##每一次rewrite之后,redis都会记录下此时“新aof”文件的大小(例如A),那么当aof文件增长到A*(1 + p)之后
##触发下一次rewrite,每一次aof记录的添加,都会检测当前aof文件的尺寸。
auto-aof-rewrite-percentage 100
Redis的默认持久化方式
- 默认的持久化方式是RDB
- AOF的持久化形式是默认关闭的
- 在开启AOF的情况下回优先使用AOF进行数据恢复
Redis的建议持久化方式
单机: 可以选择 RDB 和AOF 同时开启
集群: master可以使用AOF ,slave 可以使用RDB
Redis重启后是否会默认恢复数据
redis在重启后会自动恢复数据
Rdeis持久化方式总结
redis两种持久化方式简单的优缺点大致如此, 在实际使用当中也是视情况而定,到底哪种持久化方式更适合项目,希望简单的笔记对大家有帮助~ 欢迎讨论和纠正~