02.Redis---数据持久化

一、简介

        Redis是一种内存数据库，在断电时数据可能会丢失。比如你redis整个挂了，然后redis不可用了，如果没有持久化的话，redis就会丢失所有的数据，如果通过持久化将数据搞一份儿到磁盘上去，然后再定期同步到一些云存储服务上去，那么就可以保证一些数据不丢失，保证数据的可靠性。

持久化方式：

• RDB
• AOF

二、RDB方式持久化

        Rdb方式是通过手动(save-阻塞式，bgsave-异步)或周期性方式保存redis中key/value的一种机制,Rdb方式一般为redis的默认数据持久化方式.系统启动时会自动开启这种方式的持久化机制。

1.配置文件

RDB方式的持久化是默认开启的，也可按规则自己配置，打开redis.conf文件

 这三行的意思是每隔60s/300s/900s，如果有超过10000/10/1个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting(快照)。

 这个意思是持久化rdb文件遇到问题时，主进程是否接受写入，yes 表示停止写入，如果是no 表示redis继续提供服务。

 这个意思是在进行快照镜像时,是否进行压缩。yes:压缩，但是需要一些cpu的消耗。no:不压缩，需要更多的磁盘空间。根据自己的需求来配置

 这个意思是有一个CRC64的校验就被放在了文件末尾，当存储或者加载rbd文件的时候会有一个10%左右的性能下降，为了达到性能的最大化，你可以关掉这个配置项。

 Redis里面在网络传输和RDB备份的时候都会面临着数据出错的问题，因此采用了数据的校验。包括使用了CRC64的校验算法。CRC检验原理实际上就是在一个p位二进制数据序列之后附加一个r位二进制检验码(序列)，从而构成一个总长为n＝p＋r位的二进制序列；附加在数据序列之后的这个检验码与数据序列的内容之间存在着某种特定的关系。如果因干扰等原因使数据序列中的某一位或某些位发生错误，这种特定关系就会被破坏。因此，通过检查这一关系，就可以实现对数据正确性的检验。

 快照的文件名，可以自定义

2.测试持久性

配置文件定义完后我们进行持久性测试

测试一：直接关闭redis查看数据是否存在

清除并添加测试数据

 直接关闭再启动查看数据库数据

结果：数据没有丢失，这其实是一种安全的退出，再退出时会立刻生成一份完整的rdb快照，所以数据不会丢失。

测试二：打开两个客户端，一个把RDB文件删除，一个进行redis插入数据，我们再用kill的方式进行强杀进程之后查看数据是否存在

清除rdb文件

 

 存入测试数据

 强杀进程

 启动redis查看数据

结果：出现了数据丢失现象

测试三：手动调用save(同步保存)或者bgsave(异步保存)执行rdb快照生成.然后杀掉redis进程,再重启检测是否还有刚刚保存的数据.

添加测试数据

杀死进程

 启动redis查看数据是否存在

 

结果：数据没有丢失，删除的文件又出现了 

3.知识点

Redis中的save与bgsave的区别：

• Redis Save 命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。
• BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。

RDB持久化机制的优缺点：

优点：

1. RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据.
2. RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。
3. 相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速。
    

缺点：

假如redis故障时，要尽可能少的丢失数据，那么RDB方式不太好，它都是每隔5分钟或更长时间做一次快照，这个时候一旦redis进程宕机，那么会丢失最近几分钟的数据。

三、AOF方式持久化

Aof方式是通过记录写操作日志的方式,记录redis数据的一种持久化机制,这个机制默认是关闭的。

1.配置文件

打开redis.conf文件进行配置

 是否开启AOF，默认时关闭的

 指定文件名称，自定义

 Redis支持三种刷写模式：

• 第一种：每次收到写命令就立即强制写入磁盘，类似MySQL的sync_binlog=1,是最安全的。但该模式下速度也是最慢的，一般不推荐使用。
• 第二种：每秒钟强制写入磁盘一次，在性能和持久化方面做平衡，推荐该方式。
• 第三种：完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不推荐。

 在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes

 第一行的意思是当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。

第二行的意思是当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。

2.测试

写入数据，查看appendonly.aof文件的日志记录

 删除RDB文件，写入测试数据，强杀进程并重启进行查看数据

 发现数据还在，这是因为redis进程启动的时候，直接就会从appendonly.aof中加载所有的日志，把内存中的数据恢复回来。

3.知识点

简述AOF方式中的rewrite操作：

        redis中的可以存储的数据是有限的，很多数据可能会自动过期，也可能会被用户删除或被redis用缓存清除的算法清理掉。也就是说redis中的数据会不断淘汰掉旧的，只有一部分常用的数据会被自动保留在redis内存中，所以可能很多之前的已经被清理掉的数据，对应的写日志还停留在AOF中，AOF日志文件就一个，会不断的膨胀，最好导致文件很大。
        所以,AOF会自动在后台每隔一定时间做rewrite操作，比如日志里已经存放了针对100w数据的写日志了，但redis内存现在10万数据; 于是，基于内存中当前的10万数据构建一套最新的日志，然后到AOF文件中; 覆盖之前的老日志，从而，确保AOF日志文件不会过大，保持跟redis内存数据量一致.

AOF持久化机制的优缺点：

优点：

1. AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据.
2. AOF日志文件通常以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，并且文件不容易破损，即使文件尾部破损，也很容易修复。
3. AOF日志文件过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的日志进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
4. AOF日志文件的命令通过易读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据.
    

缺点：

1. 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。
2. AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。
3. AOF这种基于命令日志方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。
    

总结：我们到底改如何选择持久化方式呢？

• 不要仅仅使用RDB，因为那样会导致你丢失很多数据。
• 也不要仅仅使用AOF，因为AOF做冷备没有RDB做冷备进行数据恢复的速度快,并且RDB简单粗暴的数据快照方式更加健壮。
• 综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备。