聊一聊Redis的RDB快照

前面我们学习了Redis的AOF日志，我们知道通过AOF在进行数据恢复时需要将操作日志全都执行一遍，如果操作很多，那么Redis就会恢复的很慢。那有没有一种既可靠有快速的方法呢，今天我们聊一聊Redis的RDB快照。

顾名思义快照就是将内存中的数据全都记录到磁盘中，但是同样的如果给内存的全量数据做快照，把它们全部写入磁盘也会花费很多时间。
Redis的单线程模型就意味着我们需要尽量避免所有阻塞主线程的操作，在Redis中提供了两个命令来生成RDB快照：

• save：在主线程中执行，会产生阻塞
• bgsave：创建子线程，专门用于生成RDB快照，这也是默认的配置

有一个问题我们在创建快照的时候能修改数据吗，如果修改了那么生成的快照会不会出现问题，这个时候我们就要提到Redis的写时复制技术，简单来说bgsave子进程是由主线程fork生成的，可以共享主线程所有的内存数据。此时如果主线程读取数据那么是不会冲突的，但是如果主线程要修改一块数据，那么这块数据就会被复制一份，生成该数据的副本。然后bgsave子进程就会把副本数据写入RDB快照，该过程主线程可以直接修改原来数据。

那么我们需要什么时间做一次快照呢？这个需要我们根据实际情况考虑，如果频繁的执行全量夸张，也会带来CPU资源的开销，因为bgsave执行时虽然不阻塞主线程，但是fork 一个bgsave子进程也需要消耗资源的。如果间隔时间太长，那么两次快照之间丢失的数据可能会比较多。在Redis 4.0中提出了混合使用AOF日志和内存快照的方法，就是内存快照以一定的频率执行，两次快照之间，使用AOF日志记录的命令。

总结：

在我们使用AOF和RDB上，我们要注意为了保证数据不丢失，将AOF和RDB混合使用；如果允许丢失分钟级别数据，可以只使用RDB；如果只使用AFO，优先使用everysec的配置，能在可靠性和性能之间取得一个平衡。