第四天, 內填充, 邊框, 三角形, 外邊距,, 盒模型的計算, 背景屬性, 選擇器進階, css的三大特性, 標籤分類及轉化
每隔一段時間Redis會把資料持久化到硬碟進行資料的儲存。其中持久化方案包括RDB和AOF模式 ,其中RDB全稱為Redis DataBase,AOF全稱為Append Only File。Redis預設使用的是RDB方式進行資料的持久化。
RDB
從英文的全稱可以看出區別,RDB是把所有的資料進行以快照的方式進行持久化。快照檔案的生成可以使用兩個命令來完成,即save
和bgsave
。
127.0.0.1:6379> help save SAVE - summary: Synchronously save the dataset to disk since: 1.0.0 group: server 127.0.0.1:6379> help bgsave BGSAVE - summary: Asynchronously save the dataset to disk since: 1.0.0 group: server
從summary可以看出,save
是以同步的方式把資料以快照方式寫入磁碟,而bgsave
是非同步的寫入。所謂同步即redis在執行rdb備份時,期間redis不能響應外部的請求直到完成本次備份。而非同步是redis呼叫Linux的核心函式fork()生成一個子程序,並且由該子程序來完成資料的持久化,所以備份時redis仍然可以響應外部的請求。
持久化配置
配置檔案redis.conf
中的save即為bgsave
模式,官方配置檔案中有save三種預設的選項配置:
218 save 900 1 #每900秒(15分鐘)有1個鍵更新就執行一次bgsave 219 save 300 10 #每300秒(5分鐘)有10個鍵更新就執行一次bgsave 220 save 60 10000 #每60秒(1分鐘)有10000個鍵更新就執行一次bgsave
三種配置不是互斥的,只要有一個滿足了條件就會觸發備份操作。同時設定多個save是為了匹配不同的場景需要。若按照上面配置save 60 10000
進行,並且redis在一分鐘內持續更新了10000個鍵,但是伺服器卻在第59.99秒發生宕機,那後果可想而知:這一分鐘內更新的所有鍵將全部丟失並且無法恢復。生產環境需要根據請求的調整合適的配置。
備份檔案配置
253 dbfilename dump.rdb
263 dir ./
預設情況下備份儲存在./dump.rdb中,預設在配置檔案redis.conf
所在的目錄。可以手動更改配置檔案備份的地址和檔名重啟redis,也可以在redis命令列工具中熱變更,比如將備份調整為/var/redis/redis-6379.rdb:
127.0.0.1:6379> CONFIG SET dir /var/redis
OK
127.0.0.1:6379> CONFIG SET dbfilename resid-6379.rdb
OK
完成後可以使用CONFIG REWRITE
將變更合併到配置檔案中。
其它選項
241 rdbcompression yes
將備份出的rdb檔案按照LZF演算法進行壓縮,可以大大減少備份檔案的體積,此選項是預設開啟的。當然為了節省CPU時間,可以改為no,但是快照檔案的大小會大大增加。
250 rdbchecksum yes
預設情況下,一串CRC64d的檢驗和會追加到快照檔案的尾部,這個可以使得快照檔案更耐破壞。但是在儲存和載入快照檔案會損失約10%的效能。
AOF
與RDB模式不同的是,AOF僅僅儲存修改命令,類似mysql的bin-log日誌。也就是說RDB儲存的是資料快照,AOF儲存的是修改命令。預設情況下AOF是關閉的,Redis僅使用RDB方式持久化資料。
699 appendonly no
在命令列中使用 CONFIG SET appendonly yes
來開啟AOF持久化模式,同樣的可以使用CONFIG REWRITE
將變更合併到配置檔案中。
相應的持久化資料會預設儲存到appendonly.aof中,路徑即是dir
中定義的路徑。如果變更在寫入過程中伺服器發生了宕機,變更的命令位於來不及寫入到.aof檔案,也會造成資料丟失。Redis通過fsync()系統呼叫將執行的命令寫入磁碟,這裡Redis也提供了三種模式用於控制fsync的速度。
持久化配置
728 appendfsync always
729 appendfsync everysec
730 appendfsync no
always:Redis每次操作都寫入.aof檔案中,最慢但也是最安全的選項,幾乎不存在資料的丟失
no:Redis從不執行fsync()系統呼叫,而是讓作業系統決定什麼時候將資料寫入磁碟,最快但資料存在資料丟失風險
everysecond:每秒呼叫一次fsync(),折中方案也是預設配置
日誌重寫
如果生產環境開啟了AOF模式,那麼生成的.aof檔案會變得越來越大。aof重寫的主要包括1.刪除抵消的命令 2.合併重複的命令,比如說一個Python Django專案使用Redis來作為計數器,該計數器在5分鐘發生了1000次的值更新,但是資料集中包含最終值的鍵只有一個,而在AOF中卻包含1000個條目,不需要其中的999個條目來重建當前狀態。所以這999個條目可以在重建時可以全部刪除。
Redis支援一個有趣的功能:它可以在後臺fork()出一個子程序重建AOF,而不會中斷對客戶端的服務。每當您發出BGREWRITEAOF,Redis都會編寫最短的命令序列來重建記憶體中的當前資料集。除了手動的在Redis命令列中手動執行外,還可以在配置檔案中宣告自動重建的配置。
770 auto-aof-rewrite-percentage 100
771 auto-aof-rewrite-min-size 64mb
auto-aof-rewrite-min-size 64mb
指的是資料量達到64mb就觸發執行一次重寫操作,如果redis啟動時資料量大於64mb,則會自動進行一次重寫操作。此後這條配置項將不再有效。
auto-aof-rewrite-percentage 100
此第一次重寫後後當資料再次達到100%,即128mb時,會再次執行一次重寫操作,以此類推,不斷執行自動重寫。
如果auto-aof-rewrite-percentage 0
,則會禁用自動重寫
auto-aof-rewrite-min-size
的值不能太小,否則會頻繁重寫造成效能降低
總結
- RDB永續性按指定的時間間隔執行資料集的時間點快照
- AOF永續性會記錄伺服器接收的每個寫入操作,這些操作將在伺服器啟動時再次播放,以重建原始資料集。使用與Redis協議本身相同的格式記錄命令,並且僅採用追加方式。當日志太大時,Redis可以在後臺重寫日誌
- 如果希望,只要您的資料在伺服器執行時就一直存在,則可以完全禁用永續性。當做memcache使用
- 可以在同一例項中同時合併AOF和RDB。請注意,在這種情況下,當Redis重新啟動時,AOF檔案將用於重建原始資料集,因為它可以保證是最完整的