Redis持久化机制总结

Redis持久化机制总结

一. Redis持久化概述

1. 为了应对生产环境下，Redis的故障恢复和数据备份等需求，Redis提供了两种持久化机制，分别是RDB和AOF。
2. RDB：以特定的时间间隔，保存当前数据库中的全量数据快照。
3. AOF：以追加日志的形式，将Redis服务器的操作写入日志文件。
4. 可以不开启任何持久化方案，但是这在生产环境下就是作死。
5. RDB和AOF可以同时启用，但是在这种情况下，Redis服务器重启时，会优先采用AOF文件进行数据的恢复，因为AOF文件中保存的数据是最完整的。

二. RDB机制详解

1. RDB是以指定的时间间隔(可配置，如1小时、1天等)，生成一份当前完整的数据快照文件，它是一份单独的、经过压缩的、二进制形式的文件。在生成RDB快照时，Redis会fork一个子进程，由子进程去执行快照的生成，而父进程正常对客户端提供服务。
2. 优点
   1. RDB文件非常适合用于数据备份，我们可以定期将Redis备份的RDB文件保存起来，或者上传到云端，以便后期数据校验或数据恢复的需求。
   2. 由于RDB文件是经过压缩的RDB单独的一份二进制文件，因此它非常适合用于灾难恢复。
   3. RDB方式对性能影响较小，父进程只需要fork一个子进程，剩余的事情交给子进程处理就好。
   4. Redis重启时，如果使用RDB文件进行数据恢复会比AOF文件更快。
3. 缺点
   1. RDB方式无法保证数据的可靠性，如果在生成快照之前服务器宕机就会造成数据的丢失。在对数据可靠性要求较高的场景，仅采用RDB方式显然无法满足需求。
   2. 在数据量较大时，fork子进程去生成快照就会变成一个耗时操作，极端情况下甚至会导致Redis服务毫秒级乃至秒级的停顿。

三. AOF机制详解

1. AOF是以追加日志的形式保存Redis的操作记录。在写入日志时，Redis会先将操作写入AOF缓存区，然后定期由操作系统调用fsync()函数去刷盘。当AOF文件的大小达到一定条件时，会触发rewrite操作对文件进行压缩。
2. 优点
   1. AOF机制对数据可靠性有更好的支持。默认情况系，Redis会每秒写1次AOF文件，这样最坏情况下也仅会造成1秒的数据丢失，大多数情况下是可以忍受的。
   2. AOF文件达到一定大小时，会自动触发重写(rewrite)，以对文件进行压缩。举个例子：对一个key age执行了100次incr，将其从1变成了100，这样在AOF文件中会保存100条日志。对其进行重写后，就仅剩下一条age的最终值100的日志。
3. 缺点
   1. 对于相同的数据库来说，AOF文件通常比RDB文件更大。
   2. fsync策略的选择十分影响AOF的性能，如果采用fsync at every query，则会很大程度上降低Redis的性能。

四. 实践建议

1. 大部分场景下，建议同时开启RDB和AOF两种机制，这样可以兼顾数据的安全和Redis的性能。
2. 针对可以容忍分钟级数据丢失的场景，可以仅开启RDB。
3. 不建议关闭RDB而仅使用AOF，因为RDB对于数据的备份和恢复有十分重要的意义。