REDIS 學與思系列---redis持久化

前言

本文主要回答以下問題:mysql

  • Redis如何作持久化的?redis

    Redis的持久化支持2種方式:rdb 和aof 兩種方式。這個和mysql的binlog支持幾種格式有點相似。好比mysql binlog支持(row(數據快照,二進制格式),statement(文本,存修改操做的sql語句),mix)等等多種格式。rbd相似於mysql的row,aof相似於mysql的statement。
    複製代碼

目錄

  • RDB 持久化
  • AOF 持久化
  • 兩種持久化方式比較

RDB 持久化

RDB持久化是將當前進程中的數據生成快照保存到硬盤(所以也稱做快照持久化),保存的文件後綴是rdb;當Redis從新啓動時,能夠讀取快照文件恢復數據。
複製代碼
  • 觸發條件算法

    RDB持久化的觸發分爲手動觸發和自動觸發兩種。
    複製代碼
  • 1)手動觸發 經過手動執行save命令和bgsave命令均可以生成RDB文件。sql

    save命令會阻塞Redis服務器進程,直到RDB文件建立完畢爲止,在Redis服務器阻塞期間,服務器不能處理任何命令請求。而bgsave命令會建立一個子進程,由子進程來負責建立RDB文件,父進程(即Redis主進程)則繼續處理請求。bgsave命令執行過程當中,只有fork子進程時會阻塞服務器,而對於save命令,整個過程都會阻塞服務器,所以save已基本被廢棄,線上環境要杜絕save的使用,後文中也將只介紹bgsave命令。此外,在自動觸發RDB持久化時,Redis也會選擇bgsave而不是save來進行持久化。
    複製代碼

    備註: fork 子進程時會阻塞,而fork的過程與redis進程佔用的內存大小有關,佔用內存過大時,fork阻塞時間會變長。緩存

  • 2)自動觸發安全

    自動觸發是經過redis的配置文件中save m n 進行條件配置的,指的是在m秒內發生n次修改時,會觸發進行bgsave。
    複製代碼

其中save 900 1的含義是:當時間到900秒時,若是Redis數據發生了至少1次變化,則執行bgsave;save 300 10和save 60 10000同理。當三個save條件知足任意一個時,都會引發bgsave的調用。
複製代碼

提示: 由於自動觸發須要知足必定的配置條件後才能觸發,於是在redis出現故障時,可能部分數據尚未被持久化到rdb文件中,於是會出現數據丟失服務器

  • 觸發bgsave的其餘方式
    • 在主從複製場景下,若是從節點執行全量複製操做,則主節點會執行bgsave命令,並將生成的rdb文件發送給從節點;網絡

    • 執行shutdown命令時,自動執行rdb持久化。app

RDB文件

RDB文件是通過壓縮的二進制文件。Redis默認採用LZF算法對RDB文件進行壓縮。雖然壓縮耗時,可是能夠大大減少RDB文件的體積,所以壓縮默認開啓
複製代碼

RDB經常使用配置總結

save m n:bgsave自動觸發的條件;若是沒有save m n配置,至關於自動的RDB持久化關閉,不過此時仍能夠經過其餘方式觸發。

stop-writes-on-bgsave-error yes:當bgsave出現錯誤時,Redis是否中止執行寫命令;設置爲yes,則當硬盤出現問題時,能夠及時發現,避免數據的大量丟失;設置爲no,則Redis無視bgsave的錯誤繼續執行寫命令,當對Redis服務器的系統(尤爲是硬盤)使用了監控時,該選項考慮設置爲no。

rdbcompression yes:是否開啓RDB文件壓縮。

rdbchecksum yes:是否開啓RDB文件的校驗,在寫入文件和讀取文件時都起做用;關閉checksum在寫入文件和啓動文件時大約能帶來10%的性能提高,可是數據損壞時沒法發現。

dbfilename dump.rdb:RDB文件名。

dir ./:RDB文件和AOF文件所在目錄。
複製代碼

AOF持久化

RDB持久化是將進程數據寫入文件,而AOF持久化(即Append Only File持久化),則是將Redis執行的每次寫命令記錄到單獨的日誌文件中,當Redis重啓時再次執行AOF文件中的命令來恢復數據。相比RDB,AOF的優先級要高。運維

  • 開啓AOF

    Redis服務器默認開啓RDB,關閉AOF;要開啓AOF,須要在配置文件中配置:

    appendonly yes
    複製代碼

AOF 命令執行過程:

  • 命令寫入(append)

    Redis先將寫命令追加到緩衝區,而不是直接寫入文件,主要是爲了不每次有寫命令都直接寫入硬盤,致使硬盤IO成爲Redis負載的瓶頸。
    複製代碼
  • 文件寫入(write)和文件同步(sync)

    Redis提供了多種AOF緩存區的同步文件策略,策略涉及到操做系統的write函數和fsync函數,說明以下:
     爲了提升文件寫入效率,在現代操做系統中,當用戶調用write函數將數據寫入文件時,操做系統一般會將數據暫存到一個內存緩衝區裏,當緩衝區被填滿或超過了指定時限後,才真正將緩衝區的數據寫入到硬盤裏。這樣的操做雖然提升了效率,但也帶來了安全問題:若是計算機停機,內存緩衝區中的數據會丟失;所以系統同時提供了fsync、fdatasync等同步函數,能夠強制操做系統馬上將緩衝區中的數據寫入到硬盤裏,從而確保數據的安全性。
    複製代碼

AOF緩存區的同步文件策略由參數appendfsync控制,各個值的含義以下:

always:命令寫入aof_buf後當即調用系統fsync操做同步到AOF文件,fsync完成後線程返回。這種狀況下,每次有寫命令都要同步到AOF文件,硬盤IO成爲性能瓶頸,Redis只能支持大約幾百TPS寫入,嚴重下降了Redis的性能;即使是使用固態硬盤(SSD),每秒大約也只能處理幾萬個命令,並且會大大下降SSD的壽命。

 no:命令寫入aof_buf後調用系統write操做,不對AOF文件作fsync同步;同步由操做系統負責,一般同步週期爲30秒。這種狀況下,文件同步的時間不可控,且緩衝區中堆積的數據會不少,數據安全性沒法保證。

everysec:命令寫入aof_buf後調用系統write操做,write完成後線程返回;fsync同步文件操做由專門的線程每秒調用一次。everysec是前述兩種策略的折中,是性能和數據安全性的平衡,所以是Redis的默認配置,也是咱們推薦的配置。
複製代碼
  • 文件重寫(rewrite)

    隨着時間流逝,Redis服務器執行的寫命令愈來愈多,AOF文件也會愈來愈大;過大的AOF文件不只會影響服務器的正常運行,也會致使數據恢復須要的時間過長。
    複製代碼

文件重寫的觸發,分爲手動觸發和自動觸發:

手動觸發:

直接調用bgrewriteaof命令,該命令的執行與bgsave有些相似:都是fork子進程進行具體的工做,且都只有在fork時阻塞。
複製代碼

自動觸發:

根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數,以及aof_current_size和aof_base_size狀態肯定觸發時機。

auto-aof-rewrite-min-size:執行AOF重寫時,文件的最小體積,默認值爲64MB。

auto-aof-rewrite-percentage:執行AOF重寫時,當前AOF大小(即aof_current_size)和上一次重寫時AOF大小(aof_base_size)的比值。

只有當auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個參數同時知足時,纔會自動觸發AOF重寫,即bgrewriteaof操做。
複製代碼
  • AOF 經常使用配置項:

    appendonly no:是否開啓AOF
    
    appendfilename "appendonly.aof":AOF文件名
    
    dir ./:RDB文件和AOF文件所在目錄
    
    appendfsync everysec:fsync持久化策略
    
    no-appendfsync-on-rewrite no:AOF重寫期間是否禁止fsync;若是開啓該選項,能夠減輕文件重寫時CPU和硬盤的負載(尤爲是硬盤),可是可能會丟失AOF重寫期間的數據;須要在負載和安全性之間進行平衡
    
    auto-aof-rewrite-percentage 100:文件重寫觸發條件之一
    
    auto-aof-rewrite-min-size 64mb:文件重寫觸發提交之一
    
    aof-load-truncated yes:若是AOF文件結尾損壞,Redis啓動時是否仍載入AOF文件
    複製代碼

兩種持久化方式的比較

RDB和AOF各有優缺點:
複製代碼

RDB持久化:

優勢:RDB文件緊湊,體積小,網絡傳輸快,適合全量複製;恢復速度比AOF快不少。固然,與AOF相比,RDB最重要的優勢之一是對性能的影響相對較小

缺點:RDB文件的致命缺點在於其數據快照的持久化方式決定了必然作不到實時持久化,而在數據愈來愈重要的今天,數據的大量丟失不少時候是沒法接受的,所以AOF持久化成爲主流。此外,RDB文件須要知足特定格式,兼容性差(如老版本的Redis不兼容新版本的RDB文件)

AOF持久化

與RDB持久化相對應,AOF的優勢在於支持秒級持久化、兼容性好,缺點是文件大、恢復速度慢、對性能影響大。

小結

本文簡單的總結了一下redis的持久化策略以及相關配置。 參考資料:

mp.weixin.qq.com/s?__biz=MzI…

<<redis 開發與運維>>

相關文章
相關標籤/搜索