对于值得类型都基本完了，那接下来就得聊聊持久化的问题！

一、Redis持久化

1、什么是持久化：

将数据从掉电易失的内存存放到能够永久存储的设备上

2、Redis为什么要持久化

（1）基于内存的
（2）缓存服务器，需要么？看情况，缓存服务器宕了吗，所以还是要的，没有就会重新加载
（3）内存数据库，需要么？需要，存储业务数据
（4）消息队列，需要么？看情况，重要的就持久化

3、Redis持久化方式：

RDB（Redis DB）（数据）
AOF(AppendOnlyFile)（存的是命令，默认情况下不开启）

4、RDB持久化

RDB持久化功能可以将服务器包含的所有数据库数据以二进制文件的形式保存到硬盘里
redis服务器—–创建RDB文件(配置文件，dump.rdb)
在redis服务器创建RDB文件的情况中，一下三种最常见的：
1、服务器执行客户端发送的SAVE命令
2、服务器执行客户端发送的BGSAVE命令(BG,background后台执行，不会阻塞你的服务)
3、使用save配置选项设置的自动保存条件被满足，服务器将自动执行BGSAVE
前两种需要手动执行，第三种是由redis服务器自动执行
接着来介绍这三种情况的相同与不同之处：
手动穿件RDB文件，也就是手动发送SAVE命令或者BGSAVE命令
（1）通过使用客户端向服务器发送SAVE命令，可以命令服务器取创建一个新的RDB文件
（2）redis>SAVE
（3）在执行savem命令的时候，redis服务器将会被阻塞，无法处理客户端发送的命令请求，在SAVE执行完之后，才开始执行处理客户端请求
（4）如果RDB文件已经存在，那么服务器将自动使用新的RDB文件去代替旧的 RDB文件（定期的保存dunm.rdb文件）
BGSAVE：是一个异步的过程
redis服务器来fork()一个子进程去处理，对于客户来说，会直接返回OK，在日志中可以查看到每一次的操作

一些配置都在6379.conf中
创建子进程会消耗额外的内存，所以SAVE创建RDB的速度回避BGSAVE快，要在凌晨3点，则用save比较好，要在上线时，则用BGSAVE

自动去设置创建RDB文件
SAVE 时间（秒） 次数
举个例子：
SAVE 300 10
表示：距离上次300s,且数据库总共发生了不少于10次修改，那么执行BGSAVE命令
另外，用户还可以设置多个save选项来设置多个自动保存条件，当任何一个条件被满足时，就会自动执行BGSAVE命令!
每次创建RDB文件之后，服务器会实现自动化而设置的时间计数器和次数计数器就会被清零。并重新开始计数，所以保存多个结果不会叠加
在6379.conf中更改

5、RDB持久化缺点：

创建RDB文件需要将服务所有的数据库的数据保存起来，这是一个非常消耗资源和时间的操作，所以要隔一段时间才创建一新的RDB文件，也就是说创建RDB文件的操作布
操作不能过于频繁，否则会严重影响服务器性能。所以要用AOF来弥补这个缺点
数据丢失的例子：
AOF持久化有一个巨大的优势，那就是用户可以根据自己的需要对AOF持久化进行调整，让redis在遭遇意外的时候不丢失任何数据，或者只丢失一秒中，这样比RDB持久化
遭遇意外停机遭受的损失小的多
（1）AOF持久化保存数据库的方法是：每当有修改数据库的命令被执行时，服务器就会将执行的命令写入到AOF文件的末尾。
（2）只要重新执行AOF文件里的命令，就可以达到还原数据库的目的

6、安全性问题：

（1）虽然服务器执行一个修改数据库的命令，就会被执行的命令写入到AOF数据库，但并不意味着AOF文件持久化不会丢失任何东西
（2）在常见的操作系统中，执行write函数，会将一些内容写入到某个文件里面时，为了提高效率，不会直接往硬盘里写，而是将内容放在内存缓冲区，被填满时，
或者用户执行fsync调用或者fdatasyn调用时裁剪缓冲区的数据写入到硬盘
(3)所以对于AOF持久化来说，当一条命令被正真写到硬盘时，这条命令才不会因为停机而意外丢失
（4）因此，AOF持久化在遭遇停机意外丢失命令的数量，取决于命令被写入硬盘的时间
（5）越早将命令写入，则丢失数据越少，越晚，越多！

redis的三种情况，提供了appendfsync选项，这个选项有三个值：always,everysec或者no
always:每写入一个命令，就调用一次appendfsync选项，将缓冲去的命令也写到硬盘里，这样，即使意外停机，也不会丢失任何已经成功执行的命令
everysec:每一秒，最多丢失一秒的数据
NO：服务器不主动调用fdatasync,由操作系统决定，所以丢失的数量是不确定的
运行速度：always慢 everysec和no都很快
默认值：everysec

7、AOF文件中的冗余命令

（1）AOF文件的体积会越来越大
（2）为了使其大小在合理地范围之内，避免其胡乱增长，redis提供了AOF重写功能，可以产生一个新的AOF文件
——新的AOF文件记录的数据库数据和原有的AOF文件记录的数据库数据完全一样
——新的AOF文件会用尽可能少的命令来记录数据库数据，因此新的AOF文件会比原有的AOF文件体积小的多
——AOF重写期间，服务器不会被阻塞，可以正常处理客户端请求
有两种方法可以触发AOF重写：
1、客户端向服务器发送BGREWRITEAOF命令
2、通过设置配置选项来让服务器自动执行BGREWRITEAOF命令，他们分别是：
auto-aof-rewrite-min-size触发AOF重写的所需的最小以及：只要AOF文件体积大于等于size时，服务器才会考虑进行AOF重写，用于避免体积过小的AOFW
的文件进行重写
auto-aof-rewrite-percentade 100 达到100%进行重写

8、总结：比较

RDB持久化：（1） 全量备份，一次保管整个数据库（2）保存的时间较长（3）数据还原速度快（4）执行SAVE命令时会阻塞服务器，但手动和触发的BGSAVEB不会阻塞（5）更适合数据备份
AOF持久化：（1）增量备份，一次保存一个修改数据库的命令（2）保存的间隔默认为一秒钟（3）数据还原速度一般，冗余命令越多，还原速度越慢（4）无论时平时还是AOF重写的时候，都不会阻塞服务（后台进程）（5）更适合保存数据，通常意义上的持久化。在appendfsync always模式下进行时，redis的持久化方式和一般的SQL数据库持久化方式时一样的
好消息：可以同时使用两种持久化，需要根据你的需求来判断，还原数据优先用AOF
所以说Redis数据库安全性比不上SQL数据库的安全性是一个误解，当在always模式下运行的时候，redis持久化和一般的SQL数据库的持久化方式是一样的

多走路，多思考，越努力，越幸运！
                                                                                                                            ———————————————YoungerFary