redis持久化 RDB & AOF

Redis   提供了两种不同形式的持久化方式

• RDB     （Redis   Data Base）
• AOF     （Append   of   File）

 

 

一、RDB

     

     在指定时间间隔内将内存中的数据集快照写入磁盘，恢复时是将快照文件直接读到内存

 

     备份

          单独创建一个子进程来进行持久化，将数据先写到临时文件，在用临时文件替换上次持久化好的文件

 

     保存策略

          save 300 10（在配置文件中有）

 

redis.conf中的设置项

 

 

1.stop-writes-on-bgsave-error yes

     当Redis无法写入磁盘的话，直接关掉Redis的写操作

 

2.rdbcompression yes

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

 

3.rdbchecksum yes

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

 

 

优缺点

 

1.优点

• 节省磁盘空间
• 恢复速度快

 

2.缺点

• 数据较大时，消耗性能
• Redis如果意外挂掉，会丢失最后一次快照后的数据

     

 

 

 

 

 

 

 

二、AOF

 

 

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

     

 

 

    AOF默认不开启，需要手动在配置文件配置

 

 

 

      可以在redis.conf中配置文件名称，默认为 appendonly.aof  

 

 

 

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

 

如遇到AOF文件损坏，可通过      redis-check-aof  --fix  appendonly.aof   进行恢复

 

 

 

 

 

 

     重写      Rewrite

 

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof。

    

 

Redis如何实现重写？

 

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

 

重写时机

 

 

 

 

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,

 

如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，

 

     Redis会对AOF进行重写。

 

 

 

AOF优缺点

 

1.优点

• 备份机制更稳健，丢失数据概率更低。
• 可读的日志文本，通过操作AOF稳健，可以处理误操作。

 

2.缺点

• 比起RDB占用更多的磁盘空间。
• 恢复备份速度要慢。
• 每次读写都同步的话，有一定的性能压力。
• 存在个别Bug，造成恢复不能。

 

为了数据安全，建议两个都启用。

redis集群搭建。