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.1.3 RDB的優缺點
2.2. AOF（Append Only File）
AOP模式做持久化，把所有的寫操作命令記錄到磁盤文件中保存，也就是說使用AOF會將客戶端對於redis的操作（查詢除外）以一個字符串的形式記錄到磁盤的文件中去，而在啟動redis的時候會去讀取這一個文件，將命令執行。
AOF 文件與RDB 文件相比不同的是AOF 文件並不是一個snapshot （快照）的概念， 他是一個 append 的概念，文件的信息會直接添加到文件的末尾，當然這的方式比上面的RDB文件的好處就是，通過調整數據的刷新（同步）方式，是可以做到數據不丟失的，但不利的地方，即使隨着保證數據不丟失的等級升高，對REDIS 本身的性能影響就會越突出。並且AOF 文件是在系統重啟動，或者CRASH 后，在啟動REDIS后對系統數據進行恢復的一種方式。
2.2.1 AOF模式的配置方式
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. 總結
1. RDB和AOF是互補的，相比RDB，AOF的粒度更細，只做增量的操作，而不像RDB的全量替換；
2. REDIS 的持久化可以根據Redis在系統中所承擔的作用來設置，如果是只讀作為讀緩沖，則可以不需要進行持久化的操作，可以將RDB AOF 文件關閉，已達到最好的效果，當然你的程序也需要考慮在 REDIS CRASH （崩了）后的數據重新刷入，否則會引起緩存雪崩，導致你的實體數據庫 MYSQL ORACLE ,POSTGRESQL SQL SERVER 等數據庫無法承受短期的高頻的數據讀取，而不再有響應。
要不就需要設置 RDB, AOF 文件，在某些應用場景下，防止丟失數據，或者引起緩沖擊穿后的雪崩問題。
建議如果沒有特殊的要求，需要打開 RDB AOF 持久化，這樣REDIS 好, 傳統數據庫好，你好我好，大家好。
參考文章：
https://blog.csdn.net/y506798278/article/details/103541097
https://blog.csdn.net/liuhuayang/article/details/105743430