面试题：Redis RDB自动间隔性保存对系统资源的影响及优化

Question

在高并发读写的Redis环境中，RDB自动间隔性保存会对系统的CPU、内存等资源产生怎样的影响？你会如何通过调整相关参数或采用其他手段来优化这种影响，以达到更好的成本效益平衡？

Answer 1

RDB自动间隔性保存对系统资源的影响

1. CPU影响
   • 保存时：RDB保存是通过fork子进程来进行数据持久化的。fork操作本身会消耗一定的CPU资源，因为它需要复制父进程的地址空间等信息。在数据量较大时，这个过程可能会比较耗时，导致CPU使用率瞬间升高。
   • 恢复时：从RDB文件恢复数据时，Redis需要将文件中的数据读入内存并进行解析重建数据结构，这也会占用一定的CPU资源，特别是在数据量很大且数据结构复杂的情况下。
2. 内存影响
   • 保存时：fork操作后，父子进程会共享内存数据页（Copy - on - Write，写时复制机制）。但如果在RDB保存过程中有大量写操作，会导致内存页的复制，从而使内存使用量增加。如果内存紧张，可能会触发系统的内存交换（swap），严重影响系统性能。
   • 恢复时：需要足够的内存来容纳从RDB文件中恢复的数据。如果内存不足，可能导致恢复失败或者系统性能急剧下降。

优化手段

1. 调整RDB相关参数
   • save配置：可以适当延长RDB自动保存的时间间隔，减少不必要的频繁保存操作。例如，默认配置save 900 1（900秒内如果至少有1个键被修改则进行保存）、save 300 10（300秒内如果至少有10个键被修改则进行保存）等，可以根据业务特点调整这些参数，如save 1800 5 ，即1800秒（30分钟）内至少有5个键被修改才进行保存，这样减少了频繁的fork操作，降低CPU和内存压力。
   • rdbcompression：开启RDB文件压缩（默认开启），通过压缩RDB文件可以减少磁盘占用，在一定程度上减少恢复时的数据读取量，从而降低CPU在恢复阶段的压力。但压缩本身也会消耗一定CPU资源，所以需要根据实际情况权衡。如果CPU资源紧张，可以考虑关闭压缩（rdbcompression no）。
2. 采用其他手段
   • AOF和RDB结合：使用AOF（Append - Only - File）持久化方式作为补充。AOF是增量式的持久化，它可以在高并发写场景下更及时地记录写操作。可以设置AOF的fsync策略为everysec（每秒同步一次），这样既能保证数据的安全性，又不会像always那样过于频繁地进行磁盘I/O。同时结合RDB的定期保存，RDB用于大规模数据的恢复，AOF用于保证故障时的数据完整性，降低RDB频繁保存带来的资源消耗。
   • 主从架构优化：在主从架构中，可以在从节点上进行RDB保存操作。主节点只负责处理客户端的读写请求，从节点分担RDB保存任务，这样可以避免主节点在保存RDB时因CPU和内存压力而影响正常的读写服务。同时，从节点的数据恢复也可以利用RDB文件，提高整体的恢复效率。