Redis面临的数据安全问题
Redis是一个缓存中间件，它的最大特点是使用内存从而使其性能强悍。但是使用内存的方式有一个致命的特点就是数据没办法持久化保存。然而Redis持久化存储有两种持久化方案，RDB(Redis DataBase)和 AOF(Append-Only File)。其中RDB是将内存中的数据进行快照存储到磁盘，AOF则为可回放的命令日志记录redis内的所有操作。它们各有特点也相互独立。Redis4之后支持RDB-AOF混合持久化的方式，结合了两者的优点，可以通过 aof-use-rdb-preamble 配置项可以打开混合开关。RDB：快照持久化
一、原理
RDB(Redis DataBase)是将Redis内存中的数据进行Snaptshot快照存储在磁盘内，是Redis的默认持久化方案。使用RDB持久化默认有三种策略，该持久化策略在redis.conf中可配置，会以一段时间内有指定次数据修改的规则触发快照动作，快照文件名为dump.rdb，该文件默认使用LZF压缩算法 。每当Redis服务重启的时候会从该文件中加载数据进内存。二、save和bgsave
RDB持久化除了可以根据配置中的策略触发，也可以手动触发，使用save和bgsave命令即可。这两个命令的区别的save会阻塞服务器进程，在进行save的过程中，服务器不能处理任何请求，而bgsave会通过一个子进程在后台处理rdb持久化。事实上save和bgsave调用的都是rdbSave函数，因此Redis不允许save和bgsave同时运行，这也是为了避免出现竞争导致rdb文件数据不准确。 bgsave操作使用CopyOnWrite机制进行写时复制，是由一个子进程将内存中的最新数据遍历写入临时文件，此时父进程仍旧处理客户端的操作，当子进程操作完毕后再将该临时文件重命名为dump.rdb替换掉原来的dump.rdb文件，因此无论bgsave是否成功，dump.rdb都不会受到影响。 另外在主从全量同步、debug reload以及shutdown的情况下也会触发RDB数据持久化。1、save原理图
2、bgsave原理图
3、save与bgsave对比
| 命令 | save | bgsave |
|---|---|---|
| IO类型 | 同步 | 异步 |
| 是否阻塞 | 是 | 否（阻塞发生在fork） |
| 有点 | 不会消耗额外内存 | 不阻塞客户端命令 |
| 缺点 | 阻塞客户端命令 | 创建fork，消耗内存 |
三、RDB优点
1、及时点紧凑文件，适用于备份
RDB是一种表示某个即时点的Redis数据的紧凑文件。RDB文件适合用于备份。例如，你可能想要每小时归档最近24小时的RDB文件，每天保存近30天的RDB快照。这允许你很容易的恢复不同版本的数据集以容灾。2、适合灾备恢复，可远程传输
RDB非常适合于灾难恢复，作为一个紧凑的单一文件，可以被传输到远程的数据中心。3、子进程进行复制任务，不影响父进程
RDB最大化了Redis的性能，因为Redis父进程持久化时唯一需要做的是启动(fork)一个子进程，由子进程完成所有剩余工作。父进程实例不需要执行像磁盘IO这样的操作。4、数据保存读写快
RDB在重启保存了大数据集的实例时比AOF要快。四、RDB缺点
1、容易数据丢失
当你需要在Redis停止工作(例如停电)时最小化数据丢失，RDB可能不太好。你可以配置不同的保存点(save point)来保存RDB文件(例如，至少5分钟和对数据集100次写之后，但是你可以有多个保存点)。然而，你通常每隔5分钟或更久创建一个RDB快照，所以一旦Redis因为任何原因没有正确关闭而停止工作，你就得做好最近几分钟数据丢失的准备了。2、大数据量RDB导致服务停止几秒
RDB需要经常调用fork()子进程来持久化到磁盘。如果数据集很大的话，fork()比较耗时，结果就是，当数据集非常大并且CPU性能不够强大的话，Redis会停止服务客户端几毫秒甚至一秒。AOF也需要fork()，但是你可以调整多久频率重写日志而不会有损(trade-off)持久性(durability)。总结
优点：速度快，适合于用作备份，主从复制也是基于RDB持久化功能实现的。
缺点：会有数据丢失、导致服务停止几秒五、RDB相关配置
1、RDB触发机制
# 格式：save <seconds> <changes>
# save "" #关闭该规则
save 900 1 #900秒内至少有1个key被改变则做一次快照
save 300 10 #300秒内至少有300个key被改变则做一次快照
save 60 10000 #300秒内至少有300个key被改变则做一次快照2、设置持久化文件名
dbfilename dump.rdb
#rdb持久化存储数据库文件名，默认为dump.rdb3、bgsave出错时动作
stop-write-on-bgsave-error yes
#yes代表当使用bgsave命令持久化出错时候停止写RDB快照文件,no表明忽略错误继续写文件。4、RDB文件检查
rdbchecksum yes
#在写入文件和读取文件时是否开启rdb文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。5、RDB文件存放目录
dir "/etc/redis"
#数据文件存放目录，rdb快照文件和aof文件都会存放至该目录，请确保有写权限6、RDB压缩
rdbcompression yes
#是否开启RDB文件压缩，该功能可以节约磁盘空间六、RDB相关操作
1、停止备份
在配置文件中就设置save ""或在命令行中 config set save ""。2、手动开始备份
save：会立即生成dump.rdb，但是会阻塞往redis内存中写入数据。
bgsave：后台异步备份。如果是使用flushdb命令，会把之前的快照更新成当前的空状态，所以执行了flushdb后更新的快照是没有数据的。
AOF (append-only log file)
一、原理（可以理解为数据库binlog）
AOF(Append-Only File)记录Redis中每次的写命令，类似mysql中的binlog，服务重启时会重新执行AOF中的命令将数据恢复到内存中，RDB(按策略持久化)持久化方式记录的粒度不如AOF(记录每条写命令)，因此很多生产环境都是开启AOF持久化。AOF中记录了操作和数据，在日志文件中追加完成后才会将内存中的数据进行变更。二、过程
1. 客户端的请求写命令会被append追加到AOF缓冲区内；
2. AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
3. AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
4. Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；三、AOF相关配置
开启了AOF之后，RDB就默认不使用了。使用下面的配置开启AOF以及策略。(如果使用AOF，推荐选择always方式持久化，否则在高并发场景下，每秒钟会有几万甚至百万条请求，如果使用everysec的方式的话，万一服务器挂了那几万条数据就丢失了)。