redis的持久化和緩存機制

說道redis，我們可能都會知道了他是一個類似緩存的一個內(nèi)存數(shù)據(jù)庫，我們從未感知到它的存在是因為他很快，為什么非?？欤且驗樗陌l(fā)展到應(yīng)用很快，還有他的反應(yīng)速度也是非常快的。

以前文章我們講到了緩存以及非關(guān)系型數(shù)據(jù)庫的由來，這篇我們來講講redis這種非關(guān)系型數(shù)據(jù)庫用在什么地方，以及他的特色——持久化是怎么實現(xiàn)的。

一、redis的適用環(huán)境

首先作為一個nosql的key—value組成的數(shù)據(jù)庫，它們能存儲的數(shù)據(jù)結(jié)構(gòu)必須是簡單的，因為有關(guān)系的數(shù)據(jù)即使存儲進去之后查詢也是很困難的，并且對于海量的數(shù)據(jù)存儲還是關(guān)系型數(shù)據(jù)庫比較合適。

舉一個把一般數(shù)據(jù)庫數(shù)據(jù)存儲到key-value中的例子：

遵從規(guī)則為 

key  表名：主鍵值：列名value  列值

如果加上表關(guān)系的話還要復(fù)雜好幾倍的。

那么什么樣的數(shù)據(jù)適合存儲在非關(guān)系型數(shù)據(jù)庫中的呢？

1、關(guān)系不是很密切的的數(shù)據(jù)，比如用戶信息，班級信息，評論數(shù)量等等。

2、量比較大的數(shù)據(jù)，如訪問記錄等

3、訪問比較頻繁的數(shù)據(jù)，如用戶信息，訪問數(shù)量，最新微博等

二、持久化

那么這么多，這么重要的數(shù)據(jù)都存儲在內(nèi)存中，如果突然斷電，豈不是很糟糕，于是就有了數(shù)據(jù)的持久化機制，這個其實就是把內(nèi)存中的數(shù)據(jù)存儲到硬盤中，方便數(shù)據(jù)的持續(xù)存在，也可以減少斷電造成的損失。

那么我們怎么持久化數(shù)據(jù)呢？多長時間進行一次持久化呢？

redis 支持兩種持久化方式，一種是 Snapshotting（快照）也是默認方式，另一種是 Append-only file（縮寫 aof）的方式。下面分別介紹：

Snapshotting

快照是默認的持久化方式。這種方式是就是將內(nèi)存中數(shù)據(jù)以快照的方式寫入到二進制文件中,默認的文件名為dump.rdb。

可以通過配置設(shè)置自動做快照持久化的方式。

我們可以配置 redis在 n 秒內(nèi)如果超過 m 個 key 被修改就自動做快照，下面是默認的快照保存配置：

• save 900 1 #900 秒內(nèi)如果超過 1 個 key 被修改，則發(fā)起快照保存
• save 300 10 #300 秒內(nèi)容如超過 10 個 key 被修改，則發(fā)起快照保存
• save 60 10000

下面介紹詳細的快照保存過程：

1.redis 調(diào)用 fork,現(xiàn)在有了子進程和父進程。

2. 父進程繼續(xù)處理 client 請求，子進程負責將內(nèi)存內(nèi)容寫入到臨時文件。由于 os 的實時復(fù)制機制（ copy on write)父子進程會共享相同的物理頁面，當父進程處理寫請求時 os 會為父進程要修改的頁面創(chuàng)建副本，而不是寫共享的頁面。所以子進程地址空間內(nèi)的數(shù)據(jù)是 fork時刻整個數(shù)據(jù)庫的一個快照。

3.當子進程將快照寫入臨時文件完畢后，用臨時文件替換原來的快照文件，然后子進程退出。client 也可以使用 save 或者 bgsave 命令通知 redis 做一次快照持久化。 save 操作是在主線程中保存快照的，由于 redis 是用一個主線程來處理所有 client 的請求，這種方式會阻塞所有client 請求。所以不推薦使用。另一點需要注意的是，每次快照持久化都是將內(nèi)存數(shù)據(jù)完整寫入到磁盤一次，并不是增量的只同步變更數(shù)據(jù)。如果數(shù)據(jù)量大的話，而且寫操作比較多，必然會引起大量的磁盤 io 操作，可能會嚴重影響性能。

AOF方式

由于快照方式是在一定間隔時間做一次的，所以如果 redis 意外 down 掉的話，就會丟失最后一次快照后的所有修改。如果應(yīng)用要求不能丟失任何修改的話，可以采用 aof 持久化方式。

下面介紹 Append-only file:aof 比快照方式有更好的持久化性，是由于在使用 aof 持久化方式時,redis 會將每一個收到的寫命令都通過 write 函數(shù)追加到文件中(默認是 appendonly.aof)。

當 redis 重啟時會通過重新執(zhí)行文件中保存的寫命令來在內(nèi)存中重建整個數(shù)據(jù)庫的內(nèi)容。

當然由于 os 會在內(nèi)核中緩存 write 做的修改，所以可能不是立即寫到磁盤上。這樣 aof 方式的持久化也還是有可能會丟失部分修改。不過我們可以通過配置文件告訴 redis 我們想要通過 fsync 函數(shù)強制 os 寫入到磁盤的時機。

有三種方式如下（默認是：每秒 fsync 一次）

• appendonly yes //啟用 aof 持久化方式
• # appendfsync always //收到寫命令就立即寫入磁盤，最慢，但是保證完全的持久化
• appendfsync everysec //每秒鐘寫入磁盤一次，在性能和持久化方面做了很好的折中
• # appendfsync no //完全依賴 os，性能最好,持久化沒保證

aof 的方式也同時帶來了另一個問題。持久化文件會變的越來越大。

例如我們調(diào)用 incr test命令 100 次，文件中必須保存全部的 100 條命令，其實有 99 條都是多余的。

因為要恢復(fù)數(shù)據(jù)庫的狀態(tài)其實文件中保存一條 set test 100 就夠了。為了壓縮 aof 的持久化文件。

redis 提供了 bgrewriteaof 命令。收到此命令 redis 將使用與快照類似的方式將內(nèi)存中的數(shù)據(jù)以命令的方式保存到臨時文件中，最后替換原來的文件。

redis緩存和兩種持久化機制

redis的優(yōu)點第一個就是速度快它是由c語言實現(xiàn)的基于內(nèi)存讀寫的效率特別高第二個優(yōu)點就是單線程模型所謂的單線程就是一個每個請求都會有一個新的線程來處理請求第三個優(yōu)點就是使用的是非阻塞 i/o（i/o流）

不會再網(wǎng)上浪費時間第四個優(yōu)點就是支持多數(shù)據(jù)類型存儲　　

兩種持久化機制

rdb （Rrdis DataBase）默認的持久化方案是某個時間內(nèi)的間隔執(zhí)行指定次數(shù)的寫操作則會將內(nèi)存中的數(shù)據(jù)存入磁盤中   是以快照方式進行備份緩存    

rdb的優(yōu)點：

1.適合大規(guī)模的數(shù)據(jù)恢復(fù)操作  

2.業(yè)務(wù)操作對數(shù)據(jù)的完整行和一致性要求不高  那么Rdb是最好的選擇，

rdb的缺點：

1.就是數(shù)據(jù)的不完整行和一致性不高，可能是在最后一次備份是宕機，

2：備份時會占用內(nèi)存因為redis在備份的時候會獨立創(chuàng)建一個線程（此時的內(nèi)存中有兩份相同的數(shù)據(jù)）；

Aof：默認不開啟的持久化它的出現(xiàn)就是為了彌補RdB的不足（數(shù)據(jù)不一致）所以它采用的是日志的方式儲存

優(yōu)點：數(shù)據(jù)的完整性和一致性更高

缺點：因為AOF記錄的內(nèi)容多，文件會越來越大，數(shù)據(jù)恢復(fù)也會越來越慢。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論