Redis持久化方式以及他们的区别？

AOF

AOF(Append Only File)持久化:

用单独的日志方式记录下每次写命令，重启时再重新执行AOF文件中的命令达，用于恢复数据.

AOF的主要作用是解决了数据持久化的实时性,也是Redis持久化的主流方式.

AOF持久化机制对我们兼顾数据安全性和性能非常有帮助.

RDB

RDB持久化：把当前进程数据生成快照保存到硬盘的过程.

什么是内存快照？就是内存中的数据在某一个时刻的状态记录,

就像照片，当你给朋友拍照时，一张照片就能把朋友一瞬间的形象完全记下来,

RDB=Redis DataBase 的缩写.

RDB持久化以及可能的问题：

如图，假设先在 T0 时刻做了一次快照（下一次快照是T4时刻），然后在T1时刻，数据块 5 和 8 被修改了，要是在T2时刻，机器宕了，那么只能按照 T0 时刻的快照进行恢复。这个时候，数据块 5 和 8 的修改值因为没有快照记录，就不能恢复了呀~

所以我们能看出，假设想丢失较少的数据，T4-T0就要尽可能的小，但是若频繁的执行全量快照，同样会带来以下的开销：

第一方面：频繁将全量数据写入磁盘，会给磁盘带来很大压力，多个快照竞争有限的磁盘带宽，前一个快照还没有做完，后一个又开始做了，容易造成恶性循环。

另一方面，bgsave 子进程需要通过 fork 操作从主线程创建出来。虽然子进程在创建后不会再阻塞主线程，但是，fork 这个创建过程本身会阻塞主线程，而且主线程的内存越大，阻塞时间越长。如果频繁fork出bgsave 子进程，这就会频繁阻塞主线程了。

所以基于以上情况，才需要AOF的持久化机制.

其实AOF也不是万无一失的：

因为AOF的持久化是基于缓冲，并不是每一次接收到命令就去持久化：

开启AOF功能：设置配置:appendonly yes，默认是不开启。

Redis使用单线程响应命令，所有这里有一个AOF的缓冲区的概念。

Redis在开启AOF后，接收到命令先写入缓冲区aof_buf中，然后根据参数来进行持久化。

Redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制。

always

同步写回：每个写命令执行完，立马同步地将日志写回磁盘；

everysec

每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；

no

操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘，通常同步周期最长30秒。

很明显，配置为always时，每次写入都要同步AOF文件，在一般的SATA 硬盘上，Redis只能支持大约几百TPS写入,显然跟Redis高性能特性背道而驰,不建议配置。

配置为no，由于操作系统每次同步AOF文件的周期不可控,而且会加大每次同步硬盘的数据量,虽然提升了性能,但数据安全性无法保证。

配置为everysec，是建议的同步策略，也是默认配置，做到兼顾性能和数据安全性。理论上只有在系统突然宕机的情况下丢失1秒的数据。(严格来说最多丢失1秒数据是不准确的)

想要获得高性能，就选择 no 策略；如果想要得到高可靠性保证，就选择always 策略；如果允许数据有一点丢失，又希望性能别受太大影响的话，那么就选择everysec 策略。