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持久化，如下圖所示：
