* ### 一、RDB （RedisDataBase）簡介 ``` 意思就是將整個Reids的數據（通過二進制格式），持久化到磁盤里，注意 —— RDB是Redis默認的持久化機制 ``` 工作原理： ``` 這里是引用fork子進程（默認bgwrite模式下是這個，這樣的話就不會阻塞請求了，因為還有主線程在工作）進行當前數 據的二進制文件寫入磁盤工作。每次都是對當前所有的數據進行二進制文件寫入，然后會替換掉之前老的二進制文件。 （這就有個風險，如果不做定時備份的話，那么如果在替換過程中如果宕機了，整個二進制持久化數據就會全部丟失） ``` 優點： * 直接存儲二進制數據的文件，大數據場景下恢復速度快 * 整個庫Redis只有一個文件 —— 如果做了文件備份方案，比如每天歸檔一次數據，同時歸檔最近30天的數據，那這樣的備份策略就很清晰明了，出現災難性故障也好恢復。 * fork子進程，性能最大化 缺點： * 只有一個文件在不備份的情況下同樣也算是缺點，因為要替換，會造成宕機時文件的丟失風險 * fork子線程，如果數據量巨大，可能導致fork的過程阻塞幾百毫秒到一秒 #### RDB 配置關注點(Redis.conf文件）： ``` # 持久化數據到磁盤之 —— 頻率，格式如下: # save 900 1 900秒內至少有1個key被改變（那就會在900秒的時候執行rdb同步） # save 300 10 300秒內至少有300個key被改變（那就會在900秒的時候執行rdb同步） # save 60 10000 60秒內至少有10000個key被改變 （那就會在60秒的時候執行rdb同步） # save "" 如果要禁用RDB模式就把下面這三行注釋掉，并打開 save "" 的注釋 save 900 1 save 300 10 save 60 10000 # 存儲至本地數據庫時（持久化到rdb文件）是否對這個二進制文件進行壓縮數據，默認為yes rdbcompression yes # RDB后，本地持久化數據庫文件名，默認值為dump.rdb（持久化的數據都會保存在這個文件里然后準備刷盤，可自定義文件名，特別是配置集群的話要改成對應機器的名字，另一個也是好區分） dbfilename dump.rdb # 工作目錄 # 數據庫鏡像備份的文件放置的路徑。 # 這里的路徑跟文件名要分開配置是因為redis在進行備份時，先會將當前數據庫的狀態寫入到一個臨時文件中，等備份完成時， # 再把該該臨時文件替換為上面所指定的文件，而這里的臨時文件和上面所配置的備份文件都會放在這個指定的路徑當中 # # AOF文件也會存放在這個目錄下面 # # 注意這里必須制定一個目錄而不是文件,是因為redis容器中存放快照文件的路徑就是/data dir /data ``` 再次說明：如果要禁用RDB模式就注釋掉三行持久化頻率，并打開save “” 注釋，如下 ``` save "" # save 900 1 # save 300 10 # save 60 10000 ``` ### 二、AOF（AppendOnlyFile）簡介 ``` 顧名思義，（通過原操作語句）追加的方式，增量追加到一個日志文件里。 ``` #### **工作原理：** ``` 根據配置執行原操作語句追加（每次寫入都進行追加/每秒追加一次/永不追加），如果追加滿了（默認64M）則會啟動rewrite機制，老的日志會寫入磁盤，與此同時新開一個臨時日志寫新來的語句，等老的寫完磁盤后，重新開始到老的寫。 ``` #### **優點：** * 更高的安全性，如果數據被篡改了，還可以根據redis-check-aof工具來幫助數據恢復（這個也是參數設置是否開啟的）。 * 數據更完整 * 因為是追加語句的形式，所以相對來說宕機風險小 * 另外如果配置的是每次寫入都進行追加使得持久化數據完整 #### 缺點 * 因為保存的是原始操作語句，在大數據恢復場景下全部要重新執行一遍，所以相對很慢 * 根據同步策略的不同，開啟AOF后的運行效率也會相對慢于RDB（當然盡管這樣每秒同步策略還是比較高效的） #### AOF 配置關注點(Redis.conf文件): # AOF開關 —— 設置為yes則開啟，如果AOF開啟則優先使用AOF ``` appendonly no # AOF文件名稱 (默認: "appendonly.aof") # appendfilename appendonly.aof # Redis支持三種同步AOF文件的策略: # # no: 不進行同步，系統去操作 . Faster. # always: always表示每次有寫操作都進行同步. Slow, Safest. # everysec: 表示對寫操作進行累積，每秒同步一次. Compromise. # # 默認是"everysec"，按照速度和安全折中這是最好的。 # 如果想讓Redis能更高效的運行，你也可以設置為"no"，讓操作系統決定什么時候去執行 # 或者相反想讓數據更安全你也可以設置為"always" # # 如果不確定就用 "everysec". # appendfsync always appendfsync everysec # appendfsync no # AOF策略設置為always或者everysec時，后臺處理進程(后臺保存或者AOF日志重寫)會執行大量的I/O操作 # 在某些Linux配置中會阻止過長的fsync()請求。注意現在沒有任何修復，即使fsync在另外一個線程進行處理 # # 為了減緩這個問題，可以設置下面這個參數no-appendfsync-on-rewrite no-appendfsync-on-rewrite no # Automatic rewrite of the append only file. # AOF 自動重寫機制 # 這個機制類似于RDB的二進制壓縮機制，是用來縮小文件大小的 —— 比如對相同key的多次操作則只會保存最后一次操作，對多次操作，可以用一條語句完成的則改成一條語句.... 具體是會新建一個臨時AOF文件，然后讀取Redis中的數據（不是老的AOF哦），然后進行重寫，寫完后替換老的AOF文件 #關于主從部分，AOF機制是這樣的，如果從在重寫，主進來了新的追加，那么主會寫自己AOF的同時，再寫一份相同的在緩存區，子重寫完后會通知主，那這個時候主會把緩存區的再追加到子AOF文件中 #【重寫的觸發條件】 #1.無rdb、aof的持久化操作 #2.無BGREWRITEAOF進行（手動進行aof重寫操作） #3.AOF文件大小超過閾值，默認1M #4.AOF文件增長率超過閾值，默認100% # 設置 percentage 為0就關閉這個特性 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb ```