Redis 用作資料庫

Redis 用作快取，其特點之一就是資料可以丟，只需要保證其回應急速，性能較高！

但是如果把 Redis 做資料庫：資料絕對不能丟的，所以除了保證其速度之外，還必須保證其持久性，資料一定不可以丟失

而我們知道 Redis 處于記憶體，記憶體資料掉電易失！所以如果想要使用 Redis 作為資料庫，必須要保證其持久性

只要是存盤層，為了保證資料安全，都會有如下兩個通用的功能：

• 快照/副本：記錄某一時刻資料庫中所有的正確資料狀況，可以保存在本地主機，也可以拷貝到另一臺遠程主機，一旦出現斷電，甚至服務器癱瘓，也可以根據快斬訓復某一時刻的正常資料
• 日志：用戶發生增刪改的時候，所有的操作都會記錄到一個日志檔案，如果周一資料正常，周二系統上線新功能出現一個致命錯誤，造成大量資金損失，此時可以將系統緊急停服，根據日志將資料回滾到一個正常狀態

官網持久化介紹：http://redis.cn/topics/persistence.html

Redis 提供了不同級別的持久化方式:

• RDB持久化方式能夠在指定的時間間隔能對你的資料進行快照存盤.
• AOF持久化方式記錄每次對服務器寫的操作,當服務器重啟的時候會重新執行這些命令來恢復原始的資料,AOF命令以redis協議追加保存每次寫的操作到檔案末尾，Redis還能對AOF檔案進行后臺重寫,使得AOF檔案的體積不至于過大.
• 如果你只希望你的資料在服務器運行的時候存在,你也可以不使用任何持久化方式.
• 你也可以同時開啟兩種持久化方式, 在這種情況下, 當redis重啟的時候會優先載入AOF檔案來恢復原始的資料,因為在通常情況下AOF檔案保存的資料集要比RDB檔案保存的資料集要完整.

最重要的事情是了解RDB和AOF持久化方式的不同，這也是面試高頻，下面我們就來詳細學習以下 RDB 和 AOF

一、持久化之RDB

RDB 全稱 redis database，在指定的時間間隔內將記憶體中的資料集快照寫入磁盤，也就是行話講的 Snapshot 快照，它恢復時直接將快照檔案直接讀到記憶體里；

Redis會單獨創建（fork）一個子行程來進行持久化，會先將資料寫入到一個臨時檔案中，主行程是不進行任何 IO操作的，它就確保了極高的性能；RDB 檔案是在硬碟上的二進制檔案，是 Redis 在記憶體存盤的資料在某一時刻的快照

1、時點性

系統中不可能每分每秒都進行快照存盤，這樣會大量占用系統資源且毫無意義，所以運維人員一般會定時保存快照

假設使用 RDB 每一小時進行一次快照存盤，假設一個正常系統的快照檔案大小有 10 G，肯定不可能瞬時就能保存到磁盤，那么快照存盤該如何實作呢？我們最先想到的一種方式如下圖：

阻塞保存快照：Redis 主行程阻塞，不再對外提供服務，只進行快照的持久化，這種方式能保證快照的時點性，但是會導致服務停用，這種情況生產環境不會允許發生，所以我們就想讓 Redis 一邊提供服務，一邊進行快照的持久化，處理程序如下：

非阻塞保存快照：會導致時點混亂，無法保存正確的快照資訊，導致資料不一致

那么 RDB 究竟是如何進行持久化呢？——主行程非阻塞繼續提供服務，同時 fork 出子行程進行持久化，處理流程如下：

fork 子行程保存快照：Redis 主行程繼續對外提供服務，同時 fork 出子行程進行快照持久化，在持久化期間，客戶端對主行程的修改對于 fork 出的子行程是看不到的，所以能夠保證快照的時點性，不會發生混亂

補充：fork 是怎么實作的？或者說使用 fork 有什么優勢？

fork 創建子行程不會發生資料的復制，只是會創建參考指標，這樣創建子行程的時候，速度特別快；

只有發生寫操作時才會觸發復制，即 copy on write （寫時復制）機制，不會發生全量的資料修改

fork() 創建子行程優勢：

• 創建子行程時只需要創建指標參考，不需要資料復制，創建速度快
• 并不是全量復制資料，占用空間小

RDB 流程：

2、RDB配置

上面理論學習完之后，Redis 是怎么完成以 RDB 行程持久化的呢？

• 人為觸發：可以通過兩個指令人為觸發
  • save：前臺阻塞，不再提供服務，只進行快照持久化，較少使用，使用場景明確——只有明確什么時間會關機停服維護的時候才可能用到
  • bgsave：后臺異步非阻塞，fork 創建子行程完成快照的持久化
• 組態檔配置 bgsave 規則：
  • save 60 10000：時間達到 60 秒，或者寫運算元達到 10000 次，兩者滿足其一，就會觸發 RDB
  • save 300 10：時間達到 300 秒，或者寫操作到達 10 次，兩者滿足其一，就會觸發 RDB
  • save 900 1：時間達到 900 秒，或者寫運算元達到 1 次，兩者滿足其一，就會觸發 RDB
  • 根據系統的并發量、高峰時點等等靈活設定

3、優缺點

RDB的優點

• RDB是一個非常緊湊的檔案,它保存了某個時間點得資料集,非常適用于資料集的備份,比如你可以在每個小時報保存一下過去24小時內的資料,同時也可以每天保存過去30天的資料,這樣即使出了問題你也可以根據需求恢復到不同版本的資料集.
• RDB是一個緊湊的單一檔案,很方便傳送到另一個遠端資料中心或者亞馬遜的S3（可能加密），非常適用于災難恢復.
• RDB在保存RDB檔案時父行程唯一需要做的就是fork出一個子行程,接下來的作業全部由子行程來做，父行程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
• 與AOF相比，在恢復大的資料集的時候，RDB方式會更快一些.

RDB的缺點

• 資料丟失：如果你希望在redis意外停止作業（例如電源中斷）的情況下丟失的資料最少的話，那么RDB不適合你.雖然你可以配置不同的save時間點(例如每隔5分鐘并且對資料集有100個寫的操作),是Redis要完整的保存整個資料集是一個比較繁重的作業,你通常會每隔5分鐘或者更久做一次完整的保存,萬一在Redis意外宕機,你可能會丟失幾分鐘的資料
• 耗時：RDB 需要經常fork子行程來保存資料集到硬碟上,當資料集比較大的時候,fork的程序是非常耗時的,可能會導致Redis在一些毫秒級內不能回應客戶端的請求.如果資料集巨大并且CPU性能不是很好的情況下,這種情況會持續1秒,AOF也需要fork,但是你可以調節重寫日志檔案的頻率來提高資料集的耐久度.

總結：

二、持久化之AOF

AOF 即 Append-only file，使用追加寫操作

如果說 RDB 是類似于快照/副本，那么 AOF 就是類似于日志，AOF持久化以日志的形式記錄服務器所處理的每一個寫、洗掉操作，查詢操作不會記錄，而且是以文本的方式記錄，可以打開檔案看到詳細的操作記錄

redis中，RDB和AOF可以同時開啟，如果開啟了AOF只會用AOF恢復

因為 AOF 是追加寫，只要服務器不停，日志檔案就會無限膨脹，假設 redis 服務運行了10年，AOF檔案可能達到數十G，甚至數十T大小，此時可能導致記憶體溢位，而且根據這么大的檔案中的指令一條一條的進行資料恢復，耗時將會很長

所以在 Redis 4.0 以后，AOF是一個混合體，將老的資料以 RDB 方式保存到 AOF 檔案中，將增量的以指令的方式 Append 到AOF，既利用了 RDB 的快速，又保證了AOF日志的全量

1、AOF配置

既然作為資料庫，那么每次的寫操作都應該要保存下來，任何一條增刪改操作都不能丟失，但是寫操作都會觸發IO，頻繁的 IO 將會拖慢 redis 的速度，所以 Redis 中對于寫操作有三種級別：

• 無 fsync：不進行同步（不安全）
• 每秒 fsync：每秒進行一次同步（默認方式，既保證資料丟失量少，而且速度不算慢，性能比較均衡）
• 每次寫的時候 fsync：每次寫操作都進行一次同步（頻率過高，拖慢速度）

2、優缺點

AOF 優點

• 使用AOF 會讓你的Redis更加耐久: 你可以使用不同的fsync策略：無fsync,每秒fsync,每次寫的時候fsync.使用默認的每秒fsync策略,Redis的性能依然很好(fsync是由后臺執行緒進行處理的,主執行緒會盡力處理客戶端請求),一旦出現故障，你最多丟失1秒的資料.
• AOF檔案是一個只進行追加的日志檔案,所以不需要寫入seek,即使由于某些原因(磁盤空間已滿，寫的程序中宕機等等)未執行完整的寫入命令,你也也可使用redis-check-aof工具修復這些問題.
• Redis 可以在 AOF 檔案體積變得過大時，自動地在后臺對 AOF 進行重寫： 重寫后的新 AOF 檔案包含了恢復當前資料集所需的最小命令集合， 整個重寫操作是絕對安全的，因為 Redis 在創建新 AOF 檔案的程序中，會繼續將命令追加到現有的 AOF 檔案里面，即使重寫程序中發生停機，現有的 AOF 檔案也不會丟失， 而一旦新 AOF 檔案創建完畢，Redis 就會從舊 AOF 檔案切換到新 AOF 檔案，并開始對新 AOF 檔案進行追加操作，
• AOF 檔案有序地保存了對資料庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式保存， 因此 AOF 檔案的內容非常容易被人讀懂， 對檔案進行分析（parse）也很輕松， 匯出（export） AOF 檔案也非常簡單： 舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 檔案未被重寫， 那么只要停止服務器， 移除 AOF 檔案末尾的 FLUSHALL 命令， 并重啟 Redis ， 就可以將資料集恢復到 FLUSHALL 執行之前的狀態，

AOF 缺點

• 長期運行導致日志檔案體積過大，有可能出現記憶體溢位，而且恢復起來也很慢
• 根據所使用的 fsync 策略，AOF 的速度可能會慢于 RDB

關聯文章：

Redis入門–萬字長文詳解epoll

Redis——詳解五種資料結構

Redis——Redis的進階使用（管道/發布訂閱/事務/布隆過濾器）

Redis——Redis用作快取（記憶體回收/穿透/擊穿/雪崩）