【Redis】持久化的两种方式及优缺点

因为redis的数据都是保存在内存里面的，因此需要持久化来实现redis的高可用性。

1、RDB:

RDB 持久化是把当前内存里面的数据生成快照保存到磁盘里。是对 Redis 中的数据执行周期性的持久化。

优点：

1、RDB 会生多个数据文件，每个是一个二进制文件，代表 Redis 在某个时间点上的数据快照。非常适合于备份，全量复制等场景，适合用于冷备份。可以定时同步到远端的服务器，比如阿里的云服务，这样一旦线上挂了，你想恢复多少分钟之前的数据，就去远端拷贝一份之前的数据就好了。

2、Redis 加载 RDB 恢复数据远远快于 AOF 的方式。而且RDB对Redis的性能影响非常小，是因为在同步数据的时候他只是fork了一个子进程去做。

缺点：

 1、RDB默认五分钟甚至更久的时间才会生成一次，这意味着你这次同步到下次同步这中间五分钟的数据都很可能全部丢失掉。因此RDB 方式数据无法做到实时持久化/秒级持久化，

2、因为 bgsave 每次运行都要执行 fork 操作创建子进程，属于重量级操作，频繁执行成本过高， 如果文件很大，客户端可能会暂停几毫秒甚至几秒，你公司在做秒杀的时候他刚好在这个时候fork了一个子进程去生成一个大快照，那就会有很大问题。

---

2、AOF

AOF 持久化以日志的方式记录每次写命令，以“只追加”的方式写入日志，所以没有任何磁盘寻址的开销，所以很快，有点像Mysql中的binlog。重启时再重新执行 AOF 文件中的命令达到恢复数据的目的。AOF 的主要作用是解决了数据持久化的实时性，目前是 Redis 持久化的主流方式。两种机制全部开启的时候，Redis在重启的时候会默认使用AOF去重新构建数据，因为AOF的数据是比RDB更完整的。

       开启 AOF 功能需要设置：appendonly yes，默认不开启。保存路径同 RDB 方式一致，通过 dir 配置指定。

优点：

1、RDB五分钟一次生成快照，但是AOF是一秒一次去通过一个后台的线程fsync操作，那最多丢这一秒的数据。

2、AOF在对日志文件进行操作的时候是以append-only的方式去写的，他只是追加的方式写数据，自然就少了很多磁盘寻址的开销了，写入性能惊人，文件也不容易破损。

缺点：

1、一样的数据，AOF文件比RDB还要大。

2、AOF开启后，Redis支持写的QPS会比RDB支持写的要低。

---

如何选择？

全都要，你单独用RDB你可能会丢失很多数据（五分钟一次），你单独用AOF，你数据恢复没RDB来的快，真出什么时候第一时间用RDB恢复，然后AOF做数据补全。