redis為什麼要持久化？怎麼持久化，持久化的方式有哪些？
1. redis為什麼要做持久化
首先，要知道我們為什麼要對redis做持久化？
因為，redis本身執行時資料儲存在記憶體中，如果不進行持久化，那麼在redis出現非正常原因宕機或者關閉redis的程序或者關閉計算機後資料肯定被會作業系統從記憶體中清掉。
很多人又會問，“明明我們在本地自己搭redis環境的時候沒有多餘的配置操作呀，但是就算自己重啟redis或者重啟計算機後，甚至過了幾個月後，redis中的資料仍然存在哦！？”。
當然，redis本身預設採用了一種持久化方式，即RDB （Redis DataBase）——可以在redis的目錄中找到dump.rdb檔案，這就是使用RDB方式做持久化後生成的資料檔案。所以，redis如果沒有做持久化，在重啟redis後，資料會丟失，而redis預設就採用了一種持久化方式，即RDB。
2. redis怎麼做持久化，持久化的方式有哪些
redis持久化的方式有兩種：RDB（Redis DataBase）和AOF（Append Only File）
2.1.RDB（Redis DataBase）
RDB方式採用的思想是定時將記憶體中的資料進行快照，並寫入dump.rdb檔案當中，這個檔案當中所儲存的就是當前redis環境中的配置以及資料。每次當redis重啟之後，redis會先讀dump.rdb檔案，將資料從硬碟寫入到記憶體中。
-
Redis 呼叫fork函式複製一份子程序. 同時擁有（當前程序）父程序和子程序。
-
父程序繼續接收處理客戶端傳送過來的請求操作，子程序則從記憶體中將資料集寫入到一個臨時 RDB 檔案中。
-
當子程序完成對新 RDB 檔案的寫入時，Redis 用新 RDB 檔案替換原來的 RDB 檔案，並刪除舊的 RDB 檔案。
2.1.1 RDB模式的配置方式
在redis的配置檔案redis.conf中搜索save，這一個save可以設定在指定時間內，更新操作達到了固定次數，就將資料同步到資料檔案，這裡可以寫多個save多條件配合使用。比如以下程式碼所示
# 表示900秒內有一次更改，或者900秒內有10次更改，或者60秒內有10000此更改執行同步操作
save 900 1
save 300 10
save 60 10000
另外，如果想不使用RDB做持久化了，可以不配置任何的save，或者將save配成空字串，如下圖所示。
save ""
2.1.2 dbfilename與dir
在redis的配置檔案中如果使用RDB的方式做持久化，除了要注意save的配置外，還有兩個配置需注意。其中一個是dbfilename，這一個配置表示儲存的快照檔案（資料檔案）的檔名，redis預設為dump.rdb，所以我們看到redis目錄中會有這樣一個檔案，這個檔案中存放了二進位制的內容。另外一個是dir，dir的配置表示了dbfilename所配置的這一個檔案的路徑，這裡最好配一個絕對路徑，因為如果使用了相對路徑，那麼通過不同的方式其啟動redis可能會出現檔案找不到導致資料前後不一致的情況發生。
2.2.AOF（Append Only File）
AOP模式做持久化，把所有的寫操作命令記錄到磁碟檔案中儲存，也就是說使用AOF會將客戶端對於redis的操作（查詢除外）以一個字串的形式記錄到磁碟的檔案中去，而在啟動redis的時候會去讀取這一個檔案，將命令執行。
AOF 檔案與RDB 檔案相比不同的是AOF 檔案並不是一個snapshot （快照）的概念， 他是一個 append 的概念，檔案的資訊會直接新增到檔案的末尾，當然這的方式比上面的RDB檔案的好處就是，通過調整資料的重新整理（同步）方式，是可以做到資料不丟失的，但不利的地方，即使隨著保證資料不丟失的等級升高，對REDIS 本身的效能影響就會越突出。並且AOF 檔案是在系統重啟動，或者CRASH 後，在啟動REDIS後對系統資料進行恢復的一種方式。
2.2.1AOF模式的配置方式
redis預設是關閉AOF模式持久化的，需要開啟，並且預設是每秒來進行與磁碟的互動，如果要使用需要修改一下配置：
# 預設為no，需修改為yes
appendonly yes
# AOF預設的持久化檔案的檔名稱
appendfilename "appendonly.aof"
而指定更新日誌條件的同步策略有三個可選條件，預設每秒進行同步：
# 當作業系統進行資料快取同步到磁碟檔案
# appendfsync no
# 每秒同步一次（預設值，也是最佳的選擇，速度快，可能會丟失一秒以內的資料（最多不過2秒））
appendfsync everysec
# 同步持久化，當資料發生變更時，立即同步到磁碟檔案（效率慢些，能保證資料的完整性）
# appendfsync always
另外，可以配置當持久化的檔案到達一定程度後，進行重寫，為什麼要進行重寫？由於AOF模式持久化記錄的是操作命令，檔案會越來越大，其實可以優化aof檔案，去掉多餘的中間操作命令，比如說當有這兩個命令set key "value1"， set key "value2"依次執行後，實際上要恢復資料只需要執行set key "value2"即可。經過類似的壓縮，可以為原本已經很大的檔案“瘦身”，以下的內容，即為執行此“瘦身”操作的配置。觸發重寫機制為：
# 當AOF的持久化檔案大小的增長率大於此配置時，自動開啟重寫，redis會自動執行“BGREWRITEAOF”命令；
auto-aof-rewrite-percentage 100
# 當AOF的持久化檔案大小大於此配置時，自動開啟重寫，redis會自動執行“BGREWRITEAOF”命令；
auto-aof-rewrite-min-size 3000mb
注：通過fork一個子程序，重新寫一個新的aof檔案，該次重寫不是讀取舊的aof檔案進行復制，而是將讀取記憶體中的redis資料庫，重寫一份aof檔案，有點類似於rdb的快照方式；
2.2.2 AOF模式的優缺點
AOF的優點：
（1）AOF模式可以更好的保護資料不丟失，在redis因為非正常原因掛掉時，其儲存資料的完整度理論上高於RDB模式，因為採用appendfsync everysec去寫入持久化檔案，最多丟失一秒到兩秒的資料；而RDB模式丟失的資料根據其配置的寫入頻率決定；
（2）AOF寫入效能高，這歸功於其是以append-only的方式寫入；
AOF的缺點：
（1）對於同樣的資料，通常AOF檔案的大小回比RDB的要大；
（2）因為AOF存的是命令而不是資料，所以恢復資料時可能較慢。
3. 同時開啟RDB和AOF持久化模式來處理叢集高併發、高頻更新操作的業務場景
如果你的REDIS 是從事寫緩衝的工作，例如經常更新資料，所以在REDIS中進行了資料的更新，在多次的運算和更新後，將最後的結果刷入到傳統的資料庫中，這的確是一個解決高併發，更新值，降低傳統資料庫負擔的方式。例如你一分鐘更新上百次或上千次的值的情況下，在這樣的情況下，你就需要將 RDB 檔案和 AOF 檔案都開啟的，並且隨著你的應用邏輯和你容忍資料可能丟失度的降低，你的RDB 檔案和 AOF 檔案的儲存方式等級都會提高；
例如 RDB 檔案，你是否需要提高下面的RDB 檔案的重新整理率 ，根據重新整理的頻率，調整：
例如，如果寫入的在5秒就有10000次，則不需要調整，如果60秒內寫入9999次，則需要調整一下 save 60 10000 變為 save 60 5000，這樣RDB 的重新整理檔案（同步）的頻率就會提高，滿足你的需求。另外在你CTRL + C 終止REDIS 的情況下(Redis 並未在有)，會強制先將資料刷入到 RDB 檔案，否則除非你 KILL 否則是無法關閉 REDIS的。
像我上面所說，AOF 持久化模式預設是關閉的，需要開啟，並且預設是每秒來進行與磁碟的互動：
所以在雙重的RDB 和AOF 檔案的加持下，在這樣的業務場景下，資料安全是有保證的，如果還想嚴格的不丟失資料，則需要將上圖的設定調整為 appendfsync always 開啟，則任何的操作都會記錄在 appendonly.aof 檔案中，這種同步模式雖然是最安全，但也是效能最差的。
4. 總結
所以REDIS 的持久化可以根據Redis在系統中所承擔的作用來設定，如果是隻讀作為讀緩衝，則可以不需要進行持久化的操作，可以將RDB AOF 檔案關閉，已達到最好的效果，當然你的程式也需要考慮在 REDIS CRASH （崩了）後的資料重新刷入，否則會引起快取雪崩，導致你的實體資料庫 MYSQL ORACLE ,POSTGRESQL SQL SERVER 等資料庫無法承受短期的高頻的資料讀取，而不再有響應。
要不就需要設定 RDB, AOF 檔案，在某些應用場景下，防止丟失資料，或者引起緩衝擊穿後的雪崩問題。
建議如果沒有特殊的要求，需要開啟 RDB AOF 持久化，這樣REDIS 好, 傳統資料庫好，你好我好，大家好。
參考文章：
https://blog.csdn.net/y506798278/article/details/103541097