redis持久化

redis持久化的意义

对于企业级的redis架构来说，持久化是不可减少的
企业级redis集群架构：海量数据，高并发，高可用
持久化主要是做在灾难恢复，数据恢复，也可以归类到高可用一个环节中。
很有可能，大量请求过来，缓存全部无法命中，这个时候就死定了，缓存雪崩问题，所有请求，没有在redis命中，就会mysql中找，一下在mysql承接高并发，就宕机了。

redis持久化：RDB AOF

1.RDB和AOF两种持久化机制的介绍
RDB持久化机制，对redis中的数据执行周期性持久化
AOF机制对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启时，可以通过回放AOF日志中的写入指令来重构整个数据集
如果我们想要redis仅仅作为出内存的缓冲来用，那么可以禁止ROB和AOF所有的持久化机制。
通过RDB或AOF，都可以将redis内存中的数据给持久化到磁盘上，然后可以将这些数据备份到别的地方去
如果redis挂了，服务器上内存和磁盘数据丢失了，可以从云服务上拷贝回来之后，放在指定目录，重启redis，redis就会自动根据持久化数据文件中的数据，去恢复内存中的数据，继续对外提供服务。
如果同时使用RDB和AOF两种持久化机制，那么在redis 重启的时候，会使用AOF来重新构建数据，因为AOF中的数据更加完整。

RDB持久化机制优点及缺点

优点：

RDB会生成多个数据文件，每个数据文件都代表某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上。
RDB对redis对外提供读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。
相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加敏捷。

缺点

如果想要在redis故障中，尽可能少的丢失数据，那么RDB没有AOF好，一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据。
*RDB每次fock子进程来执行RDB快照数据文件生成时候，如果数据文件特别大，可能会导致对客户提供的服务暂停数毫秒，甚至数秒钟。

AOF持久化机制优点及缺点

优点：

AOF可以更好保证数据不丢失，一般AOF每个1秒，通过后台线程执行一次fsync操作，最多丢失1秒钟数据
AOF日志文件以append-only模式写入，所以没有任何磁盘寻址开销，写入性能非常高，而且文件不容易损坏，及时文件损坏，也是很容易修复的。
AOF日志文件及时过大的时候，出现后台重写操作，也不会影响客户端的读写，因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志，在创建新日志文件时候，老的日志文件照常写入，当新的merge后的日志文件ready时候，再交换新老日志文件即可。

缺点：

对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
AOF开启后，支持写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync,性能也还是很高的

RDB和AOF如何选择

不要仅仅使用RDB，因为那样会导致你丢失很多数据
也不要仅仅使用AOF，因为那样有两个问题，第一，你通过AOF做冷备，没有RDB做冷备，来的恢复速度更快; 第二，RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug
综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复

AOF rewrite原理剖析.png

RDB和AOF的介绍.png