Redis中的持久化操作：RDB和AOF

1.1: RDB（Redis DataBase）方式

1)	在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
2)	备份是如何执行的
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
3) Fork
Fork的作用就是复制一个与当前进程一样的进程。新进程的所有数据(变量，环境变量，程序计数器等)数值与原进程一致，但是一个全新的进程，并作为原进程的子进程。在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”，一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。
4)	RDB的备份与恢复
  备份: 先通过config get dir查询rdb文件的目录, 将*.rdb的文件拷贝到别的地方。
  恢复: 关闭Redis，把备份的文件拷贝到工作目录下, 启动redis, 备份数据会直接加载。
5)	RDB的优缺点
	优点: 适合大规模的数据恢复。对数据完整性和一致性要求不高更适合使用。节省磁盘空间。恢复速度快。
	缺点: 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能，大约2倍的膨胀性，需要考虑。在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

rdb文件默认保存位置：为Redis启动时命令行所在的目录下。在redis.conf中配置文件名称，默认为dump.rdb。
redis.conf中的配置：
1: 指定rdb文件的名称
 482 # The filename where to dump the DB
 483 dbfilename dump.rdb
2: 指定rdb文件生成的位置
 505 # Note that you must specify a directory here, not a file name.
 506 dir /usr/local/var/db/redis/
3: 指定文件持久化操作的规则
 428 # Unless specified otherwise, by default Redis will save the DB:
 429 #   * After 3600 seconds (an hour) if at least 1 change was performed
 					(3600秒也就是一小时以内有一个key改变，则进行持久化操作)
 430 #   * After 300 seconds (5 minutes) if at least 100 changes were performed
 					(在300秒内也就是5分钟内有100个key发生改变，则进行持久化操作)
 431 #   * After 60 seconds if at least 10000 changes were performed
 					(在60秒内也就是1分钟内有10000个key发生改变，则进行持久化操作)
 432 #
 433 # You can set these explicitly by uncommenting the following line.
 434 #
 435 # save 3600 1 300 100 60 10000
当你设置30秒内10个key改变时，进行持久化操作。如果你30秒内12个key发生了变化，则他持久化时只持久化1到10，从第11开始继续记录如果30秒内10个key改变时，在再进行一次持久化操作。
4:	手动保存快照
  save: 只管保存，其它不管，全部阻塞
  bgsave:按照保存策略自动保存
5:	RDB的相关配置
  stop-writes-on-bgsave-error yes
  当Redis无法写入磁盘的话（磁盘满了），直接关掉Redis的写操作。
  rdbcompression yes
  进行rdb保存时，对于存储到磁盘中的快照，可以设置是否进行压缩存储，如果是的话，redis会采用LZF算法将文件压缩。推荐yes
  rdbchecksum yes
  在存储快照后，还可以让Redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。推荐yes

1.2: AOF（Append Of File）方式

追加操作日志的方式。
1)以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
默认不开启的。
2)AOF默认不开启，需要手动在配置文件中配置
  # Please check https://redis.io/topics/persistence for more information.
  appendonly no
3)可以在redis.conf中配置文件名称，默认为 appendonly.aof
  # - appendonly.aof.1.base.rdb as a base file.
  # - appendonly.aof.1.incr.aof, appendonly.aof.2.incr.aof as incremental files.
  # - appendonly.aof.manifest as a manifest file.
  appendfilename "appendonly.aof"
	AOF文件的保存路径，同RDB的路径一致。
4)AOF和RDB同时开启，redis听谁的？
	AOF和RDB同时开启，系统默认取AOF的数据(数据不会丢失)。
5)AOF文件故障备份
	AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。
6)AOF文件故障恢复
  如遇到AOF文件损坏，可通过
  redis-check-aof  --fix  appendonly.aof   进行恢复
7)AOF同步频率设置
  appendfsync always
  始终同步，每次Redis的写入都会立刻记入日志，性能较差但是数据完整性比较好。
  appendfsync everysec(默认的)
  每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
  appendfsync no
  redis不主动进行同步，把同步时机交给操作系统。
8)Rewrite压缩
	AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof。
	Redis如何实现重写：
  AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
	何时重写：
	重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。
	# Specify a percentage of zero in order to disable the automatic AOF
  # rewrite feature.
  auto-aof-rewrite-percentage 100 （设置重写的基准值，文件达到100%时开始重写，文件是原来的重写后文件的2倍128MB时触发）
  auto-aof-rewrite-min-size 64mb	（设置重写的基准值，最小文件64mb，达到这个值进行重写）
	系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,
	如果Redis的AOF当前大小>=base_size+base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。
9)	AOF的优缺点
  优点:
    备份机制更稳健，丢失数据概率更低。
    可读的日志文本，通过操作AOF稳健，可以处理误操作。
  缺点:
    比起RDB占用更多的磁盘空间
    恢复备份速度要慢
    每次读写都同步的话，有一定的性能压力。

AOF的持久化流程：
（1）客户端的请求写命令会被append追加到AOF缓冲区内；
（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

1.3: RDB和AOF 用哪个好

官方推荐两个都启用。
如果对数据不敏感，可以选单独用RDB
不建议单独用 AOF，因为可能会出现Bug。
如果只是做纯内存缓存，可以都不用。