RDB
將Redis某一時刻的內存數據保存到硬盤的文件當中，默認保存的文件名爲dump.rdb，而在Redis服務器啓動時，會重新加載dump.rdb文件的數據到內存當中恢復數據。
1、配置：
# 900s內至少達到一條寫命令
save 900 1
# 300s內至少達至10條寫命令
save 300 10
# 60s內至少達到10000條寫命令
save 60 10000
# 是否壓縮rdb文件
rdbcompression yes
# rdb文件的名稱
dbfilename redis-6379.rdb
# rdb文件保存目錄
dir ~/redis/
2、自動快照：
執行流程：
（1）Redis使用fork函數複製一份當前進程（父進程）的副本（子進程）；
（2）父進程繼續接收並處理客戶端發來的命令，而子進程開始將內存中的數據寫入硬盤中
的臨時文件RDB；
（3）當子進程寫入完所有數據後會用該臨時文件RDB替換舊的RDB文件，至此一次快照操作完
成。
3、手動快照：
save命令：由主進程進行快照操作，會阻塞住其他請求
bgsave命令：通過fork子進程進行快照操作。
4、RDB的幾個優點
- 與AOF方式相比，通過rdb文件恢復數據比較快。
- rdb文件非常緊湊，適合於數據備份。
- 通過RDB進行數據備，由於使用子進程生成，所以對Redis服務器性能影響較小。
5、RDB的幾個缺點
- 如果服務器宕機的話，採用RDB的方式會造成某個時段內數據的丟失，比如我們設置10分鐘同步一次或5分鐘達到1000次寫入就同步一次，那麼如果還沒達到觸發條件服務器就死機了，那麼這個時間段的數據會丟失。
- 使用save命令會造成服務器阻塞，直接數據同步完成才能接收後續請求。
- 使用bgsave命令在forks子進程時，如果數據量太大，forks的過程也會發生阻塞，另外，forks子進程會耗費內存。
AOF
AOF持久化方式會記錄客戶端對服務器的每一次寫操作命令，並將這些寫操作以Redis協議追加保存到appendonly.aof文件末尾，Redis 重啓會通過執行文件中保存的寫命令在內存中重建整個數據庫的內容，以達到恢復數據的目的。
1、配置
# 開啓aof機制
appendonly yes
# aof文件名
appendfilename "appendonly.aof"
# 寫入策略
appendfsync everysec
# appendfsync always 表示每個寫操作都保存到aof文件中，不丟失數據，慢
# appendfsync everysec 每秒寫入一次aof文件,最多可能會丟失1s的數據。
# appendfsync no 由操作系統來處理什麼時候寫入aof文件，最不安全，不推薦
# 保存目錄
dir ~/redis/
# 重寫aof文件
no-appendfsync-on-rewrite no # 默認不重寫，一般使用命令bgrewriteaof主動重寫追加aof文件
auto-aof-rewrite-percentage 100 # 目前的AOF文件大小超過上一次重寫時的AOF文件大小的百分之100時會再次進行重寫
auto-aof-rewrite-min-size 64mb # 小於64mb時不會進行重寫
2、aof文件重寫
每次appendfsync後，文件就會越來越大，所以需要文件重寫來壓縮aof文件
3、aof文件損壞
服務器宕機時，aof文件會出現格式錯誤，在重啓Redis服務器時，Redis服務器會拒絕載入這個aof文件，可以通過以下步驟修復aof並恢復數據。
-
備份現在aof文件，以防萬一。
-
使用redis-check-aof命令修復aof文件，該命令格式如下：
redis-check-aof -fix appendonly.aof
4、優點：
- 數據安全性更高，AOF持久化可以配置appendfsync屬性
- 通過append模式寫文件，即使中途服務器宕機，可以通過redis-check-aof工具解決數據一致性問題。
- AOF機制的rewrite模式。
5、缺點：
- AOF文件比RDB文件大，且恢復速度慢；
- 數據集大的時候，比RDB啓動效率低。
- 根據同步策略的不同，AOF在運行效率上往往會慢於RDB。
rdb、aof混用
AOF重寫日誌時會將RDB持久化的內容寫到AOF文件開頭，於是在Redis重啓時，可以先加載RDB的內容，再對增量的AOF日誌進行重放，提升Redis重啓的效率。