Redis 是記憶體資料庫，如果不將記憶體中的資料庫狀態保存到磁盤，那么一旦服務器行程退出，服務器中的資料庫狀態也會消失，所以Redis 提供了持久化功能！
RDB（Redis DataBase）
什么是RDB
在指定的時間間隔內將記憶體中的資料集快照寫入磁盤，也就是行話講的Snapshot快照，它恢復時是將快照檔案直接讀到記憶體里，
Redis會單獨創建（fork）一個子行程來進行持久化，會先將資料寫入到一個臨時檔案中，待持久化程序都結束了，再用這個臨時檔案替換上次持久化好的檔案，
整個程序中，主行程是不進行任何IO操作的，這就確保了極高的性能，如果需要進行大規模資料的恢復，且對于資料恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效，
RDB的缺點是最后一次持久化后的資料可能丟失，
Fork
Fork的作用是復制一個與當前行程一樣的行程，新行程的所有資料（變數，環境變數，程式計數器等）
數值都和原行程一致，但是是一個全新的行程，并作為原行程的子行程，
Rdb 保存的是 dump.rdb 檔案
配置位置及SNAPSHOTTING決議
這里的觸發條件機制，我們可以修改測驗一下：
save 180 10 # 180秒內修改10次則觸發RDB
RDB 是整合記憶體的壓縮過的Snapshot，RDB 的資料結構，可以配置復合的快照觸發條件，
默認：
- 1分鐘內改了1萬次
- 5分鐘內改了10次
- 15分鐘內改了1次
如果想禁用RDB持久化的策略，只要不設定任何save指令，或者給save傳入一個空字串引數也可以，
若要修改完畢需要立馬生效，可以手動使用 save 命令！立馬生效 !
其余命令決議
Stop-writes-on-bgsave-error：如果配置為no，表示你不在乎資料不一致或者有其他的手段發現和控制，默認為yes，
rbdcompression：對于存盤到磁盤中的快照，可以設定是否進行壓縮存盤，如果是的話，redis會采用LZF演算法進行壓縮，如果你不想消耗CPU來進行壓縮的話，可以設定為關閉此功能，
rdbchecksum：在存盤快照后，還可以讓redis使用CRC64演算法來進行資料校驗，但是這樣做會增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關閉此功能，默認為yes，
如何觸發RDB快照
1、組態檔中默認的快照配置，建議多用一臺機子作為備份，復制一份 dump.rdb
2、命令save或者是bgsave
- save 時只管保存，其他不管，全部阻塞
- bgsave，Redis 會在后臺異步進行快照操作，快照同時還可以回應客戶端請求，可以通過lastsave命令獲取最后一次成功執行快照的時間，
3、執行flushall命令，也會產生 dump.rdb 檔案，但里面是空的，無意義 !
4、退出的時候也會產生 dump.rdb 檔案！
如何恢復
1、將備份檔案（dump.rdb）移動到redis安裝目錄并啟動服務即可，
2、CONFIG GET dir 獲取目錄，
127.0.0.1:6379> config get dir
dir
/usr/local/bin
優點和缺點
優點：
1、適合大規模的資料恢復，
2、對資料完整性和一致性要求不高，
缺點：
1、在一定間隔時間做一次備份，所以如果redis意外down掉的話，就會丟失最后一次快照后的所有修改，
2、Fork的時候，記憶體中的資料被克隆了一份，大致2倍的膨脹性需要考慮，
RDB小結
-
RDB是一個非常緊湊的檔案，
-
RDB在保存RDB檔案時父行程唯一需要做的就是fok出一個子行程，接下來的作業全部由子行程來做，父行程不需要再做其他10
操作，所以RDB持久化方式可以最大化redis的性能，
-
與AOF相比，在恢復大的資料集的時候，RDB方式會更快一些，
-
資料丟失風險大，
-
RDB需要經常fOrk子行程來保存資料集到硬碟上，當資料集比較大的時候，fok的程序是非常耗時的，可能會導致Redis在一些毫秒級不能回應客戶端請求，
AOF（Append Only File）
什么是AOF
以日志的形式來記錄每個寫操作，將Redis執行過的所有指令記錄下來（讀操作不記錄），只許追加檔案但不可以改寫檔案，redis啟動之扯訓讀取該檔案重新構建資料，換言之，redis重啟的話就根據日志檔案的內容將寫指令從前到后執行一次以完成資料的恢復作業，
Aof保存的是 appendonly.aof 檔案，
配置
appendonly no # 是否以append only模式作為持久化方式，默認使用的是rdb方式持久化，這種方式在許多應用中已經足夠用了
appendfilename "appendonly.aof" # appendfilename AOF 檔案名稱
appendfsync everysec # appendfsync aof持久化策略的配置
# no表示不執行fsync，由作業系統保證資料同步到磁盤，速度最快，
# always表示每次寫入都執行fsync，以保證資料同步到磁盤，
# everysec表示每秒執行一次fsync，可能會導致丟失這1s資料，
No-appendfsync-on-rewrite #重寫時是否可以運用Appendfsync，用默認no即可，保證資料安全性
Auto-aof-rewrite-min-size # 設定重寫的基準值
Auto-aof-rewrite-percentage #設定重寫的基準值
AOF 啟動/修復/恢復
正常恢復：
- 啟動：設定Yes，修改默認的appendonly no，改為yes，
- 將有資料的aof檔案復制一份保存到對應目錄，（config get dir）
- 恢復：重啟redis然后重新加載，
例外恢復：
- 啟動：設定Yes
- 故意破壞 appendonly.aof 檔案！
- 修復： redis-check-aof --fix appendonly.aof 進行修復，
- 恢復：重啟 redis 然后重新加載，
Rewrite
是什么：
?AOF 采用檔案追加方式，檔案會越來越大，為避免出現此種情況，新增了重寫機制，當AOF檔案的大小超過所設定的閾值時，Redis 就會啟動AOF 檔案的內容壓縮，只保留可以恢復資料的最小指令集，可以使用命令 bgrewriteaof ！
重寫原理：
AOF 檔案持續增長而過大時，會fork出一條新行程來將檔案重寫（也是先寫臨時檔案最后再rename），遍歷新行程的記憶體中資料，每條記錄有一條的Set陳述句，重寫aof檔案的操作，并沒有讀取舊的aof檔案，這點和快照有點類似！
觸發機制：
Redis會記錄上次重寫時的AOF大小，默認配置是當AOF檔案大小是上次rewrite后大小的已被且檔案大于64M的觸發，
優點和缺點
優點：
1、每修改同步：appendfsync always 同步持久化，每次發生資料變更會被立即記錄到磁盤，性能較差但資料完整性比較好，
2、每秒同步： appendfsync everysec 異步操作，每秒記錄 ，如果一秒內宕機，有資料丟失，
3、不同步： appendfsync no 從不同步，
缺點：
1、相同資料集的資料而言，aof 檔案要遠大于 rdb檔案，恢復速度慢于 rdb，
2、Aof 運行效率要慢于 rdb，每秒同步策略效率較好，不同步效率和rdb相同，
AOF小結
- AOF檔案時一個只進行追加的日志檔案，
- Redis可以在AOF檔案體積變得過大時，自動地在后臺對AOF進行重寫，
- AOF檔案有序地保存了對資料庫執行的所有寫入操作，這些寫入操作以Redis協議的格式保存，因此AOF檔案的內容非常容易被人讀懂，對檔案進行分析也很輕松，
- 對相同的資料集來說，AOF檔案的體積通常要大于RDB檔案的體積，
- 根據所使用的fsync策略，AOF的速度可能會慢于RDB，
總結
1、RDB 持久化方式能夠在指定的時間間隔內對你的資料進行快照存盤，
2、AOF 持久化方式記錄每次對服務器寫的操作，當服務器重啟的時候會重新執行這些命令來恢復原始的資料，AOF命令以Redis 協議追加保存每次寫的操作到檔案末尾，Redis還能對AOF檔案進行后臺重寫，使得AOF檔案的體積不至于過大，
3、只做快取，如果你只希望你的資料在服務器運行的時候存在，你也可以不使用任何持久化，
4、同時開啟兩種持久化方式
- 在這種情況下，當redis重啟的時候會優先載入AOF檔案來恢復原始的資料，因為在通常情況下AOF檔案保存的資料集要比RDB檔案保存的資料集要完整，
- RDB 的資料不實時，同時使用兩者時服務器重啟也只會找AOF檔案，那要不要只使用AOF呢？作者建議不要，因為RDB更適合用于備份資料庫（AOF在不斷變化不好備份），快速重啟，而且不會有AOF可能潛在的Bug，留著作為一個萬一的手段，
5、性能建議
- 因為RDB檔案只用作后備用途，建議只在Slave上持久化RDB檔案，而且只要15分鐘備份一次就夠了，只保留 save 900 1 這條規則，
- 如果Enable AOF ，好處是在最惡劣情況下也只會丟失不超過兩秒資料，啟動腳本較簡單只load自己的AOF檔案就可以了，代價一是帶來了持續的IO，二是AOF rewrite 的最后將 rewrite 程序中產生的新資料寫到新檔案造成的阻塞幾乎是不可避免的，只要硬碟許可，應該盡量減少AOF rewrite的頻率，AOF重寫的基礎大小默認值64M太小了，可以設到5G以上，默認超過原大小100%大小重寫可以改到適當的數值，
- 如果不Enable AOF ，僅靠 Master-Slave Repllcation 實作高可用性也可以，能省掉一大筆IO，也減少了rewrite時帶來的系統波動，代價是如果Master/Slave 同時倒掉，會丟失十幾分鐘的資料，啟動腳本也要比較兩個 Master/Slave 中的 RDB檔案，載入較新的那個，微博就是這種架構，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/458321.html
標籤：其他
上一篇：SQL查閱筆記——DDL