（一）redis的持久化机制

redis持久化的意义

redis的数据存储在内存中，如果没有持久化的话，redis遇到灾难性故障的时候，就会丢失所有的数据，即使重启redis，没有数据恢复的情况下，就有可能发生缓存雪崩的问题，从而导致系统数据库压力过大，甚至宕机，导致服务不可用。
如果通过持久化一份儿数据放在磁盘上，然后定期比如说同步和备份到一些云存储服务上去，那么就可以保证数据不丢失全部，还是可以恢复一部分数据回来的

redis持久化机制

redis有两种持久化机制，一种RDB，另一种AOF

1. RDB
   对redis中的数据进行周期性的持久化，根据设定的时间定时生成一份redis内存中完整数据的快照。

RDB持久化机制的工作流程
（1）redis根据配置自己尝试去生成rdb快照文件
（2）fork一个子进程出来
（3）子进程尝试将数据dump到临时的rdb快照文件中
（4）完成rdb快照文件的生成之后，就替换之前的旧的快照文件
2. AOF
以每条写入命令作为日志，以append-only的方式写入一个日志文件中，在redis重启的时候，通过回放AOF日志文件中的写入指令来构建整个数据集。

AOF的ReWrite机制。由于redis内存大小是有限制的，redis内存在达到上限时会通过LRU缓存清除算法，将不经常使用的数据从内存中删除，给新的数据腾出储存空间，但是AOF文件是存放写命令的，随着redis数据的写入，会变得越来越大，当达到一定大小时，redis会基于当前内存中的数据生成一个新的AOF日志文件，新的写入命令会存放在新的，体积更小的新文件中。

通过RDB或AOF，都可以将redis内存中的数据给持久化到磁盘上面来，然后可以将这些数据备份到别的地方去，比如说阿里云，云服务。
如果redis挂了，服务器上的内存和磁盘上的数据都丢了，可以从云服务上拷贝回来之前的数据，放到指定的目录中，然后重新启动redis，redis就会自动根据持久化数据文件中的数据，去恢复内存中的数据，继续对外提供服务。
如果同时使用RDB和AOF两种持久化机制，那么在redis重启的时候，会使用AOF来重新构建数据，因为AOF中的数据更加完整。

两种持久化机制的优缺点

RDB的优点

1. RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis中的完整数据，非常适合做冷备份。
2. RDB对redis对外提供读写服务的时候，影像非常小，因为redis 主进程只需要fork一个子进程出来，让子进程对磁盘io来进行rdb持久化
3. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB的缺点

1. 如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据
2. RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒

AOF的优点

1. AOF可以更好的保护数据不丢失，一般AOF会以每隔1秒，通过后台的一个线程去执行一次fsync操作，如果redis进程挂掉，最多丢失1秒的数据。
2. AOF以appen-only的模式写入，所以没有任何磁盘寻址的开销，写入性能非常高。
3. AOF日志文件的命令通过非常可读的方式进行记录，这个非常适合做灾难性的误删除紧急恢复，如果某人不小心用flushall命令清空了所有数据，只要这个时候还没有执行rewrite，那么就可以将日志文件中的flushall删除，进行恢复。

AOF的缺点

1. 对于同一份文件AOF文件比RDB数据快照要大。
2. AOF开启后支持写的QPS会比RDB支持的写的QPS低，因为AOF一般会配置成每秒fsync操作，即使每秒一次fsync，redis性能也还是很高的。
3. 数据恢复比较慢，不适合做冷备。

RDB和AOF到底如何选择

1. 不要仅仅使用RDB这样会丢失很多数据。
2. 也不要仅仅使用AOF，因为这一会有两个问题，第一通过AOF做冷备没有RDB做冷备恢复的速度快；第二RDB每次简单粗暴生成数据快照，更加健壮。
3. 综合AOF和RDB两种持久化方式，用AOF来保证数据不丢失，作为恢复数据的第一选择；用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，可以使用RDB进行快速的数据恢复。

如何配置RDB持久化

在配置文件redis.conf配置

save <seconds> <changes>

意思为每秒，如果有超过个key变化，就生成一次rdb快照，可设置多个save。
其他SNAPSHOTTING配置按需修改，一般默认就可以。

如何配置AOF持久化

AOF持久化，默认是关闭的，默认是打开RDB持久化
appendonly yes，可以打开AOF持久化机制，在生产环境里面，一般来说AOF都是要打开的。
appendfsync everysec，配置成everysec。
everysec：每秒将os cache中的数据fsync到磁盘，这个最常用的，生产环境一般都这么配置，性能很高，QPS还是可以上万的.
always：每次写入一条数据，立即将这个数据对应的写日志fsync到磁盘上去，性能非常非常差，吞吐量很低; 确保说redis里的数据一条都不丢，那就只能这样了。
no：redis仅负责将数据写入os cache就撒手不管了，然后后面os自己会时不时有自己的策略将数据刷入磁盘，不可控了。
rewrite配置，主要配置下面两个参数，其余默认就可以

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

比如说上一次AOF rewrite之后，是128mb
然后就会接着128mb继续写AOF的日志，如果发现增长的比例，超过了之前的100%，256mb，就可能会去触发一次rewrite。

AOF破损文件的修复

如果redis在append数据到AOF文件时，机器宕机了，可能会导致AOF文件破损
用redis-check-aof --fix命令来修复破损的AOF文件

AOF和RDB同时工作

1. 如果RDB在执行snapshotting操作，那么redis不会执行AOF rewrite; 如果redis再执行AOF rewrite，那么就不会执行RDB snapshotting
2. 如果RDB在执行snapshotting，此时用户执行BGREWRITEAOF命令，那么等RDB快照生成之后，才会去执行AOF rewrite
3. 同时有RDB snapshot文件和AOF日志文件，那么redis重启的时候，会优先使用AOF进行数据恢复，因为其中的日志更完整