Redis持久化方式

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两种持久化方式简单的优缺点大致如此， 在实际使用当中也是视情况而定，到底哪种持久化方式更适合项目，希望简单的笔记对大家有帮助~ 欢迎讨论和纠正~