面试题：Redis RDB持久化过程中如果系统崩溃，可能会丢失哪些数据，如何尽量避免这种数据丢失情况？

Question

结合RDB持久化的原理，分析在系统崩溃场景下，从上次快照之后到崩溃时刻，哪些数据会面临丢失风险，并提出尽量减少这类数据丢失的方法。

Answer 1

1. RDB持久化原理

RDB持久化是将Redis在某一时刻的数据以快照的形式保存到磁盘上。Redis会定期（如根据配置的save规则，例如save 900 1表示900秒内如果有1个key发生变化则进行快照）或者在执行BGSAVE命令时，fork出一个子进程，子进程将当前内存数据写入到一个临时RDB文件，完成后将临时文件替换旧的RDB文件。

2. 系统崩溃场景下丢失数据分析

从上次快照之后到崩溃时刻，这期间发生变化（新增、修改、删除）的数据会面临丢失风险。因为RDB快照是定期或手动触发的，两次快照之间的数据变化不会实时持久化到磁盘，一旦系统崩溃，这些未被快照记录的数据就会丢失。

3. 尽量减少这类数据丢失的方法

• 缩短快照间隔时间：通过修改save配置项，如设置更短的时间间隔和更小的变化次数，例如save 60 100，让Redis更频繁地进行快照。但这会增加I/O开销，影响Redis性能。
• 结合AOF持久化：AOF（Append - Only - File）持久化是将Redis执行的写命令以追加的方式保存到AOF文件中。开启AOF后，Redis可以配置不同的刷盘策略（如appendfsync always表示每次写命令都刷盘；appendfsync everysec表示每秒刷盘一次；appendfsync no表示由操作系统决定刷盘时机）。appendfsync always刷盘策略能最大程度减少数据丢失，但性能开销较大；appendfsync everysec在性能和数据安全性之间有较好的平衡，系统崩溃时最多丢失1秒的数据。