redis持久化方式:RDB和AOF

RDB（redis database）

1. 什么是RDB？
   因为redis是内存数据库，断电时内存数据会丢失，所以RDB就是redis进行持久化的一个机制，将内存中的数据保存在本地磁盘文件，即dump.rdb。

2. 为什么要使用RBD？
   就像上面所说的进行持久化，重新启动redis时会加载dump.rdb中的数据到内存。

3. 怎么用RDB？
   redis默认启用RDB，redis的配置文件（windows下面是redis.windows.conf）中的SNAPSHOTTING区域会对RBD进行一些配置，比如

格式：save <seconds> <changes>
#   save ""//当你不想启用自动更新的时候，可以放开这里

save 900 1
save 300 10
save 60 10000

意思就是900秒内redis进行了一次更新操作，或者300秒内进行了10次更新操作，60秒内进行了10000次更新操作，那么将会将内存中的数据fork到磁盘中，也就是dump.rdb。
（tips1：解释下这里的fork过程，fork是将redis的主进程完全复制一份，状态，数据什么的都相同，然后子进程将数据复制到dump.rdb中，但是这里就会造成一个问题，假如数据量过大，比如一个班里做了50人坐满了，再来50人，那么redis可能就不行了，在复制期间，主进程是不能进行任何操作的。）

备份过程：

1. Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
2. 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
3. fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

（tips2:文件备份是解决了断电等软件异常，但是假如安装redis的那台服务器坏掉了，数据一样会丢失，因此经常会对dump.rdb文件进行备份，且备份到其他机器上，那么一台机器坏掉启用另一台就好了。）

stop-writes-on-bgsave-error yes

这里提一下bgsave是异步fork数据到磁盘，主进程可以继续执行，和上面的save不同。这个配置见词知意，就是写数据出错了立马停止。

rdbcompression yes

这个是存储数据时压缩一下，会造成CPU的占用。

rdbchecksum yes

对rdb数据进行校验，大概耗费10%CPU。
（tips：10%！？一听是很多，但是数据复制一般是在深夜无人的时候，这时候CPU是空闲的，所以一般够用，这里不用配置成no，优化这点性能不如再买个redis，因为程序员的工作是干不完的，这点不用跟老板客气…）

dbfilename dump.rdb

很明显，就是RDB的文件名。

dir ./

RDB的文件目录，这里是相对目录，和redis.conf在一个目录。

4. 优点
   1. 适合大规模的数据恢复
      2.全量备份、恢复，只备份最后一次.rdb文件
5. 缺点
   1.在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
   2.fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

为了弥补RDB的缺点，诞生了AOF。

AOF(Append Only File)

1. 什么是AOF？
   存储redis写操作指令的文件。
2. 为什么用AOF？
   因为RDB可能丢失数据较多，AOF最坏情况下丢失的数据不超过两秒。
3. 怎么用AOF？
   配置文件的APPEND ONLY MODE模块：

appendonly no					//aof开关，默认是关闭，设置yes打开
appendfilename "appendonly.aof"	//aof文件名
appendfsync everysec				//文件追加方式，有三种：
								1.always 	redis执行一个写命令，aof文件追加一个命令。
								2.everysec  每秒同步一次命令。
								3.no		不同步命令。
no-appendfsync-on-rewrite no		//当rewrite AOF子进程或RDB子进程正在执行时，Server是否支持fsync，即当新修改的数据写入AOF文件后，是否将数据刷新到硬盘，设置为no是最安全的方式，但是会造成阻塞。
官方说明：指定是否在后台aof文件rewrite期间调用fsync，默认为no，表示要调用fsync（无论后台是否有子进程在刷盘）。Redis在后台写RDB文件或重写afo文件期间会存在大量磁盘IO，此时，在某些linux系统中，调用fsync可能会阻塞。

auto-aof-rewrite-percentage 100		//配置重写aof文件的阈值，默认是超过原文件大小的一倍并且超过64mb，必须同时满足两个条件才重写。
auto-aof-rewrite-min-size 64mb
重写：当redis执行命令越来越多，那么aof文件会越来越大，redis会用重写方式将aof一些命令进行压缩（比如，连续对一个数据执行了多个 incr 操作，那么就可以将这些incr操作合成一个set操作），以减小aof文件大小，来减少redis重启时加载aof文件所需时间。
重写原理：AOF文件持续增长而过大时，会fork出一个新进程来重写文件（也是先写临时文件再rename），遍历新进程的内存数据，每条记录有一个set语句。重写AOF的操作，并没有读取旧的AOF文件，而是将整个内存中的数据用命令的方式重写了一个新的aof文件，这点和快照有点相似。

5. 优点
   1.灵活的配置同步方式：可以按修改、秒同步，也可以不同步
6. 缺点
   1.相同的数据集的数据而言aof文件远大于rdb文件，恢复速度慢于rdb
   2.aof运行效率慢于rdb，每秒同步策略较好，不同步效率和rdb相同

下面是带来的问题：

• 两者能同时使用吗？
  可以

• 加载顺序？
  先加载aof，再加载rdb

• 如何选择两种持久化方式？
  官网建议都开启，aof比rdb更全，rdb可以作为一种备用方案。

又为了弥补aof缺点！产生了redis主从复制！
技术的迭代就是如此呀~