1. Redis持久化简介

redis持久化就是把内存中的数据定期的保存到磁盘当中

  • RDB持久化方式会在一个特定的间隔保存那个时间点的一个数据快照。
  • AOF持久化方式则会记录每一个服务器收到的写操作。在服务启动时，这些记录的操作会逐条执行从而重建出原来的数据。写操作命令记录的格式跟Redis协议一致，以追加的方式进行保存。

Redis 提供了多种不同级别的持久化方式：

  1. RDB持久化
  • RDB文件是一个很简洁的单文件，它保存了某个时间点的Redis数据，很适合用于做备份。你可以设定一个时间点对RDB文件进行归档，这样就能在需要的时候很轻易的把数据恢复到不同的版本。
  • 基于上面所描述的特性，RDB很适合用于灾备。单文件很方便就能传输到远程的服务器上。
  • RDB的性能很好，需要进行持久化时，主进程会fork一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的I/O操作。
  • 比起AOF，在数据量比较大的情况下，RDB的启动速度更快。
  • RDB容易造成数据的丢失。假设每5分钟保存一次快照，如果Redis因为某些原因不能正常工作，那么从上次产生快照到Redis出现问题这段时间的数据就会丢失了。
  • RDB使用fork()产生子进程进行数据的持久化，如果数据比较大的话可能就会花费点时间，造成Redis停止服务几毫秒。如果数据量很大且CPU性能不是很好的时候，停止服务的时间甚至会到1秒。
  1. AOF
  • 比RDB可靠。你可以制定不同的fsync策略：不进行fsync、每秒fsync一次和每次查询进行fsync。默认是每秒fsync一次。这意味着你最多丢失一秒钟的数据。
  • AOF日志文件是一个纯追加的文件。就算是遇到突然停电的情况，也不会出现日志的定位或者损坏问题。甚至如果因为某些原因（例如磁盘满了）命令只写了一半到日志文件里，我们也可以用redis-check-aof这个工具很简单的进行修复。
  • 当AOF文件太大时，Redis会自动在后台进行重写。重写很安全，因为重写是在一个新的文件上进行，同时Redis会继续往旧的文件追加数据。新文件上会写入能重建当前数据集的最小操作命令的集合。当新文件重写完，Redis会把新旧文件进行切换，然后开始把数据写到新文件上。
  • AOF把操作命令以简单易懂的格式一条接一条的保存在文件里，很容易导出来用于恢复数据。例如我们不小心用FLUSHALL命令把所有数据刷掉了，只要文件没有被重写，我们可以把服务停掉，把最后那条命令删掉，然后重启服务，这样就能把被刷掉的数据恢复回来。
  • 在相同的数据集下，AOF文件的大小一般会比RDB文件大。
  • 在某些fsync策略下，AOF的速度会比RDB慢。通常fsync设置为每秒一次就能获得比较高的性能，而在禁止fsync的情况下速度可以达到RDB的水平。
  • 在过去曾经发现一些很罕见的BUG导致使用AOF重建的数据跟原数据不一致的问题。

面试： redis 持久化方式有哪些？有什么区别？ rdb：基于快照的持久化，速度更快，一般用作备份，主从复制也是依赖于rdb持久化功能 aof：以追加的方式记录redis操作日志的文件。可以最大程度的保证redis数据安全，类似于mysql的binlog

RDB和AOF，应该选用那一个？
一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免 AOF 程序的 bug 。

2. Redis持久化之RDB

触发持久化可以直接进入到redis-ctl，使用save命令，来触发，但是在生产环境中，每次都要人为的这么操作，就非常不人性化，所以redis也提供了一些配置参数，用于自动实现持久化

1.文件路径名

  1. //文件存放的目录，AOF文件同样存放在此目录下（默认为当前工作目录）
  2. dir /data/6379  
  4. //RDB文件名，默认为dump.rdb
  5. dbfilename dump.rdb

2.保存点
使Redis如果在每N秒后数据发生了M次改变就保存快照文件。例如下面这个保存点配置表示每60秒，如果数据发生了1000次以上的变动，Redis就会自动保存快照文件

  1. save 60 1000

保存点可以有多个（Redis的配置文件就默认设置了3个保存点）

  1. save 900 1  #900秒后至少有1个key更改
  2. save 300 10 #300秒后至少有10个key更改
  3. save 60 10000 #60秒后至少有10000个key更改

3.错误处理
默认情况下，如果Redis在后台生成快照的时候失败，那么就会停止接收数据，目的是让用户能知道数据没有持久化成功。但是如果你有其他的方式可以监控到Redis及其持久化的状态，那么可以把这个功能禁止掉

  1. stop-writes-on-bgsave-error [yes|no]

4.数据压缩
默认Redis会采用LZF对数据进行压缩。如果你想节省点CPU的性能，你可以把压缩功能禁用掉，但是数据集就会比没压缩的时候要大。

  1. rdbcompression [yes|no]

5.错误校验
从版本5的RDB的开始，一个CRC64的校验码会放在文件的末尾。这样更能保证文件的完整性，但是在保存或者加载文件时会损失一定的性能（大概10%）。如果想追求更高的性能，可以把它禁用掉，这样文件在写入校验码时会用0替代，加载的时候看到0就会直接跳过校验

  1. rdbchecksum [yes|no]

实践RBD
1.修改redis配置文件，添加以下参数

  1. # vim /application/redis-6379/redis.conf
  2. dir "/application/redis-6379"
  3. dbfilename "dump.rdb"
  4. save 900 1
  5. save 300 10
  6. save 60 10000

2.重启redis服务

  1. # redis-cli -a xmh123 shutdown
  2. # redis-server /application/redis-6379redis.conf 
  3. # tree /application/redis-6379
  4. /application/redis-6379
  5. ├── dump.rdb   #当有数据写入触发save的时候就生成dump.rdb文件
  6. ├── redis.conf
  7. └── redis.log

3. Redis持久化之AOF

1.启用AOF
把配置项appendonly设为yes

  1. appendonly yes

2.文件路径和名称

  1. //文件存放目录，与RDB共用。默认为当前工作目录
  2. dir "/application/redis-6379"
  4. //默认文件名为appendonly.aof
  5. appendfilename "appendonly.aof"

3.可靠性
配置Redis调用fsync的频率，有三个选项：

  1. 每当有新命令追加到AOF的时候调用fsync。速度最慢，但是最安全。
  1. 每当有新命令追加到AOF的时候调用fsync。速度最慢，但是最安全。
  2. 从不fsync，交由系统去处理。这个方式速度最快，但是安全性一般。

推荐使用每秒fsync一次的方式（默认的方式），因为它速度快，安全性也不错。相关配置如下：

  1. appendfsync always   # 每1个命令，都立即同步到aof
  2. appendfsync everysec   # 每秒写1次
  3. appendfsync no       # 不做持久化，写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof

实践AOF
1.修改redis配置文件，添加以下参数

  1. # vim /application/redis-6379/redis.conf
  2. dir "/application/redis-6379"
  3. appendfilename "appendonly.aof"
  4. appendonly yes
  5. appendfsync everysec

2.重启redis服务

  1. # redis-cli -a xmh123 shutdown
  2. # redis-server  /application/redis-6379/redis.conf 
  3. # tree /application/redis-6379
  4. /application/redis-6379
  5. ├── dump.rdb
  6. ├── appendonly.aof  #重启完后，会创建appendonly.aof持久化文件
  7. ├── redis.conf
  8. └── redis.log

4. Redis备份

建议的备份方法：

  • 创建一个定时任务，每小时和每天创建一个快照，保存在不同的文件夹里。
  • 定时任务运行时，把太旧的文件进行删除。例如只保留48小时的按小时创建的快照和一到两个月的按天创建的快照。
  • 每天确保一次把快照文件传输到数据中心外的地方进行保存，至少不能保存在Redis服务所在的服务器。