如何使用redis實現持久化

如何使用redis實現持久化？很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

RDB

RDB就是持久化的一種手段，把內存中數據在某些條件下寫到磁盤中去。那么在哪些條件下寫入呢？不可能無腦寫入，來一個寫一個，影響性能，也不能等老半天才寫一個，萬一中間宕機了，數據全丟失，還不如用memcached。在redis的配置里有著這樣的一段配置：

save 900 1

save 300 10

save 60 10000

很關鍵的一段配置，這時RDB持久化的核心。意思是：

1.如果900秒時，有1個key變化（插入或者更新），我就同步到磁盤一下

2.如果300秒時，有10個key變化（插入或者更新），我就同步到磁盤一下

3.如果60秒時，有10000個key變化（插入或者更新），我就同步到磁盤一下

這些時間點和變化的數量是怎么知道的，這時有另外兩個極為關鍵的東西，一個叫dirty計數器，一個叫lastsave（上次save的時間），dirty計數器專門記錄從上次save后變化key的數量，lastsave記錄執行save的時間，舉個例子剛開始時間是time1，dirty是0，這時有20個key發生了變化，dirty是20，然后現在的時間是time2，time2-time1 >= 300,滿足第二個條件，這時內存中的數據會save一下，同時dirty清為0，然后再等待條件觸發。

如果我60秒內有10萬個key，那么問題來了，一下大量磁盤io來臨，這時redis主進程就會阻塞，期間的所有的命令都不執行，這哪能行，于是就來了一個叫bgsave的，它是redis主進程fork出來的一個子進程，專門執行rdb的持久化工作的。

保存的文件格式是二進制格式的，萬一數據庫宕機，恢復不需要人為干預，redis會自動讀取磁盤文件。

AOF

與RDB不同，AOF存儲的是你執行的命令，當aof功能打開的時候，執行的更新命令不會直接寫到aof文件中去，而是先寫到一個aof buf中，我們知道不能一直往buf中寫，buf也是內存啊，那么何時才能同步到磁盤中去呢？redis中也有這樣一段配置

appendfsync always

appendfsync everysec

appendfsync no

意思是：

1.只要有更新的命令我就同步

2.如果上次同步時間距離現在超過一秒就同步

3.不同步，等待操作系統自己判斷（什么時候我有空我才同步）

分析下，第一種io頻繁，io壓力大，但丟失數據的概率最小，第二種io壓力不是很大，最多也就丟失1秒左右的數據，第三中io壓力很小，丟失數據概率太大。綜合考慮，一般第二種。但還有個問題，我執行了100次INCR num，按道理num就是100，aof中也有100個同樣的命令，沒毛病，那么請問執行100次INCR num和SET num 100有什么區別，同樣的結果前者多了99倍的空間，很浪費啊，于是就出現了AOF重寫，它是怎么做到的。很簡單：首先從數據庫讀取現在的值，然后用一條記錄代替，這就是AOF重寫的原理。重寫很花時間，所以也是子進程來處理。重寫的過程中，如果有新的命令來臨怎么辦，老辦法，寫buf緩沖，重寫完成后，把buf中的命令追加到新的aof中，然后用新的aof替代老的aof，就實現了重寫。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。