Redis 是内存数据库，但是它为数据的持久化提供了两个技术------ 「 AOF 日志和 RDB 快照 」
- AOF 文件的内容是操作命令；
- RDB 文件的内容是二进制数据。
文章目录
配置
这里可以配置对外 ip，外界才能连接：
bind 0.0.0.0 ::1持久化
AOF 持久化
Append Only File
把所有执行过的语句写入文件。
默认不开启，在配置文件一半的位置可以修改：
写回内容解读：
*3 当前命令有三部分
$3 每部分的长度 （字节）：3 set 4 name $7 aaaaaaa
redis 写回逻辑
- redis 执行完命令后，会将命令追加到 server.aof_buf 缓冲区；
- 通过系统调用 write() ，将缓冲区数据写入AOF文件。（write 会先把数据拷贝到 内核缓冲区 page cache，等待内核写入）
三种写回策略
- Always：每次
- Everysec：每秒
- No：不自动写回
底层是在控制 fsync() 函数调用时机
AOF 重写机制
压缩 AOF 文件
当AOF 文件的大小超过所设定的阈值后，Redis 就会启用 AOF 重写机制
为什么能重写呢？像两个 set 语句，第二个会覆盖第一个，那第一个就不用再执行了。
AOF的重写机制是： 在重写时，读取当前数据库中的所有键值对，然后将每一个键值对用一条命令记录到「新的 AOF 文件」，等到全部记录完后，就将新的 AOF 文件替换掉现有的 AOF 文件。
以上重写是由子进程完成的：
写AOF日志一般是在主进程中完成，写入内容并不多。
如果AOF文件大于64M，就会触发对AOF的重写，重写比较耗时，是由后台子进程来完成的。
这样不会阻塞主进程。而且子进程有相同的数据（fork；写时拷贝），如果用线程，就得有加锁保证数据安全等操作。
--
当子进程写时，主进程可能又修改值了：主进程会正常执行，会把该写命令追加到 【AOF 缓冲区】和【AOF重写缓冲区】
子进程重写完后通过信号告知主进程，此时主进程把AOF重写缓冲区内容追加到新的AOF文件，然后覆盖现有AOF文件
RDB 快照
我们关掉 Redis内存数据库，下次打开数据仍在。
RDB 快照就是记录某一个瞬间的所有内存数据，记录的是实际数据。而AOF是命令操作日志。
因此在 Redis 恢复数据时， RDB 恢复数据的效率会比 AOF 高些。
save bgsave 命令可以生成 RDB 文件，主线程/子进程生成。
RDB 文件的加载工作是在服务器启动时自动执行的，Redis 并没有提供专门用于加载 RDB文件的命令。
Redis会自动执行 bgsave
配置文件可以自定义：
save 900 1
save 300 10
save 60 10000（实际执行的都是 bgsave）
意思是 多少秒过后，这期间对数据库做了至少多少次修改，就执行。
如 900s内，执行了1次修改，900s结束时，就会执行 bgsave。
由于 RDB快照 会对所有数据都去记录，因此执行消耗大，且故障时会丢失更多数据。
且 生成 RDB快照时，后续的修改是没有被记录的。
混合持久化
Redis 4.0 提出的，该方法叫混合使用 AOF 日志和内存快照，也叫混合持久化。
使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据（即生成RDB时主线程又有的新操作）。
配置：
aof-use-rdb-preamble yes