一篇文章让你读懂Redis持久化机制

概念：Redis的高性能是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存中同步到硬盘(文件)中，这一过程就是持久化。

包含: RDB、AOF、不持久以及RDB+AOF-->这四种选项

1.RDB持久化机制

1.RDB概念：

RDB 持久化以指定的时间间隔执行数据集的快照。RDB持久化方式是Redis默认开启的，我们不配置也可以默认使用RDB持久化机制，持久化内存数据到磁盘

2. 触发机制

2.1.自动触发

save 900 1 900秒内至少有一次修改则触发保存的操作
save 300 1 300秒内至少有10次修改则触发保存的操作
save 60 1 60秒内至少有一万次修改则触发保存的操作
执行shutdown命令关闭服务器时，如果没有开启AOF持久化功能，那么会自动执行一次bgsave
主从同步（slave和master建立同步机制）

2.2.手动触发

save命令：会阻塞当前服务器，直到RDB完成为止，如果数据量大的话会造成长时间的阻塞，线上环境一般禁止使用
bgsave命令：就是background save，执行bgsave命令时Redis主进程会fork一个子进程来完成RDB的过程，
完成后自动结束（操作系统的多进程Copy On Write机制，简称COW）。
所以Redis主进程阻塞时间只有fork阶段的那一下。相对于save，阻塞时间很短。

3.RDB执行流程

Redis 使用操作系统的多进程 cow(Copy On Write) 机制来实现RDB快照持久化

1.执行bgsave命令的时候，Redis主进程会检查是否有子进程在执行RDB/AOF持久化任务，
  如果有的话，直接返回
2.Redis主进程会fork一个子进程来执行执行RDB操作，fork操作会对主进程造成阻塞（影响Redis的读写），
  fork操作完成后会发消息给主进程，从而不再阻塞主进程。（阻塞仅指主进程fork子进程的过程，
  后续子进程执行操作时不会阻塞）
3.RDB子进程会根据Redis主进程的内存生成临时的快照文件，持久化完成后会使用临时快照文件
  替换掉原来的RDB文件。（该过程中主进程的读写不受影响，但Redis的写操作不会同步到主进程的
  主内存中，而是会写到一个临时的内存区域作为一个副本）
4.子进程完成RDB持久化后会发消息给主进程，通知RDB持久化完成
  （将上阶段内存副本中的增量写数据同步到主内存）

4.RDB的优点：

1.RDB文件小，非常适合定时备份，用于灾难恢复
2.Redis加载RDB文件的速度比AOF快很多，因为RDB文件中直接存储的是内存数据，
  而AOF文件中存储的是一条条命令，需要重演命令。

5.RDB缺点：

1.RDB无法做到实时持久化，若在两次bgsave间宕机，则会丢失区间（分钟级）的增量数据，
  不适用于实时性要求较高的场景
2.RDB的cow机制中，fork子进程属于重量级操作，并且会阻塞redis主进程
3.存在老版本的Redis不兼容新版本RDB格式文件的问题

 2.AOF持久化机制

1.AOF概念：

AOF 持久化记录服务器收到的每个写操作，这些操作将在服务器启动时再次播放，重建原始数据集。命令使用与 Redis 协议本身相同的格式以仅附加的方式记录。当日志变得太大时，Redis 能够在后台重写日志。

2.开启方式：AOF默认是关闭的，通过redis.conf配置文件进行开启

注意: 当 AOF 和 RDB 机制并存时，Redis 会优先采纳 AOF 机制。
使用 AOF 持久化文件恢复内存中的数据
。而 AOF 刚刚开启时 appendonly.aof 持久化文件中没有任何数据。
拿空的 appendonly.aof 持久化文件恢复内存，就会导致以前所有数据都丢失。 

3.AOF本质就是：使用文件记录redis服务器上所有的写操作

4.重写（rewrite）机制：

AOF Rewrite 虽然是“压缩”AOF文件的过程，但并非采用“基于原AOF文件”来重写或压缩，
而是采取了类似RDB快照的方式：基于Copy On Write，全量遍历内存中数据，
然后逐个序列到AOF文件中。因此AOF rewrite能够正确反应当前内存数据的状态。

4.AOF的优点：

AOF只是追加写日志文件，对服务器性能影响较小，速度比RDB要快，消耗的内存较少

5.AOF的缺点：

AOF方式生成的日志文件太大，需要不断AOF重写，进行瘦身。
即使经过AOF重写瘦身，由于文件是文本文件，文件体积较大（相比于RDB的二进制文件）。
AOF重演命令式的恢复数据，速度显然比RDB要慢。

3.如何选择Redis的持久化选项

如果Redis仅仅作为缓存可以不使用任何持久化方式。

其他应用方式综合考虑性能和完整性、一致性要求。

RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘允许，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。如果不开启AOF，仅靠Master-Slave Replication 实现高可用性能也不错。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时挂掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构。