Redis是一種面向“key-value”類型數據的分布式NoSQL數據庫系統，具有高性能、持久存儲、適應高并發應用場景等優勢。它雖然起步較晚，但發展卻十分迅速。?

近日，Redis的作者在博客中寫到，他看到的所有針對Redis的討論中，對Redis持久化的誤解是最大的，于是他寫了一篇長文來對Redis的持久化進行了系統性的論述。文章主要包含三個方面：Redis持久化是如何工作的、這一性能是否可靠以及和其它類型的數據庫比較。以下為文章內容：?

一、Redis持久化是如何工作的？?

什么是持久化？簡單來講就是將數據放到斷電后數據不會丟失的設備中，也就是我們通常理解的硬盤上。首先我們來看一下數據庫在進行寫操作時到底做了哪些事，主要有下面五個過程：?

• 客戶端向服務端發送寫操作（數據在客戶端的內存中）。
• 數據庫服務端接收到寫請求的數據（數據在服務端的內存中）。
• 服務端調用write這個系統調用，將數據往磁盤上寫（數據在系統內存的緩沖區中）。
• 操作系統將緩沖區中的數據轉移到磁盤控制器上（數據在磁盤緩存中）。
• 磁盤控制器將數據寫到磁盤的物理介質中（數據真正落到磁盤上）。

故障分析?

寫操作大致有上面5個流程，下面我們結合上面的5個流程看一下各種級別的故障：?

• 當數據庫系統故障時，這時候系統內核還是完好的。那么此時只要我們執行完了第3步，那么數據就是安全的，因為后續操作系統會來完成后面幾步，保證數據最終會落到磁盤上。
• 當系統斷電時，這時候上面5項中提到的所有緩存都會失效，并且數據庫和操作系統都會停止工作。所以只有當數據在完成第5步后，才能保證在斷電后數據不丟失。

通過上面5步的了解，可能我們會希望搞清下面一些問題：?

• 數據庫多長時間調用一次write，將數據寫到內核緩沖區？
• 內核多長時間會將系統緩沖區中的數據寫到磁盤控制器？
• 磁盤控制器又在什么時候把緩存中的數據寫到物理介質上？

對于第一個問題，通常數據庫層面會進行全面控制。而對第二個問題，操作系統有其默認的策略，但是我們也可以通過POSIX API提供的fsync系列命令強制操作系統將數據從內核區寫到磁盤控制器上。對于第三個問題，好像數據庫已經無法觸及，但實際上，大多數情況下磁盤緩存是被設置關閉的，或者是只開啟為讀緩存，也就是說寫操作不會進行緩存，直接寫到磁盤。建議的做法是僅僅當你的磁盤設備有備用電池時才開啟寫緩存。?

數據損壞?

所謂數據損壞，就是數據無法恢復，上面我們講的都是如何保證數據是確實寫到磁盤上去，但是寫到磁盤上可能并不意味著數據不會損壞。比如我們可能一次寫請求會進行兩次不同的寫操作，當意外發生時，可能會導致一次寫操作安全完成，但是另一次還沒有進行。如果數據庫的數據文件結構組織不合理，可能就會導致數據完全不能恢復的狀況出現。?

這里通常也有三種策略來組織數據，以防止數據文件損壞到無法恢復的情況：?

• 第一種是最粗糙的處理，就是不通過數據的組織形式保證數據的可恢復性。而是通過配置數據同步備份的方式，在數據文件損壞后通過數據備份來進行恢復。實際上MongoDB在不開啟操作日志，通過配置Replica Sets時就是這種情況。
• 另一種是在上面基礎上添加一個操作日志，每次操作時記一下操作的行為，這樣我們可以通過操作日志來進行數據恢復。因為操作日志是順序追加的方式寫的，所以不會出現操作日志也無法恢復的情況。這也類似于MongoDB開啟了操作日志的情況。
• 更保險的做法是數據庫不進行舊數據的修改，只是以追加方式去完成寫操作，這樣數據本身就是一份日志，這樣就永遠不會出現數據無法恢復的情況了。實際上CouchDB就是此做法的優秀范例。

1、Redis的第一個持久化策略：RDB快照?

Redis支持將當前數據的快照存成一個數據文件的持久化機制。而一個持續寫入的數據庫如何生成快照呢。Redis借助了fork命令的copy on write機制。在生成快照時，將當前進程fork出一個子進程，然后在子進程中循環所有的數據，將數據寫成為RDB文件。?

我們可以通過Redis的save指令來配置RDB快照生成的時機，比如你可以配置當10分鐘以內有100次寫入就生成快照，也可以配置當1小時內有1000次寫入就生成快照，也可以多個規則一起實施。這些規則的定義就在Redis的配置文件中，你也可以通過Redis的CONFIG SET命令在Redis運行時設置規則，不需要重啟Redis。?

Redis的RDB文件不會壞掉，因為其寫操作是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，然后通過原子性rename系統調用將臨時文件重命名為RDB文件，這樣在任何時候出現故障，Redis的RDB文件都總是可用的。?

同時，Redis的RDB文件也是Redis主從同步內部實現中的一環。?

但是，我們可以很明顯的看到，RDB有它的不足，就是一旦數據庫出現問題，那么我們的RDB文件中保存的數據并不是全新的，從上次RDB文件生成到 Redis停機這段時間的數據全部丟掉了。在某些業務下，這是可以忍受的，我們也推薦這些業務使用RDB的方式進行持久化，因為開啟RDB的代價并不高。 但是對于另外一些對數據安全性要求極高的應用，無法容忍數據丟失的應用，RDB就無能為力了，所以Redis引入了另一個重要的持久化機制：AOF日志。?

2、Redis的第二個持久化策略：AOF日志?

AOF日志的全稱是Append Only File，從名字上我們就能看出來，它是一個追加寫入的日志文件。與一般數據庫不同的是，AOF文件是可識別的純文本，它的內容就是一個個的Redis標準命令。比如我們進行如下實驗，使用Redis2.6 版本，在啟動命令參數中設置開啟AOF功能：?

代碼?

./redis-server?--appendonly?yes??

然后我們執行如下的命令：?

代碼?

redis?127.0.0.1:6379>?set?key1?Hello??

OK??

redis?127.0.0.1:6379>?append?key1?"?World!"??

(integer)?12??

redis?127.0.0.1:6379>?del?key1??

(integer)?1??

redis?127.0.0.1:6379>?del?non_existing_key??

(integer)?0??

這時我們查看AOF日志文件，就會得到如下內容：?

代碼?

$?cat?appendonly.aof??

*2??

$6??

SELECT??

$1??

0??

*3??

$3??

set??

$4??

key1??

$5??

Hello??

*3??

$6??

append??

$4??

key1??

$7??

?World!??

*2??

$3??

del??

$4??

key1??

可以看到，寫操作都生成了一條相應的命令作為日志。其中值得注意的是最后一個del命令，它并沒有被記錄在AOF日志中，這是因為Redis判斷出 這個命令不會對當前數據集做出修改。所以不需要記錄這個無用的寫命令。另外AOF日志也不是完全按客戶端的請求來生成日志的，比如命令 INCRBYFLOAT 在記AOF日志時就被記成一條SET記錄，因為浮點數操作可能在不同的系統上會不同，所以為了避免同一份日志在不同的系統上生成不同的數據集，所以這里只將操作后的結果通過SET來記錄。?

AOF重寫?

你可以會想，每一條寫命令都生成一條日志，那么AOF文件是不是會很大？答案是肯定的，AOF文件會越來越大，所以Redis又提供了一個功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一條記錄的操作只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的多次操作。其生成過程和RDB類似，也是fork一個進程，直接遍歷數據，寫入新的AOF臨時文件。在寫入新文件的過程中，所有的寫操作日志還是會寫到原來老的 AOF文件中，同時還會記錄在內存緩沖區中。當重完操作完成后，會將所有緩沖區中的日志一次性寫入到臨時文件中。然后調用原子性的rename命令用新的 AOF文件取代老的AOF文件。?

二、Redis持久化性能是否可靠？?

從上面的流程我們能夠看到，RDB是順序IO操作，性能很高。而同時在通過RDB文件進行數據庫恢復的時候，也是順序的讀取數據加載到內存中。所以也不會造成磁盤的隨機讀取錯誤。?

而AOF是一個寫文件操作，其目的是將操作日志寫到磁盤上，所以它也同樣會遇到我們上面說的寫操作的5個流程。那么寫AOF的操作安全性又有多高呢？實際上這是可以設置的，在Redis中對AOF調用write寫入后，何時再調用fsync將其寫到磁盤上，通過appendfsync選項來控制，下面appendfsync的三個設置項，安全強度逐漸變強。?

1、appendfsync no?

當設置appendfsync為no的時候，Redis不會主動調用fsync去將AOF日志內容同步到磁盤，所以這一切就完全依賴于操作系統的調試了。對大多數Linux操作系統，是每30秒進行一次fsync，將緩沖區中的數據寫到磁盤上。?

2、appendfsync everysec?

當設置appendfsync為everysec的時候，Redis會默認每隔一秒進行一次fsync調用，將緩沖區中的數據寫到磁盤。但是當這一 次的fsync調用時長超過1秒時。Redis會采取延遲fsync的策略，再等一秒鐘。也就是在兩秒后再進行fsync，這一次的fsync就不管會執行多長時間都會進行。這時候由于在fsync時文件描述符會被阻塞，所以當前的寫操作就會阻塞。?

所以，結論就是：在絕大多數情況下，Redis會每隔一秒進行一次fsync。在最壞的情況下，兩秒鐘會進行一次fsync操作。?

這一操作在大多數數據庫系統中被稱為group commit，就是組合多次寫操作的數據，一次性將日志寫到磁盤。?

3、appednfsync always?

當設置appendfsync為always時，每一次寫操作都會調用一次fsync，這時數據是最安全的，當然，由于每次都會執行fsync，所以其性能也會受到影響。?

對于pipelining有什么不同？?

對于pipelining的操作，其具體過程是客戶端一次性發送N個命令，然后等待這N個命令的返回結果被一起返回。通過采用pipilining 就意味著放棄了對每一個命令的返回值確認。由于在這種情況下，N個命令是在同一個執行過程中執行的。所以當設置appendfsync為everysec 時，可能會有一些偏差，因為這N個命令可能執行時間超過1秒甚至2秒。但是可以保證的是，最長時間不會超過這N個命令的執行時間和。?

三、和其它數據庫的比較?

上面操作系統層面的數據安全我們已經講了很多，其實，不同的數據庫在實現上都大同小異?？傊?#xff0c;最后的結論就是，在Redis開啟AOF的情況下，其單機數據安全性并不比這些成熟的SQL數據庫弱。?

在數據導入方面的比較?

這些持久化的數據有什么用，當然是用于重啟后的數據恢復。Redis是一個內存數據庫，無論是RDB還是AOF，都只是其保證數據恢復的措施。所以 Redis在利用RDB和AOF進行恢復的時候，都會讀取RDB或AOF文件，重新加載到內存中。相對于MySQL等數據庫的啟動時間來說，會長很多，因為MySQL本來是不需要將數據加載到內存中的。?

但是相對來說，MySQL啟動后提供服務時，其被訪問的熱數據也會慢慢加載到內存中，通常我們稱之為預熱，而在預熱完成前，其性能都不會太高。而Redis的好處是一次性將數據加載到內存中，一次性預熱。這樣只要Redis啟動完成，那么其提供服務的速度都是非?？斓?。?

而在利用RDB和利用AOF啟動上，其啟動時間有一些差別。RDB的啟動時間會更短，原因有兩個，一是RDB文件中每一條數據只有一條記錄，不會像 AOF日志那樣可能有一條數據的多次操作記錄。所以每條數據只需要寫一次就行了。另一個原因是RDB文件的存儲格式和Redis數據在內存中的編碼格式是一致的，不需要再進行數據編碼工作。在CPU消耗上要遠小于AOF日志的加載

轉載于:https://www.cnblogs.com/xiaobaoTribe/p/10985697.html

總結

以上是生活随笔為你收集整理的深入理解Redis的持久化机制和原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。