save：
优点：节约系统资源
缺点：直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。
bgsave：
优点：fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。 Redis 服务器在BGSAVE 执行期间仍然可以继续处理客户端的请求
缺点：由于会fork一个进程，因此更消耗内存
综上：
还是推荐使用bgsave命令，毕竟save命令阻塞其他请求是我们无法接受的
---------------------------------------------------
save m n：触发机制
自动触发最常见的情况是在配置文件中通过save m n，指定当m秒内发生n次变化时，会触发bgsave。
例如，查看Redis根目录默认配置文件 redis.conf，看到如下配置信息：
其中save 900 1的含义是：当时间到900秒时，如果Redis数据发生了至少1次变化，则执行bgsave；save 300 10和save 60 10000同理。
当三个save条件满足任意一个时，都会引起bgsave的调用。
save m n：实现原理
1、Redis的save m n，是通过serverCron函数、dirty计数器、和lastsave时间戳来实现的。
2、serverCron是Redis服务器的周期性操作函数，默认每隔100ms执行一次（可在redis.conf 文件中配置 默认：hz 10 这个配置表示1s内执行10次，也就是每100ms触发一次定时任务）；
该函数对服务器的状态进行维护，其中一项工作就是检查 save m n 配置的条件是否满足，如果满足就执行 bgsave。
3、dirty计数器是Redis服务器维持的一个状态，记录了上一次执行bgsave/save命令后，服务器状态进行了多少次修改(包括增删改)；而当save/bgsave执行完成后，会将dirty重新置为0。
4、例如，如果Redis执行了set mykey helloworld，则dirty值会+1；如果执行了sadd myset v1 v2 v3，则dirty值会+3；注意dirty记录的是服务器进行了多少次修改，而不是客户端执行了多少修改数据的命令。
5、lastsave时间戳也是Redis服务器维持的一个状态，记录的是上一次成功执行save/bgsave的时间。
6、save m n的原理如下：每隔100ms，执行serverCron函数；在serverCron函数中，遍历save m n配置的保存条件，只要有一个条件满足，就进行bgsave。
对于每一个save m n条件，只有下面两条同时满足时才算满足：
当前时间-lastsave > m
dirty >= n
save m n ： 执行日志
下图是save m n触发bgsave执行时，服务器打印日志的情况：
其他触发机制：
除了save m n以外，还有一些其他情况会触发bgsave：
在主从复制场景下，如果从节点执行全量复制操作，则主节点会执行 bgsave 命令，并将rdb文件发送给从节点；
执行shutdown命令时，自动执行rdb持久化，如下图所示：
