//来源[01,05]分布式缓存
除了黑马，还参考了别的。

1.单点redis问题及解决方案

数据丢失问题：实现redis数据持久化
并发能力问题：搭建主从集群，实现读写分离
故障恢复问题：利用Redis哨兵，实现健康检测和自动恢复
存储能力问题：搭建分片集群，利用插槽机制进行动态扩容

2.为什么需要持久化？

Redis是个基于内存的数据库。服务一旦宕机，内存中的数据将全部丢失。
通常的解决方案是从后端数据库恢复这些数据，但后端数据库有性能瓶颈，如果是大数据量的恢复，1、会对数据库带来巨大的压力，2、数据库的性能不如Redis。导致程序响应慢。
所以对Redis来说，实现数据的持久化，避免从后端数据库中恢复数据，是至关重要的。

3.Redis持久化有哪些方式呢？为什么我们需要重点学RDB和AOF？

从严格意义上说，Redis服务提供四种持久化存储方案：RDB、AOF、虚拟内存（VM）和　DISK STORE。但目前官方明确支持的只有前两种方案。

4.RDB

4.1 定义

RDB：redis数据备份文件，redis数据快照。
把内存中的所有数据都记录到磁盘中，当redis实例故障重启后，从磁盘中读取快照文件，恢复数据。
快照文件称为RDB文件，默认是保存在当前运行目录。再次启动时自动读取rdb文件。

4.2 触发方式

4.2.1手动触发save

save命令：由redis主进程执行rdb，会阻塞所有进程。
默认是服务停止时才会执行。

4.2.2被动触发bgsave

开启子进程后台执行rdb，避免影响主进程。

配置

在redis.conf配置文件中写：save x y (在x秒内，如果至少有y个key被修改，则执行bgsave)；
如果是save ”"则表示禁用rdb。

配置文件中也可以配置rdb的其他配置。

bgsave的流程

bgsave开始时，fork主进程得到子进程，子进程共享主进程的内存，完成fork后读取内存数据并写入rdb文件（替换旧的rdb）。
共享：子进程拷贝主进程的页表，子进程操作自己的虚拟内存时，映射到跟主进程相同的物理内存区域。只有fork时，需要对主进程阻塞（拷贝虚拟页表）。

如果子进程读取数据时，主进程在修改数据怎么办？
fork采用的是copy-on-write技术。主进程要写一块数据时，拷贝一份原数据的副本，子进程读取副本数据，同时主进程可以在原来的数据上写。
极端情况下，所有数据都要修改，都有拷贝，占用极大的内存。

什么时候会执行bgsave？

在快照时服务崩溃怎么办？

在快照操作过程中不能影响上一次的备份数据。Redis服务会在磁盘上创建一个临时文件进行数据操作，待操作成功后才会用这个临时文件替换掉上一次的备份。

4.3 rdb的缺点

RDB方式实时性不够，无法做到秒级的持久化（只能恢复快照之前的数据）；
每次调用bgsave都需要fork子进程，fork子进程属于重量级操作，频繁执行成本较高；

4.4 rdb的优点

快照使用的算法大大压缩了文件大小，用于备份、全量复制等场景；
Redis加载RDB文件恢复数据要远远快于AOF方式；

5.AOF持久化

5.1定义

Append only file（追加文件）。Redis处理的每一个写命令都会追加在aof文件，可以看作是命令的日志文件。恢复时读取aof的命令并执行。

5.2 配置

在配置文件中开启

先写到缓冲区，缓冲区在内存中，到时候再写到磁盘中。

5.3 为了解决AOF文件体积膨胀的问题，Redis提供AOF文件重写机制

因为记录命令，所以aof文件比rdb大很多。
执行bg rewrite aof，消除冗余命令，用最少的命令完成一样的效果。比如对同一个key的多次写，只有最后一次写是有意义的。

执行过程：AOF重写过程是由后台子进程完成的。主线程fork出后台的bgrewriteaof子进程，bgrewriteaof子进程拷贝一份主进程的内存，这里包含了最新数据。然后，bgrewriteaof子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。

6.RDB和AOF对比

总结：rdb文件体积小，启动快，数据不完整，占用资源多。

7.RDB和AOF混合方式

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。
简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

8.两者都有时，如何从持久化中恢复数据？

优先加载aof。因为AOF保存的数据更完整。