持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第9天，点击查看活动详情

我们前几天的学习，知道了RDB和AOF的持久化方式，今天我们来比较下，RDB和AOF的各自的优点和缺点，以及在平时我们如何选择持久化的方式。

RDB和AOF的优缺点

RDB持久化

• RDB 在分片恢复大数据集时的速度比 AOF 的恢复速度要快。
• RDB 会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，非常适合做数据冷备。
• RDB对redis对外提供读写服务的时候，影像非常小，因为redis 主进程只需要fork一个子进程出来，让子进程对磁盘io来进行rdb持久化

缺点：

• 做不到实时数据的持久化
• 分片故障时候，会丢失时间段内的数据，比如 12:00 的时候写了快照，12:30再次写之前 故障，半小时的数据会丢失。
• RDB每次fork出子进程来执行RDB快照生成文件时，如果文件特别大，可能会导致客户端提供服务暂停数毫秒或者几秒
• RDB文件需要满足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）

AOF持久化

优点：

• 兼容性好
• 秒级持久化，减少数据丢失，默认AOF同步文件策略是everysec，会以每隔1秒，通过后台的一个线程去执行一次fsync操作，如果redis进程挂掉，最多丢失这1秒的数据。

缺点：

• AOF文件很大。
• 对缓存性能影响大
• AOF文件数据恢复比较慢，不适合做冷备。

如何选择持久化方式

无论是RDB还是AOF，持久化的开启都是要付出性能方面代价的：

RDB持久化对性能损耗

• bgsave在进行fork操作时Redis主进程会阻塞
• 子进程向硬盘写数据也会带来IO压力；

AOF持久化对性能损耗

• 如果选择的是默认的everysec秒级同步策略，向硬盘写数据的频率大大提高，对IO压力更大，甚至可能造成AOF追加阻塞问题。
• AOF文件的重写与RDB的bgsave类似，也会有fork时的阻塞和子进程的IO压力问题。由于AOF向硬盘中写数据的频率更高，因此对Redis主进程性能的影响会更大。

在实际生产环境中，根据数据量、应用对数据的安全要求、预算限制等不同情况，会有各种各样的持久化策略；如完全不使用任何持久化、使用RDB或AOF的一种，或同时开启RDB和AOF持久化等。此外，持久化的选择必须与Redis的主从策略一起考虑，因为主从复制与持久化同样具有数据备份的功能，而且主机master和从机slave可以独立的选择持久化方案。

总结

需要根据具体的业务场景来选择是开启AOF持久化还是开启RDB持久化。
（1） 如果缓存没有，有降级查询DB，并且数据会补全至redis缓存中。
那么无论是单机，还是主从架构，都可以不进行任何持久化。

（2）主从环境，缓存持久化存储。。
第一种方式： master分片：完全关闭RDB和AOF持久化，这样可以让master的性能达到最好
slave分片：

• 关闭RDB，开启AOF（任何情况下，即使是从分片，也不建议开启AOF，文件太大，除非是为了排查问题，看下有期间哪些业务key进行过操作）
• 关闭RDB，关闭AOF（对数据丢失有一定的容忍度）
• 开启RDB，关闭AOF（常用方式，RDB的开启尽量选择天为单位，每天进行一次备份）