数据安全与性能保障

Redis 提供俩种不同的持久化方法来将数据存储到硬盘上。

一种是 快照snapshotting（它可以将存在于某一时刻的所有数据都写入到硬盘里面）；

另一种 叫 只追加文件append-only file,AOF),它会在执行写命令时，将被执行的 写命令复制到硬盘里面；

以上两种持久化方法可以同时使用也可以单独使用。

创建快照的方法有：

1、客户端通过向Redis发送 BGSAVE命令来创建一个快照。Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程则继续处理命令请求；

2、客户端通过向Redis发送 SAVE命令来创建一个快照，接收到SAVE命令的Redis服务器在快照创建完毕之前不再响应任何其他命令。通常只有在内存不足时去执行BGSAVE命令的情况下，又或者即使等待持久化操作执行完毕也无所谓的情况下，才会使用这个命令；

3、如果设置了 save选项，则 从redis最近一次创建快照之后开始算起，当满足设置的条件后，redis就会自动触发BGSAVEmingl .如果用户设置了多个save配置选项，那么当任意一个save配置选项所设置的条件被满足时，Redis就会触发一次BGSAVE命令；

4、当Redis通过 SHUTDOWN命令接收到关闭服务器的请求时，或者接收到标准TERM信号时，会执行一个SAVE命令，阻塞所有客户端，不再执行客户端发送的任何命令，并在SAVE命令执行完毕之后关闭服务器；

5、当一个Redis服务器连接另一个Redis服务器，并向对方发送SYNC命令来开始一场复制操作的时候，如果主服务器目前没有在执行BGSAVE操作，或者主服务器并非刚刚执行完BGSAVE操作，那么主服务器就会执行BGSAVE命令；

Snapshot工作原理：

将数据先存储在内存，然后当数据累计达到某些设定的阀值的时候，就会触发一次DUMP操作，将变化的数据一次性写入数据文件中（RDB文件）

AOF持久化

AOF持久化文件同步过程：

1、调用file.write()方法对文件进行写入，写入时的内容首先会被存储到缓冲区，然后操作系统会在将来的某个时间将缓冲区存储的内容写入硬盘。

2、或者 用户可以调用 file.flush()方法来请求操作系统尽快将缓冲区存储的数据写入硬盘，但具体何时执行写入操作 仍然由操作系统决定。

3、除此之外，用户还可以命令操作系统将文件同步sync到硬盘，同步操作会一直阻塞直到指定的文件被写入硬盘为止。

AOF工作原理：

将数据同样先存在内存中，但是在存储的时候会调用fsync来完成本次写操作的日志记录，这个日志揭露文件其实是一个基于Redis网络交互协议的文本文件。AOF调用fsync也不是说全部都是无阻塞的，在某些系统上可能出现fsync阻塞进程的情况，对应这种情况可以通过配置修改，但是默认情况不需要修改。AOF最关键的配置就是调用fsync追加日志文件的频率，有俩种预设频率，always每次记录进程都添加，everysecond每秒添加一次。俩个配置各有所长。由于是采用日志追加的方式来持久化数据，所以引出了第二个日志的概念：Rewrite。

Rewrite：

由于AOF的存储是按照记录日志的方式去工作的，成千上万的数据插入必然导致日志文件的扩大，Redis这个时候就会根据配置合理触发Rewrite操作，所谓Rewrite就是将日志文件中的所有数据都重新写到另一个新的日志文件中，但是不同的是，对应老日志文件中对应Key的多次操作，只保留最终的值的那次操作记录到日志文件中，从而缩小日志文件的大小。

需要注意的俩个配置：

auto-aof-rewrite-percentage 100 （当前写入日志文件的大小占到初始日志文件大小的某个百分比时触发Rewrite）

auto-aof-rewrite-min-size 64mb （本次Rewrite最小的写入数据量）

以上俩个条件要同时满足才会触发。

性能：

Snapshot 方式的性能要高于AOF。原因：

1、采用二进制方式存储数据，数据文件比较小，加载速度快；

2、存储的时候按照配置中的save策略来存储，没错都是聚合很多数据批量存储，写入的效率也高，而AOF则一般都是工作在实时存储或准实时模式下，相对来说存储的频率高，效率却偏低；

数据安全：

AOF数据安全性要高于Snapshot存储。原因：

Snapshot存储是基于累计批量的思想，也就是说在允许的情况下，累计的数据越多那么写入的效率也就越高，但是数据的累计是靠时间的累积完成的，那么长时间数据不写入RDB，当Redis遇到奔溃那么没写入的数据就无法恢复了。

但是AOF方式偏偏相反，根据AOF配置的存储频率策略可以做到最少的数据丢失和较高的数据恢复能力。