1.redis持久化
1>持久化流程
a) 客户端向服务器写数据
b) 服务器再把数据写到内存中
c) 服务端再调write这个系统调用，写入磁盘（内存缓冲区）
d) 操作系统再把数据从内存缓存区写入磁盘控制器（磁盘缓存区）
e）磁盘控制器把数据写入物理磁盘中
2>两种策略RDB和AOF
<1>RDB（redis data base）是采用快照的方式将数据持久化，指定的时间间隔内，将内存中数据集快照写入磁盘中二进制文件中，默认文件格式为dump.rdb
**主要有三种方法**
a)save的方法，当调用save方法时，客户端将不能向服务器中写数据，redis采用RDB方式将数据以数据集快照方式写入，直到写入完成
b) bgsave的方式，redis服务器fork()一个子进程，专门将数据以RDB的方式写入，阻塞只发生在for()阶段
c)自动化方式，可以在redis.conf配置文件中定义
例如save m n 如果在m秒钟有n修改，则自动调用bgsave
stop-writes-on-bgsave-error 默认为yes在redis发生问题时，不能再向redis写入数据
**优缺点：**
优点：rdb文件文件紧凑，全量，适合备份和容灾，恢复速度比AOF快
生成rdb文件时候，会fork()子进程，主进程不需要做IO操作
缺点：在持久化过程中，发生改变无法被记录，导致恢复数据缺失
<2> AOF
redis每次写操作，都将文件写入AOF文件中，但是为了防止AOF文件过大，有重写机制，利用bgrewriteaof，先将文件写入一个临时文件中，再fork()一个子进程来重写AOF
三种方式
每次修改同步always:每次修改都会写AOF文件，
everyecs:异步操作
no:从不同步
**优缺点**
优点
（1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。（2）AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。
（3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
（4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据
缺点
（1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
（2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的
（3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来
打开App，阅读手记
随时随地看视频
