Redis 持久化
前言
Rdis的讀寫都是在內存中進行，所以redis的性能很高。
持久化可以有效地避免因進程退出而造成數據丟失問題，下次重啓的時候利用之前持久化文件可以實現數據恢復。
持久化的幾種方式
Redis 持久化擁有以下三種方式：
- 快照方式（RDB, Redis DataBase）
RDB持久化是把當前進程數據生成快照保存到硬盤的過程，觸發RDB持久化過程分爲手動觸發和自動觸發
- 文件追加方式（AOF, Append Only File）
記錄所有的操作命令，並以文本的形式追加到文件中；
- 混合持久化方式，
Redis 4.0 之後新增的方式，混合持久化是結合了 RDB 和 AOF 的優點，在寫入的時候，先把當前的數據以 RDB 的形式寫入文件的開頭，再將後續的操作命令以 AOF 的格式存入文件，這樣既能保證 Redis 重啓時的速度，又能減低數據丟失的風險。
以上三種持久化方案，每一種都有特定的使用場景,具體的我們可以根據自己的需求自行選擇。
RDB持久化
RDB（Redis DataBase）是將某一個時刻的內存快照（Snapshot），以二進制的方式寫入磁盤的過程。
RDB的持久化方式有兩種：
一種是手動觸發，一種是自動觸發
手動觸發
手動觸發Redis提供了兩個命令 ：save 和 bgsave 。
- save 命令
save 手動觸發會阻塞主線程
在客戶端執行save命令時候，就會觸發持久化，但也會使得Redis主線程阻塞，必須等到RDB持久化完成之後，纔會相應客戶端的命令，線上環境不建議使用。
下圖演示使用save命令
啓動Redis （默認配置是rdb持久化方式），rdb文件時間。
然後使用save持久化數據
然後查看持久化後rdb文件的時間
說明手動持久化文件成功
- bgsave 命令
bgsave不會阻塞主線程
使用bgsave命令時候，Redis進程執行fork操作創建子進程，RDB持久化過程由子 進程負責，完成後自動結束。阻塞只發生在fork階段，一般時間很短，基本不會發生阻塞，與save命令相比顯然bgsave更適合我們持久化數據。
下圖表示開始自動持久化數據
自動觸發
如何自動觸發 RDB 持久化？
在redis.conf文件中有這麼一個配置
什麼意思呢？
- save m n
save m n 表示m秒內數據集存在n次修改 時，自動觸發bgsave命令。
save 900 1 則表明在 900 秒內，至少有一個鍵發生改變，就會觸發 RDB 持久化。
save 300 10 則表明在 300 秒內，至少有10個鍵發生改變，就會觸發 RDB 持久化。
save 60 10000 則表明在 60 秒內，至少有10000個鍵發生改變，就會觸發 RDB 持久化。
滿足以上任意一個條件，Redis 就會自動觸發bgsvae命令進行持久化工作。
- flushall
注意：flushall 是把內存中的數據清空，持久化會把原先已經持久化的 .rdb 文件清空。
- 主從同步觸發
Redis主從複製時，當從節點執行全量複製操作時，主節點會執行 bgsave 命令，並將 RDB 文件發送給從節點，該過程會自動觸發 Redis 持久化。
RDB配置說明
# RDB 保存的條件
save 900 1
save 300 10
save 60 10000
# bgsave 失敗之後，是否停止持久化數據到磁盤，yes 表示停止持久化，no 表示忽略錯誤繼續寫文件。
stop-writes-on-bgsave-error yes
# RDB 文件壓縮
# Redis 會採用 LZF 算法進行壓縮。如果不想消耗 CPU 性能來進行文件壓縮的話，可以設置爲關閉此功能，# 這樣的缺點是需要更多的磁盤空間來保存文件。
rdbcompression yes
# 寫入文件和讀取文件時是否開啓 RDB 文件檢查，檢查是否有無損壞，如果在啓動是檢查發現損壞，則停止啓動。
rdbchecksum yes
# RDB 文件名
dbfilename dump.rdb
# RDB 文件目錄
dir ./
RDB 優缺點
優點
- RDB是一個緊湊壓縮的二進制文件，代表Redis在某個時間點上的數據 快照。非常適用於備份，全量複製等場景。
- 與 AOF 格式的文件相比，RDB 文件可以更快的重啓。
- RDB 對災難恢復非常有用，它是一個緊湊的文件，可以更快的傳輸到遠程服務器進行 Redis 服務恢復
缺點
- RDB方式數據沒辦法做到實時持久化/秒級持久化，RDB只能保存某個時間間隔的數據，如果在這個期間Redis故障了，就會丟失一段時間的數據。
- RDB方式數據沒辦法做到實時持久化/秒級持久化。因爲bgsave每次運 行都要執行fork操作創建子進程，屬於重量級操作，頻繁執行成本過高。
禁用持久化
save ""
AOF持久化
AOF（append only file）持久化：以獨立日誌的方式記錄每次寫命令， 重啓時再重新執行AOF文件中的命令達到恢復數據的目的。AOF的主要作用 是解決了數據持久化的實時性，目前已經是Redis持久化的主流方式
AOF的工作流程操作
命令寫入 （append）、文件同步（sync）、文件重寫（rewrite）、重啓加載 （load）。
配置AOF
默認是 no表示關閉 ，yes表示開啓。
- 自動觸發
持久化配置
-
always：每條 Redis 操作命令都會寫入磁盤，最多丟失一條數據，但會使得Redis的性能降低，但數據幾乎是全的，基本不會存在丟失數據問題。
-
everysec：每秒鐘寫入一次磁盤，最多丟失一秒的數據，對存取數據和性能折中，可以滿足大部分使用場景。
-
no：不設置寫入磁盤的規則，根據當前操作系統來決定何時寫入磁盤，一般不採用這種設置。
-
手動觸發
使用bgrewriteaof命令可以手動觸發aof持久化
隨着時間的推移和數據量變大，aof一直在進行持久化，磁盤日誌越來越大，redis重啓速度越來越慢，針對這個問題，Redis提供了AOF重寫功能。
Redis中的數據是有一定限量的，最多不超過物理內存大小，不可能說Redis中的數據無限增長，導致aof也無限增長，到一定的時候Redis就會採用緩存淘汰算法LRU自動將以部分數據從內存中給清除。
AOF 重寫配置
- auto-aof-rewrite-min-size：允許 AOF 重寫的最小文件容量，默認是 64m 。
- auto-aof-rewrite-percentage：AOF 文件重寫的大小比例，默認值是 100，表示 100%，也就是隻有當前 AOF 文件，比最後一次（上次）的 AOF 文件大一倍時，纔會啓動 AOF 文件重寫。
AOF 重寫流程
AOF 是存放每條寫命令的，所以會不斷變大，達到一定的時候，AOF做rewrite操作，會重新生成一個新的AOF文件。
優缺點
AOF 優點
AOF 持久化保存的數據更加完整，AOF 提供了三種保存策略：每次操作保存、每秒鐘保存一次、跟隨系統的持久化策略保存，其中每秒保存一次，從數據的安全性和性能兩方面考慮是一個折中的選擇，也是 AOF 默認的策略，即使發生了意外情況，最多隻會丟失 1s 鐘的數據；
AOF 採用的是命令追加的寫入方式，所以不會出現文件損壞的問題，即使由於某些意外原因，導致了最後操作的持久化數據寫入了一半，也可以通過 redis-check-aof 工具輕鬆的修復；
AOF 持久化文件，非常容易理解和解析，它是把所有 Redis 鍵值操作命令，以文件的方式存入了磁盤。即使不小心使用 flushall 命令刪除了所有鍵值信息，只要使用 AOF 文件，刪除最後的 flushall 命令，重啓 Redis 即可恢復之前誤刪的數據。
AOF 缺點
對於相同的數據集來說，AOF 文件要大於 RDB 文件；
在 Redis 負載比較高的情況下，RDB 比 AOF 性能更好；
RDB 使用快照的形式來持久化整個 Redis 數據，而 AOF 只是將每次執行的命令追加到 AOF 文件中，因此從理論上說，RDB 比 AOF 更健壯。
混合持久化
RDB和AOF持久化各有優缺點，RDB會導致一段時間內的數據丟失，AOF文件會越來越大，會影響Redis的啓動速度，爲了同時兼顧RDB，AOF的優點，Redis在4.0版本之後提供了混合持久化方式。
混合持久化
AOF 重寫時會把 Redis 的持久化數據，以 RDB 的格式寫入到 AOF 文件的開頭，之後的數據再以 AOF 的格式化追加的文件的末尾，如下圖所示。
開啓混合
將no改爲yes即可
混合持久化優缺點
優點
混合持久化結合了 RDB 和 AOF 持久化的優點，開頭爲 RDB 的格式，使得 Redis 可以更快的啓動，同時結合 AOF 的優點，有減低了大量數據丟失的風險。
缺點：
AOF 文件中添加了 RDB 格式的內容，會使得 AOF 文件的可讀性會很差，不容易閱讀；
如果開啓混合持久化，就必須使用Redis 4.0 以及之後版本。
使用混合持久化的時候可以根據自身業務選擇關閉RDB或者AOF，或者關閉持久化。