Redis持久化
Redis作为键值对内存数据库，在一般情况下出来用户的操作数据都是存在内存中
有点常识的都知道，掉电了，内存数据就没了，裂开
所以需要有持久化机制，存你的数据，在你再成功的启动Redis服务的时候恢复你之前的数据
Redis提供了两种持久化机制：RDB和AOF
RBD
RDB简单理解就是快照，执行RDB的时候，就咔嚓一下把执行那个时刻，Redis内的所有数据全都存下来，生成一个RDB文件，在Redis服务启动时会到相应的目录中找到RDB文件，读取并恢复数据。
在Redis的配置中，RDB是默认开启的，生成的配置文件名为dump.rdb（这些都是Redis配置文件中的默认配置，下面会有介绍）
时效性
看了RDB的描述，容易产生一个问题：持久化是要有时间的，比如有10g的数据，不可能一微秒就存下来，假设可能需要10分钟。那问题来了，这中间10分钟的数据发生了修改怎么办？
答：RDB是时效性的，只存指令执行那个时刻的数据，后面更新的不存。所以在存的过程中，就是上面那十分钟的那个数据，会丢失，这是RDB的机制，也是RDB的一个缺点。
触发RDB
Redis提供了两种方式用来触发RDB，用户指令下发与配置条件触发
save
直接通过在Redis client输出save指令就可以执行RDB持久化 但是save命令是阻塞的，Redis是单线程服务，一旦阻塞，其他的请求就没办法执行 所以最好不要用这个save，至少在生产环境别用
bgsave
还有个指令bgsave，这是一个不阻塞的，在后台执行RDB持久化 bgsave会创建一个子进程，子进程负责持久化，主进程继续处理服务 创建子进程的过程也是会阻塞的，但是一般很快
shutdown
当收到客户端的shutdown指令时，Redis会执行一个save指令。执行完成后关闭服务器。
配置条件触发
# Redis配置文件中关于RDB条件的配置
# 默认情况下
# 900s内至少达到一条写命令
save 900 1
# 900s内至少达到一条写命令
save 300 10
# 900s内至少达到一条写命令
save 60 10000
配置save 900 1的大意是：当900秒内如果发生了1次写指令，就会触发RDB持久化
需要注意的是虽然此处配置文件写的是save，但是真正执行的其实是bgsave
其他配置
# Redis配置文件中关于RDB的相关的其他配置
# 当bgsave快照操作出错时停止写数据到磁盘，这样后面写错做均会失败
stop-writes-on-bgsave-error yes
# 是否压缩rdb文件
rdbcompression yes
# rdb文件的名称
dbfilename redis-6379.rdb
# rdb文件保存目录
dir ~/redis/
原理：fork和cow
前面说到，进行RDB的时候，由于Redis是单线程，为了保证进程能够进行在持久化的同时继续处理其他服务，Redis会创建出一个子进程，由子进程来完成持久化的任务，父进程则继续提供服务。如果此时父进程对数据进行操作，是不会影响子进程的持久化的
这个过程就可以理解成是fork，相当于影分身一个自己出来
那么问题来了：
为什么父进程的操作不会影响copy出来的子进程？难道数据也是一模一样拷贝一份吗？
如果是这样，要是父进程占10G内存，复制一个子进程出来不就总共20G内存了吗？
那不是裂开了。。。
答案当然是否定的，如果是这种方式，虽然却是能做到父进程修改数据，不影响子进程，但是这样做的代价太大了，空间消耗大且时间久
所以就有了COW（copy on write）
当子进程使用父进程已经创建好的数据时发生copy on write即先将相同的地址空间数据拷贝到另外一个地址中，然后再对此变量赋值，这样子进程可以看到父进程的数据，但是在应用程序中修改数据时确无法改变父进程的数据
ok，看不懂。。。
翻译下就是：数据在机器上有个实际的内存地址和空间，然后进程内部有自己的逻辑空间，指针的形式将逻辑空间与内存空间关联起来，那么fork出来之后其实复制的是指针，这样数据其实都是同一份。如果父进程中改了数据，那么会先把原地址的数据copy出来然后创建一个新的区域去存这个数据，然后子进程指针指向这个新地址，然后直接改原地址的那个数据的值，这样就做到了父子进程数据隔离了。
这样操作，既达到了数据隔离，速度还很快，占用的空间也很小。
图解：
当然COW不是完美的
在fork的时候，linux内核会把父进程用的那些内存也设置为只读的（readonly），这样子进程和父进程要是都去读取这些数据是没啥问题的。
但是如果有人要改数据，那就要触发内核的一个页异常中断，中断啊，你想想，咯噔一下，要让cpu知道有人要改这个数据了，然后进行cow，那如果有很多很多要修改，疯狂触发cpu中断，对整体的性能会有很大影响。
不过呢，好在Redis读操作还是较多的，如果出现了很多的写，那么还是会对性能有点点影响的。
AOF
RDB的好处是：速度快
但是坏处很明显：RDB时，fork出来的子进程只会存那个时刻前的数据，RDB过程中的增量数据会丢了
Redis还有另一种持久化方式：AOF（Append Only File）相对于RDB，AOF更侧重数据的实时性，丢的数据少
AOF是以类似日志文件的形式，不停的记录用户的操作，恢复的时候直接读取文件中的操作记录，达到数据恢复的效果，类似于MySQL的binlog
开启与配置
默认情况下，Redis不开启AOF，在配置文件中可以手动开启
# Redis配置文件中关于AOF的启动配置
#开启AOF持久化，默认关闭
appendonly yes
其他配置
# Redis配置文件中关于AOF的其他基础配置
#AOF文件名称（默认）
appendfilename "appendonly.AOF"
#AOF文件存放目录
dir "/data/dbs/Redis/abcd"
重写
对于日志形式的记录普遍都有一个问题，就是面对日益增长的读写量，日志文件的大小也会随着不断地增长
举个例子：Redis服务开了10年，如果没有特殊的处理，AOF文件的大小会一直涨，10T、20T...即便这样存下来了数据，对于数据的恢复也是非常痛苦的，如此大的数据恢复，也需要花费很长时间
所以需要有个机制，既要能保证AOF的优点，且能解决上面说的问题，这就是Redis的重写机制Rewrite
对于Rewrite，Redis随着版本的迭代已经演化出了不同的形式
4.0前
之前的Redis重写是通过删除抵消与合并命令来达到重写的。
举个例子：Redis执行了10年，假设一直都在执行incr命令
incr num 1
incr num 2
incr num 3
incr num 4
incr num 5
incr num 6
...
incr num 100000000000000000000000000000000000000000000000000000000000000
像这种情况，Redis可以直接重写为:
set num 100000000000000000000000000000000000000000000000000000000000000
在进行AOF 重写期间，也会fork一个子进程去进行，而主进程继续接收命令。子进程根据当前的内存快照，对原AOF文件进行扫描，并把新的结果写入一个新的AOF文件（与RDB一样，保证任意时刻文件的完整性）。最后用新的AOF文件替换旧的AOF文件。
那么问题又来了：
上面说了，AOF重写时也是fork出一个子进程，根据当前内存快照进行持久化，那不是和RDB一样了吗
持久化过程中的数据一样会丢失啊？
当然这个问题是有解决方法的，针对这个情况，Redis专门提供了重写缓冲区（aof_rewrite_buff）在AOF重写期间，主进程接收到新的写命令后，不仅会添加到旧的AOF文件，还会添加到重写缓存区。在子进程完成了重写后，会先把重写缓存区的数据添加到新的AOF中，再去替换掉旧的AOF文件。
重写期间还将读写记到老AOF文件中的目的是如果重写过程出现问题，老的AOF文件还能用
重写流程如图：
4.0后
Redis在4.0后使用了新的重写机制，将RDB与AOF两种方式进行了混合
fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。
触发AOF
和RDB一样，AOF也有触发方式
bgrewriteaof
和bgsave类似，在后台执行AOF操作，也会fork子进程进行操作，不阻塞主进程
配置条件触发
# Redis配置文件中关于AOF的重写配置
# 当前AOF文件大小和最后一次重写后的大小之间的比率。如默认100代表当前AOF文件是上次重写的两倍时候才重写。
# 这里的数字是比例，超出了原大小比例的100%，也就是两倍就重写
auto-aof-rewrite-percentage 100
# 只有当AOF文件大小大于该值时候才可能重写，默认是64MB
auto-aof-rewrite-min-size 64mb
策略
涉及到IO的操作，也会有一个非常普遍的问题需要考虑：什么时候我们向文件中写数据？上面已经描述了AOF的原理，Redis的读写操作会追加到AOF文件中，难道每条命令一执行马上就直接写入文件？访问量小的时候还可以，当访问量巨大时，这种方式的文件写入，存在很大的性能问题。
所以Redis的AOF实际写入流程是：当开启AOF后，服务端每执行一次写操作就会把该条命令追加到一个单独的AOF缓冲区的末尾，然后把AOF缓冲区的内容写入AOF文件里
这里需要注意的是此处的AOF缓冲区要和重写时的重写缓存区区分，并非一个概念。
#AOF持久化策略，默认为no
appendfsync no
appendfsync有三个配置项：
- always：这种最极端，每执行一个事件就把AOF缓冲区的内容强制性的写入硬盘上的AOF文件里。
- everysec：每隔一秒才会进行一次文件同步把内存缓冲区里的AOF缓存数据真正写入AOF文件里。
- no：默认系统的缓存区写入磁盘的机制，不做程序强制，数据安全性和完整性差一些。
所以AOF即使丢失了数据，也是可以接受的范围内
修复文件
既然是IO操作，数据在写入文件必然是有一个过程的，假设在写入set num 1，这条指令的过程中，出现了问题，只写入了set num，这样就会导致AOF文件中出现异常的恢复语句，AOF在恢复读取文件时会出错。
针对此情况，Redis提供了一个工具redis-check-aof用于自动检查修复AOF文件中的异常
# 使用很简单
redis-check-aof --fix appendonly.aof
同理，也可用redis-check-rdb工具来修复dump.rdb
数据恢复
Redis中，AOF恢复的优先级最高，如果同时配置了RDB和AOF，会只进行AOF的恢复
如果只配置 RDB，Redis会去配置的dir下面找文件并恢复数据。
