谈谈 RDB
RDB：相当于对内存中的数据，拍一张数据快照。RDB文件存储的是二进制数据。
这里提一点，Redis 的快照是全量快照，也就是说每次执行快照，都是把内存中的「所有数据」都记录到磁盘中。
所以可以认为，执行快照是一个比较重的操作，如果频率太频繁，可能会对 Redis 性能产生影响。如果频率太低，服务器故障时，丢失的数据会更多。

怎么生成RDB文件?

save：一般不使用，因为会阻塞主线程，导致其他客户端请求阻塞。
basave：fork 一个子进程来生成RDB文件，不会一直阻塞主线程，可以正常响应客户端的请求。【创建子进程的过程中，是会阻塞主线程的。】
执行 bgsave 过程中，Redis 依然可以继续处理操作命令的，也就是数据是能被修改的。
那具体如何做到的呢？关键的技术就在于写时复制技术（Copy-On-Write, COW）。
执行 bgsave 命令的时候，会通过 fork() 创建子进程，此时子进程和父进程是共享同一片内存数据的，因为创建子进程的时候，会复制父进程的页表，但是页表指向的物理内存还是一个。

只有在发生修改内存数据的情况时，物理内存才会被复制一份。

但是这里就有一个问题了，在生成 RDB 文件的过程中，如果有新的写命令过来，那么最终生成的 RDB 文件中的数据就和 Redis 内存中的数据产生不一致了，怎么解决呢？

这个问题是存在的，所以说要配合 AOF 一起使用。

另外，写时复制的时候会出现这么个极端的情况。
在 Redis 执行 RDB 持久化期间，刚 fork 时，主进程和子进程共享同一物理内存，但是途中主进程处理了写操作，修改了共享内存，于是当前被修改的数据的物理内存就会被复制一份。

那么极端情况下，如果所有的共享内存都被修改，则此时的内存占用是原先的 2 倍。
所以，针对写操作多的场景，我们要留意下快照过程中内存的变化，防止内存被占满了

Redis什么时候会生成RDB呢？

1、人为手动的执行save命令。
2、Redis 还可以通过配置文件的选项来实现每隔一段时间自动执行一次 bgsave 命令，默认会提供以下配置：
● save 900 1
● save 300 10
● save 60 10000
save n m：表示在 n 秒内，至少有 m 次修改操作，就会执行bgsave命令