Redis 數據安全與性能保障

 

數據安全與性能保障

·將數據持久化至硬盤
·將數據複製至其餘機器
·處理系統故障
·reids事務
·非實物型流水線
·診斷性能問題

 

持久化選項：

共享選項，這個選項決定了快照文件和AOF文件的保存位置
dir ./

1. 快照(snapshotting)

快照持久化選項：
save 60 1000
stop-write-on-bgsave-error no
rdbcompression yes
dbfilename dump.rdb

建立快照的方法：
·客戶端能夠經過向redis發送BGSAVE命令來建立一個快照。Redis會調用fork來建立一個子進程，而後子進程負責將快照寫入硬盤，而父進程則繼續處理命令請求
·客戶端還能夠經過向Redis發送save命令來建立一個快照，接到save命令的redis服務器在快照建立完畢以前將再也不相應任何其餘命令，save命令並不經常使用，咱們一般只會在沒有足夠內存區執行bgsave的狀況下，又或者即便等待持久化操做執行完畢也無所謂的狀況下，纔會使用這個命令
·若是用戶設置了save配置選項，好比save 60 1000，那麼從redis最近一次建立快照以後開始算起，當「60秒以內有10000次寫入」，這個條件被知足時，Redis就會自動觸發bgsave命令，若是用戶設置了多個save配置選項，那麼當任意一個save配置選擇所設置的條件被知足時，redis就會觸發一次bgsave
·當redis經過shutdown命令接收到關閉服務器的請求時，或者接收到標準的term信號時，會執行一個save命令，阻塞全部客戶端，不在執行客戶端發送的任何命令，並在save命令執行完畢以後關閉服務器
·當一個redis服務器鏈接另外一個redis服務器，並向對方發送sync命令來開始一個複製操做的時候，若是主服務器目前沒有執行bgsave操做，或者主服務器並不是剛剛執行完bgsave操做，那麼主服務器就會執行basave命令，

使用快照持久化的場景：
·開發服務器上面，考慮儘量下降快照持久化帶來的資源消耗，設置save 900 1 這一條規則。若是服務器距離上此成功超過900秒，而且在此期間執行了至少一次寫入操做，那麼redis就會自動開始一次i新的bgsave操做。
·對日誌進行聚合計算。在對日誌文件進行聚合計算或者對頁面瀏覽量進行分析的時候，咱們惟一須要考慮的就是，若是redis由於崩潰而未能成功建立新的快照，那麼咱們可以承受丟失多長事件之內產生的新數據。
·大數據，當redis存儲數十個GB時，爲了防止redis由於建立子進程而出現停頓，咱們能夠考慮關閉自動保存，轉而經過手動發送bgsave或save來進行持久化。手動發送bgsave以用會引發停頓，惟一不一樣的是用戶能夠經過手動發送bgsave命令來控制停頓出現的事件。

2. 只追加文件(append-only file,AOF)

AOF持久化選擇appendonly no
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

AOF持久化將被執行的寫命令寫道AOF文件的末尾，今後來記錄數據發生的變化。所以，redis只要從頭至尾從新執行一次AOF文件包含的全部寫命令，就能夠恢復AOF文件所記錄的數據集。AOF持久化能夠經過設置代碼清單 appendonly yes配置選項來打開。
appendfsync配置選項對AOF文件的同步頻率的影響。
always 每一個reids寫命令都要同步寫入硬盤，這樣作會嚴重下降redis的速度
everysec 每秒執行一次同步，顯式地將多個寫命令同步到磁盤
no 讓操做系統來決定應該什麼時候進行同步

**固態硬盤和appendfsync always 使用固態硬盤的用戶謹慎使用always選項，由於這個選項讓reids每次值寫入一個命令，而不是像其餘選項那樣一次寫入多個命令。這樣不斷的寫入少許數據的作法有可能會引起嚴重的寫入放大（write amplification)問題，在某些狀況下甚至會將固態硬盤的壽命從原來的幾年下降到幾個月
爲了兼顧數據安全和寫入性能，用戶能夠考慮使用everysec選項，讓reids以每秒一次的頻率對AOF文件進行同步。redis每秒同步一次AOF文件時的性能和不適用任何持久化特性時的性能相差無幾。能夠保證即便系統崩潰，用戶也最多指揮丟失一秒以內產生的數據，當硬盤忙於寫入操做的時候，reids還會優雅地放慢本身的速度以便適應硬盤的最大寫入速度。
使用appendfsync no選項，那麼redis將不對AOF文件執行任何顯式的同步操做，而是由操做系統決定。這個選項通常狀況下不會對reids性能帶來影響。但系統崩潰將致使使用這種選項的redis服務器丟失不定數量的數據。另外若是用戶硬盤處理寫入操做速度不夠快的話，那麼當緩衝區被等待寫入硬盤的數據填滿時，redis的寫入操做將被阻塞。並致使redis處理命令請求速度變慢。通常不推薦使用no

2.1 重寫/壓縮AOF文件

redis會不斷地將被執行的寫命令記錄到AOF文件裏面，因此隨着reids不斷運行，AOF文件不斷增長，redis重啓以後須要從新執行AOF文件，若是AOF文件過大，恢復時間過長。
爲了解決AOF文件不斷增長的問題，用戶能夠向redis發送BGREWRITEAOF命令，這個命令會經過移除AOF文件中的冗餘命令來重寫(rewrite)AOF文件，使AOF文件的提交變得儘量小。BGREWRITEAOF的工做原理和BGSAVE建立快照的工做原理很是類似。刪除一個體積達到數十GB大的舊AOF文件可能會致使操做系統hang住數秒

不管使用AOF持久化，仍是快照持久化，將數據持久化到硬盤上都是很是有必要的，但處理進行持久化以外， 用戶還必須對持久化所得的文件進行備份(最好備份到多個不一樣地方)，這樣才能儘可能避免數據丟失事故發送。若是條件容許的話，最好能將快照文件和最新重寫的AOF文件備份到不一樣的服務器上面。
經過使用AOF持久化或者快照持久化，用戶能夠在系統重啓或者崩潰的狀況下仍然保留數據，隨着負載量上升。或者數據完整性變得愈來愈重要時，用戶可能須要使用複製特性。

 

 

複製：

對Redis的複製相關選項進行配置：

主服務器配置： dir, dbfilename 選項，而且這兩個選項所指示的路徑和文件對於redis進程來講都是可寫的(writeable)
開啓從服務器所必須的選項只有slaveof一個，若是用戶在啓動redis時候指定了一個包含slaveof host port選項的配置文件，那麼redis服務器將根據指定的IP地址和端口號來鏈接主服務器。對於一個正在運行的redis服務器。用戶能夠經過發送slaveof no one 命令來讓服務器終止複製操做，也能夠經過發送slaveof host port命令來讓服務器開始複製一個新的主服務器

Redis複製的啓動過程:

 

 

 Redis在複製進行期間也會盡量地處理接收到的命令請求，單實若是主從服務器之間的網絡帶寬不足，或者主服務器沒有足夠的內存來建立子進程和建立記錄寫命令的緩衝區，那麼redis處理命令請求的效率就會受到影響。在實際中最好仍是讓主服務器只是用50%-65%的內存，留下30%-45%的內存用於執行BGSAVE命令和建立記錄寫命令的緩衝區

**從服務器在進行同步時，會清空本身的全部數據

**Redis不支持主主複製

當多個從服務器嘗試鏈接同一個主服務器的時候，就會出現上圖的兩種狀況中的其中一種

 

 

 

 

 主從鏈

     當讀請求的重要性明顯高於寫請求的中華藥性，並未讀請求的數量遠遠超出一臺Redis服務器能夠處理的範圍時，用戶就須要添加新的從服務器來處理讀請求。隨着負載不斷上升，主服務器可能會沒法快速地更新全部從服務器，或者由於從新鏈接和從新同步從服務器而致使系統超載，爲了緩解這個問題，用戶能夠建立一個由Redis主從節點組成的中間層來分擔主服務器的複製工做：

 

     爲了將數據保存到多臺機器上面，用戶首先須要爲主服務器設置多個從服務器，而後對每一個從服務器設置appendonly yes 選項和 appendfsync everysec 選項(若是有須要的話，也能夠對主服務器進行相同的設置)，這樣的話，用戶就可讓多臺服務器以每秒一次的頻率將數據同步到硬盤上了，但這還只是第一步，由於用戶還必須等待主服務器發送的寫命令到達從服務器，而且在執行後續操做以前，檢查數據是否已經被同步到了硬盤裏面

 

檢驗硬盤寫入

    爲了驗證主服務器是否已經將寫數據發送至從服務器，和用戶須要在向主服務器寫入真正的數據以後，再向主服務器寫入一個惟一的虛構值(unique dummy value)，而後經過檢查虛構值是否存在於從服務器來判斷寫數據是否已經到達從服務器。

    判斷數據是否已經被保存到磁盤裏面，對於每秒同步一次AOF文件的redis服務器來講用戶老是能夠經過等待1秒來確保數據已經被保存到磁盤裏面。更節約時間的作法是，檢查INFO命令輸出結果中aof_pending_bio_fsync屬性的值是否爲0， 若是是的話那麼就表示服務器已經將已知的全部數據都保存到磁盤裏面了。

 

處理系統故障

驗證快照文件和AOF文件

    不管是快照持久化仍是AOF持久化，都提供了再遇到系統故障時進行數據恢復的工具。Redis提供了兩個命令行程序 redis-check-aof 和 redis-check-dump, 他們能夠在系統故障發生以後，檢查AOF文件和快照文件的狀態，並在有須要的狀況下對文件進行修復

    若是用戶在運行reids-check-aof程序時給定了--fix參數，那麼程序將對AOF文件進行修復。程序修復AOF文件的方法很是簡單：它會掃描給定的AOF文件，尋找不正確或者不完整的命令，當發現第一個出錯命令的時候，程序刪除出錯的命令以及位於出錯命令以後的全部命令，只保留那些位於出錯命令以前的正確命令。在大多數狀況下，被刪除的都是AOF文件末尾的不完整的寫命令。

 

更換故障主服務器

假設 A、B兩臺機器運行Redis，其中機器A的reids爲主服務器，而機器B的reids爲從服務器，A掛了，以後想新加C做爲新的主服務器。

步驟： 

一、在機器B發送一個SAVE命令，讓他建立一個新的快照文件

二、接着將這個快照文件發送給機器C，並在機器C上面啓動Redis

三、讓機器B成爲機器C的從服務器。

 

 另外一種建立新的主服務器的方法，就是將從服務器升級(turn)爲主服務器，併爲升級後的主服務器建立從服務器。

 Redis Sentinel ， Redis Sentinel 能夠監視指定的Redis主服務器及其屬下的從服務器，並在主服務器下線時自動進行故障轉移(failover)。

 

Redis 事務

 Redis的事務以特殊命令MULTI爲開始，以後跟着用戶傳入的多個命令，最後以EXEC結束。可是因爲這種簡單的事務在EXEC命令被調用以前不會執行任何實際操做，因此用戶將沒辦法根據讀取到的數據來作決定。