PHP實現給文章關鍵詞加連結功能
持久化簡介
什麼是持久化
利用永久性儲存介質將資料進行儲存，在在特定的時間將儲存的資料進行恢復的工作機制稱為持久化。
為什麼要持久化
防止資料意外丟失，保證資料安全。
持久化的功能
Redis是記憶體資料庫，資料都是儲存在記憶體中，為了避免程序退出導致資料的永久丟失，需要定期將Redis中的資料以某種形式(資料或命令)從記憶體儲存到硬碟；當下次Redis重啟時，利用持久化檔案實現資料恢復。除此之外，為了進行災難備份，可以將持久化檔案拷貝到一個遠端位置。
Redis持久化型別
RDB持久化和AOF持久化：前者將當前資料儲存到硬碟，後者則是將每次執行的寫命令儲存到硬碟（類似於MySQL的binlog）。由於AOF持久化的實時性更好，即當程序意外退出時丟失的資料更少，因此AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地。
RDB持久化
RDB概念
RDB持久化是將當前程序中的資料生成快照儲存到硬碟(因此也稱作快照持久化)，儲存的檔案字尾是rdb；當Redis重新啟動時，可以讀取快照檔案恢復資料。
RDB的啟動方式---save
手動執行
命令：save 命令可以儲存資料到硬碟，預設生成dump.rdb快照檔案。
save指令相關配置
- dbfilename dump.rdb
設定本地資料庫檔名，預設為dump.rdb。通常設定為dump-埠號.rdb - dir
設定.rdb 檔案的路徑，通常設定儲存空間較大的目錄中，目錄名為data - rdbcompression yes
設定儲存至本地資料庫時是否壓縮，通常設定開啟狀態。 - rdbchecksum yes
設定是否進行RDB檔案格式校驗，開啟會消耗一定的效能，不開啟儲存會存在資料損壞風險，通常設定為開啟狀態
redis為單執行緒任務執行序列，save指定的執行會阻塞當前redis伺服器，直到當前rdb過程完成位置，線上環境不建議使用。
後臺執行
命令:bgsave ，手動啟動後後臺執行，不會立即操作。由redis 呼叫fork函式生成子程序進行save操作，生成RDB檔案。
bgsave指令相關配置
- 參考save指令相關配置
- stop-writes-on-bgsave-error yes
後臺儲存過程中如果出現錯誤現象，是否停止儲存操作，通常設定為開啟狀態
bgsave是針對save阻塞問題做的優化，redis內部所有涉及到RDB操作都採用bgsave的方式，save命令可以放棄使用。
自動執行
相關配置
save second changes
- 作用：滿足限定時間範圍內key的變化數量達到指定數量即進行持久化。
- second：監控時間範圍，changes：監控key的變化量。
# bgsave
# 900秒：15分鐘內變化一個存一次
save 900 1
# 300秒 5分鐘內變了10個就存一次
save 300 10
# 1分鐘內1萬個變化存一次
save 60 10000
save配置要根據實際業務情況進行設定，頻度過高或過低都會出現效能問題，對於second與changes設定通常具有互補關係，儘量不要設定行包含性關係，save配置實際是執行的bgsave操作。
RDB持久化三種方式對比
| 方式 | save | bgsave |
|---|---|---|
| 讀寫 | 同步 | 非同步 |
| 阻塞客戶端指令 | 是 | 否 |
| 額外記憶體消耗 | 否 | 是 |
| 啟動新程序 | 否 | 是 |
RDB優點
- RDB是一個緊湊壓縮的二進位制檔案，儲存效率高
- RDB內部儲存的是redis在某個時間點的資料快照，非常適合用於資料備份，全量複製等場景
- RDB資料恢復比AOF快
- 應用：伺服器中每X小時執行bgsave備份，並將RDB檔案拷貝到遠端機器中，用於災難恢復
RDB 缺點
- RDB方式無論是執行指令還是配置，無法做到實時持久化，具有較大可能性丟失資料
- bgsave每次執行都要fork操作建立子程序，要犧牲一些效能
- Redis各版本中RDB檔案格式不統一，可能出現各版本之間資料格式無法相容的現象
AOF持久化
RDB儲存的弊端
- rdb儲存資料量較大，效率較低，基於快照思想，每次獨寫都是全部資料，當資料量過大時，影響效率。
- bgsave 基於fork建立子程序，會產生額外消耗
- 突然宕機會影響資料丟失的風險
解決思路
不寫全資料，僅記錄部分資料。（AOF，不記錄資料，對所有操作進行記錄，降低丟失資料風險。）
AOF 概念
- AOF（append only file）持久化：以獨立日誌的方式記錄每次寫命令，啟動時再重新執行AOF檔案中命令達到恢復資料的目的。與RDB相比可以簡單描述為
改記錄資料為記錄資料產生的過程。 - AOF的主要作用時解決了資料持久化的實時性，目前已經是Redis持久化的主流方式。
（RDB和AOF到底用哪個呢？建議優先使用AOF。）
AOF寫資料的三種策略
always（每次）每次寫入操作均同步到AOF檔案中，資料零誤差，效能較低。不建議使用
everysec（每秒）每秒將緩衝區中的指令同步到AOF檔案中，資料準確性較高，效能較高，突然宕機的情況下最多丟失1秒內的資料。 建議使用
no（系統控制）由作業系統控制每次同步到AOF檔案的週期，整體過程不可控。
AOF功能開啟
#appendonly 是否開啟AOF持久化功能，預設no
appendonly yes
#AOF寫資料的策略
appendfsync always|everysec|no
#自定義檔名
appendfilename filename
# dir 檔案路徑，與RDB持久化檔案保持一致就可以了
AOF重寫
隨著命令不斷寫入AOF，檔案會越來越大，為了解決這個問題，redis引入了AOF重寫機制壓縮檔案體積。AOF檔案重寫是將Redis程序內的資料轉化為寫命令同步到AOF檔案的過程。簡單說就是將同一個資料若干個命令執行結果轉化成最終結果資料對應的指令進行記錄。
作用
- 降低磁碟佔用量，提高磁碟利用率
- 提高持久化效率，降低持久化寫時間，提高IO效能
- 降低資料恢復用時，提高資料恢復效率
AOF重寫規則
- 程序內已超時的資料不再寫入檔案
- 忽略無效指令，重寫時使用程序內資料直接生成，這樣新的AOF檔案只保留最終資料的寫入命令
如del key1、hdel key2、srem key3、set key4 111、set key4 222等 - 對同一資料的多條寫命令合併為一條命令。
為防止資料量過大造成緩衝區溢位，對list set hash zset等型別，每條最多寫入64個元素
重寫配置
-
手動重寫
bgrewriteaof -
自動重寫
#條件設定 auto-aof-rewrite-min-size size auto-aof-rewrite-percentage percent # 自動重寫觸發對比引數（info persistence獲取具體信aof_base_size息） aof_current_size aof_base_size #自動寫觸發條件 aof_current_size>uto-aof-rewrite-min-size (aof_current_size-aof_base_size)/aof_base_size>=auto-aof-rewrite-percentage percent -
aof常用配置
#是否開啟AOF appendonly yes # AOF檔名 appendfilename "appendonly.aof" # RDB檔案和AOF檔案所在目錄 dir /data # fsync持久化策略 appendfsync everysec # AOF重寫期間是否禁止fsync；如果開啟該選項，可以減輕檔案重寫時CPU和硬碟的負載（尤其是硬碟），但是可能會丟失AOF重寫期間的資料；需要在負載和安全性之間進行平衡 no-appendfsync-on-rewrite no
檔案重寫觸發條件之一 百分比
auto-aof-rewrite-percentage 100
檔案重寫觸發提交之一 大小
auto-aof-rewrite-min-size 64mb
如果AOF檔案結尾損壞，Redis啟動時是否仍載入AOF檔案
aof-load-truncated yes
## RDB與AOF的區別
| 持久化方式 | RDB | AOF |
| ------------ | ------------------ | ------------------ |
| 佔用儲存空間 | 小（資料級：壓縮） | 大（指令集：重寫） |
| 儲存速度 | 慢 | 快 |
| 恢復速度 | 快 | 慢 |
| 資料安全性 | 會丟失資料 | 依據策略決定 |
| 資源消耗 | 高/重量級 | 低/輕量級 |
| 啟用優先順序 | 低 | 高 |
### RDB與AOF之間的選擇
* 對資料非常敏感，建議使用預設的AOF持久化
* AOF持久化策略使用everysecond，每秒鐘fsync一次，該策略redis仍可以保持很好的處理效能，當出現問題是，最多丟失0-1秒內的資料
* 注意：由於AOF檔案儲存體積較大，且恢復速度較慢
* 資料呈現階段有效性，件以使用RDB持久化方案
* 資料可以良好的做到階段內無丟失（開發或運維手工維護），且恢復速度較快，階段點資料恢復通常採用RDB方案
* 注意：利用RDB實現緊湊的資料持久化會使Redis效能降低
* 綜合對比
* RDB與AOF的選擇實際上是在做一種權衡，每種都有利有弊
* 如不能承受數分鐘以內的資料丟失，對業務資料非常敏感，選用AOF
* 如能承受，且追求大資料的恢復速度，選用RDB
* 災難恢復選用RDB
* 雙保險策略，同時開啟RDB和AOF，重啟後，redis優先使用AOF來恢復資料，降低資料丟失的量本文來自部落格園，作者：La0jin，轉載請註明原文連結：https://www.cnblogs.com/la0jin/p/15027623.html