世界上并没有完美的程序,但我们并不因此而沮丧,因为写程序本来就是一个不断追求完美的过程。 ——摘自周志明

Redis持久化

提供了两种方式:

  RDB(Redis DataBase)和AOF(Append Of file)

RDB


 

RDB就是:在指定的时间间隔内将内存中的数据集快照写入磁盘(Snapshot快照),等到恢复时,将快照文件直接读到内存中。

rdb保存的文件

  在redis.conf配置文件中(文件保存的名字,保存的位置,默认redis启动时命令行所在的目录)

    

  rdb 保存策略

    

  stop-writes-on-bgsave-error   yes

    当redis无法写入磁盘的话,直接关掉redis的写操作。

  rdbcompresssion  yes

    进行rdb保存时,将文件压缩

  rdbchecksum  yes

    在存储快照后,还可以让Redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能

rdb的备份

  》先通过config get dir 查询rdb存放的位置

  》将*.rdb的文件拷贝到别的地方

rdb的恢复

  》关闭redis

  》先把备份的文件拷贝到工作目录下

  》启动redis,备份数据会自动的加载

rdb的优缺点

  优点:节省磁盘空间;由于存储的是计算过得数据,所以恢复起来快

  缺点:

    》虽然redis采用在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能的

    》在备份机制是每隔一段时间,触发备份机制,就会自动备份。所以如果在redis意外down掉的话,就会丢失最后一次快照之后的所有修改。

AOF


 

  以日志的形式来记录每个操作;将redis执行的所有的写指令记录下来(读操作不记录)。只许追加文件但不可以改写文件,redis启动之初会读取文件重新构建数据,换句话说,redis重启的话就根据日志文件的内容将写指令从前到后执行一次已完成数据的恢复工作。

AOF默认时不开启的,需要手动设置

  

AOF和rdb同时开启,redis听谁的?

  系统默认取AOF的数据。

AOF文件故障备份还原

  拷贝备份文件到redis工作目录下,启动redis会自动加载。

AOF文件故障恢复

  AOF文件保存路径,同RDB的路径一致。

  如果遇到AOF文件损坏,则可以通过

    redis-check-aof --fix appendonly.aof    进行恢复

AOF同步频率设置

  

  》每次写入数据,都会立刻同步  安全性最好,性能最差

  》每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失。

  》不主动进行同步,把同步时机交给操作系统。

Rewrite机制

  AOF采用文件追加方式,文件会越来越大,为了解决文件太大的问题。所以新增重写机制,当AOF文件的大小超过所设定的阀值时,redis就会压缩aof文件,只保留最小指令集,可以使用bgrewriteaof。

 AOF的优缺点

  优点:

    备份机制更稳健,丢失数据概率更低。

    可读的日志文本,通过操作AOF,可以处理误操作。

  缺点:

    比起rdb占用更多的磁盘空间

    恢复备份速度慢

    每次读写都同步,会有一定的性能压力

    存在个别bug,造成恢复不能,官方说的,但是没有遇见过。

AOF和RDB该选哪个?

  》官方推荐两个都启用

  》如果对数据不敏感,可以单独选用RDB

  》不建议单独用AOF,因为可能出现bug

  》如果只做内存缓存,可以都不用

  

 

posted @ 2018-12-23 20:10  白杯与咖啡  阅读(173)  评论(0编辑  收藏  举报