Redis - 持久化
持久化方式
因为Redis是内存操作，意味着掉电就GG, 所以为了保证异常重启等问题后能尽快恢复服务，还是需要一定的持久化机制来保证。Redis提供了两种持久化机制：
- AOF Append Only File
- RDS Redis Database
AOF
AOF文件记录的命令本身，是写完内存之后再写AOF缓冲区。
落盘机制
- Always 每次 （主进程主线程进行，
fsync阻塞特性导致挂起，吞吐量下降） - EverySec 每秒 （后台I/O线程执行，主线程不会阻塞）
- No 操作系统自己决定
当然了，频次越高，数据越可靠（越不容易丢失）但对性能的影响越大，这其中的trade-off需要根据业务场景具体考虑。
重写机制
为了避免AOF文件过大，Redis会进行AOF重写(因为AOF是记录的命令本身，比如三个set a xxx的命令重写过后就只剩最后一个set命令会减少存储量)。如何确定AOF是否太大，有两个参数控制，auto-aof-rewrite-min-size默认64MB, 和auto-aof-rewrite-percentage即上一次重写后体量的差值。
对AOF的重写是后台线程进行的，当AOF大小超过设定值时，主线程会fork出一个子线程bgrewriteof,（注：fork的过程其实是会阻塞主线程的），然后子线程对AOF进行重写，当新的客户端请求到来时，需要既写新的AOF又写原来的AOF。
RDB
RDB文件保存的是内存快照，也就是实际的内存数据。生成RDB的方式有两种
- save命令，主线程执行
- bgsave 子线程执行，也是Redis默认的配置
快照，就有一个问题，比如我想保存t0时刻的内存快照，我整个保存过程需要5s,如果这5s中，没有任何改变内存数据的客户端请求，那没问题。但是如果有，那如果没有其他机制保证，我的内存快照其实是掺杂了t1,t2等5s内修改了数据的结果。
解决办法也很简单，就像其他数据库一样，我有多个数据“版本”就行了呀，我t1改的数据a,改成a1,两个我都存着。Redis采用的就是操作系统提供的Copy-on-write机制，究其本质就是有多个版本啦。
混合使用AOF,RDB
Redis4.0提出混合使用AOF,RDB来取得性能和可靠性的折中。即两次生成RDB的期间用AOF日志记录这其中的操作。
