文章目录
1. 什么是Redis持久化？ 2. Redis 的持久化机制是什么？各自的优缺点？ 2.1 RDB（Redis DataBase），快照 2.2 AOF（Append Only File），日志 3. 优缺点是什么？ 4. 如何选择合适的持久化方式 5. Redis持久化数据和缓存怎么做扩容？ 6. Redis 怎么确保 Aof 不丢失 7. Aof 日志是写前还是写后日志 8. AOF为什么要先执行命令再记日志 9. Redis Aof 的风险1. 什么是Redis持久化？
持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。
2. Redis 的持久化机制是什么？各自的优缺点？
Redis 提供两种持久化机制 RDB（默认） 和 AOF 机制。
2.1 RDB（Redis DataBase），快照
RDB是Redis默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为 dump.rdb。通过配置文件中的save参数来定义快照的周期。
优点：
缺点：
数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候)2.2 AOF（Append Only File），日志
AOF持久化(即Append Only File持久化)，则是将Redis执行的每次写命令记录到单独的日志文件中，当重启Redis会重新将持久化的日志中文件恢复数据。
所有的命令行记录以 redis 命令请 求协议的格式完全持久化存储)保存为 aof 文件。
当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。
优点：
appendfsync 属性，有 always，每进行一次 命令操作就记录到 aof 文件中一次。
2、通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
3、AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)
缺点：
1、AOF 文件比 RDB 文件大，且恢复速度慢。 2、数据集大的时候，比 rdb 启动效率低。3. 优缺点是什么？
AOF文件比RDB更新频率高，优先使用AOF还原数据。 AOF比RDB更安全也更大 RDB性能比AOF好 如果两个都配了优先加载AOF4. 如何选择合适的持久化方式
如果极度关心数据安全性，你应该同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入AOF 文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。 如果非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。 如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。 有很多用户都只使用 AOF 持久化，但并不推荐这种方式，因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用 RDB 还可以避免 AOF 程序的 bug 。5. Redis持久化数据和缓存怎么做扩容？
如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。 如果Redis被当做一个持久化存储使用，必须使用固定的 keys-to-nodes 映射关系，节点的数量一旦确定不能变化。否则的话( 即Redis节点需要动态变化的情况 ），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。6. Redis 怎么确保 Aof 不丢失
首先，要 AOF完全不丢失，是不可能的，因为 aof 的写回策略只有三种，always，everySec， no，就算启用的是 always，由于 redis 是写后日志，当数据写入成功的瞬间，redis 实例宕机了，依然会导致 aof 丢失，但是此时，redis 没有响应，所以可以认为 aof 不曾丢失（因为业务没有成功响应）。
7. Aof 日志是写前还是写后日志
说到日志，我们比较熟悉的是数据库的写前日志（Write Ahead Log, WAL），也就是说，在实际写数据前，先把修改的数据记到日志文件中，以便故障时进行恢复。不过，AOF日志正好相反，它是写后日志，“写后”的意思是Redis是先执行命令，把数据写入内存，然后才记录日志。
8. AOF为什么要先执行命令再记日志
要回答这个问题，我们要先知道AOF里记录了什么内容。
传统数据库的日志，例如redo log（重做日志），记录的是修改后的数据，而AOF里记录的是Redis收到的每一条命令，这些命令是以文本形式保存的。
我们以Redis收到“ set testkey testvalue ”命令后记录的日志为例，看看 AOF 日志的内容。其中，“*3”表示当前命令有三个部分，每部分都是由“$+数字”开头，后面紧跟着具体的命令、键或值。这里，“数字”表示这部分中的命令、键或值一共有多少字节。例如，“$3 set”表示这部分有3个字节，也就是“set”命令。
最重要的原因是 Redis 作为一个内存数据库追求极致的性能。
为了避免额外的检查开销，Redis在向AOF里面记录日志的时候，并不会先去对这些命令进行语法检查。所以，如果先记日志再执行命令的话，日志中就有可能记录了错误的命令，Redis在使用日志恢复数据时，就可能会出错。
而写后日志这种方式，就是先让系统执行命令，只有命令能执行成功，才会被记录到日志中，否则，系统就会直接向客户端报错。所以，Redis使用写后日志这一方式的一大好处是，可以避免出现记录错误命令的情况。
除此之外，AOF还有一个好处：它是在命令执行后才记录日志，所以不会阻塞当前的写操作。
9. Redis Aof 的风险
AOF也有两个潜在的风险。
首先，如果刚执行完一个命令，还没有来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险。如果此时Redis是用作缓存，还可以从后端数据库重新读入数据进行恢复，但是，如果Redis是直接用作数据库的话，此时，因为命令没有记入日志，所以就无法用日志进行恢复了。
其次，AOF虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。这是因为，AOF日志也是在主线程中执行的，如果在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行了。
仔细分析的话，你就会发现，这两个风险都是和AOF写回磁盘的时机相关的。这也就意味着，如果我们能够控制一个写命令执行完后AOF日志写回磁盘的时机，这两个风险就解除了。