什么是Redis的持久化

我們知道Redis的數據都存儲在內存中，如果服務器突然宕機，那么內存數據將會全部消失，為了防止這種情況出現，利用一套機制來保證數據不會因為故障而丟失，我們將這種機制稱之為Redis的持久化機制，該機制主要目的是將內存數據存入到硬盤中

Redis 提供兩種持久化機制RDB（Redis DataBase）和AOF（Append-Only File）機制。

RDB-快照

快照是最簡單的Redis持久化模式，也就是生成某個時間點的數據集，生成RDB文件，可以看到RDB文件中的數據是非常緊湊的，所以在恢復數據的時候讀取也是非常快的

觸發RDB快照的方式有兩種

手動觸發

通過手動執行bgsave/save，顯示觸發生成快照

• save命令：阻塞當前Redis服務器，直到RDB過程完成為止，對于內存 比較大的實例會造成長時間阻塞，線上環境不建議使用

• bgsave命令：Redis進程執行fork操作創建子進程，RDB持久化過程由子 進程負責，完成后自動結束。阻塞只發生在fork階段，一般時間很短

配置參數自動觸發

自動觸發有以下幾種情況：

• 使用save相關配置，命令save m n。表示m秒內數據集存在n次修改時，自動觸發bgsave
• 從節點執行全量復制操作，主節點自動執行bgsave生成RDB文件發送給從節點
• 執行debug reload命令重新加載Redis時，自動觸發save命令
• 執行shutdown命令時，如果沒有開啟AOF持久化功能自動執行bgsave

注意：在RDB持久化的過程中有兩個問題需要考慮

RDB快照過程中Redis是否會停止對外提供服務

如果沒有停止服務，如何處理新的請求

針對上述問題我們先看一下RDB的持久化執行流程

根據上圖我們可以看到主線程主要是fork一個子線程來進行持久化操作，同時父子線程會共享一個數據區域，而且該區域設置為read-only方式，該方式下讀的時候沒有問題，但是寫的時候會觸發copyonwrite機制來進行，接下來我們看看什么是 COW(Copy On Write) 機制 。

COW(Copy On Write) 機制

COW(Copy On Write) 機制屬于操作系統處理多進程下的一種機制，Redis在持久化的時候會調用glibc函數fork一個子進程。父子進程會共享內存里面的代碼段和數據段。

所以持久化的時候是完全交給子進程，而父進程繼續處理客戶端請求，所以在持久化的時候操作系統采用COW機制進程數據段頁面的分離。數據段是由很多操作系統的頁面組合而成，當父進程對其中一個頁面進行數據修改的時候，先將被父子線程共享的這一個頁面復制并分離出來，然后直接對復制的頁面進程修改，而此時子進程對應的頁面是沒有修改的。

Redis采用該機制的簡單流程如下。Lunix在fork之后，操作系統會將父進程的所有內存也權限設置為read-only，然后子進程的地址空間指向父進程。當父進程只讀時沒有問題，當有寫內存時，CPU硬件檢測到內存也是read-only，于是會觸發頁異常中斷（page-fault），陷入到操作系統的一個中斷例程。中斷例程中，操作系統采用cow機制會觸發異常的也復制一份，于是父子進程各自持有獨立的一份，如果這個時候又大量寫入操作，會產生大量的分頁錯誤（頁異常中斷page-fault），從而觸發cow機制。

之所以稱之為快照也就是說在子進程創建的那一時刻開始。內存的數據就固定下來了，不會發生變化。

RDB的優缺點

優點：

性能最大化，fork子進程來完成寫操作，讓主進程繼續處理命令，保證了redis的高性能

重啟恢復數據的時候。數據量比較大時候，Redis直接解析RDB二進制文件，生成對應的數據存儲在內存中，比AOF的啟動效率更高

缺點

數據安全性低，因為是間隔一段時間進行持久化，如果在持久化之間發生了故障，會丟失數據，這也就決定了該方式更適合在數據要求不嚴謹的時候采用

系統性能耗費，根據上文提到的Redis執行cow機制時，可以看到大量的分頁錯誤會耗費不少性能在復制上。

AOF（Append Only File - 僅追加文件）

根據上文，快照在某些情況下不是可行的選擇，所以AOF很好的支持了。

AOF 原理

該方式非常簡單：也就是修改內存的操作命令都會記錄下來，加入AOF日志記錄都是Redis實例創建以來的所有修改性指令序列，所以恢復也就是順序執行所有執行。

Redis使用單線程相應命令，如果每次寫AOF文件命令都追加到硬盤，會極大地影響處理性能，所以Redis會先寫入到aof緩沖區，根據用戶配置的同步硬盤策略寫入到aof文件中，這個策略可以通過appendfsync參數配置，

• always：每一次寫操作都會調用一次fsync，這時數據是最安全的，當然，由于每次都會執行fsync，所以其性能也會受到影響
• no：Redis不會主動調用fsync去將AOF日志內容同步到磁盤，所以這一切就完全依賴于操作系統的調試了。對大多數Linux操作系統，是每30秒進行一次fsync，將緩沖區中的數據寫到磁盤上。
• everysec：Redis會默認每隔一秒進行一次fsync調用，將緩沖區中的數據寫到磁盤。但是當這一次的fsync調用時長超過1秒時。Redis會采取延遲fsync的策略，再等一秒鐘。也就是在兩秒后再進行fsync，這一次的fsync就不管會執行多長時間都會進行。這時候由于在fsync時文件描述符會被阻塞，所以當前的寫操作就會阻塞。

注意，這也是影響Redis性能的參數之一，建議采用 appendfsync everysec（缺省方式）

AOF重寫

所謂重寫，Redis在長期運行過程中日志會越來越大，在恢復的時候會非常好使，所以我們的目的就是對日志做瘦身

會從以下幾點做瘦身：

無效命令可以刪除，比如del key1、hdel key2、srem keys、set a111、set a222等，直接用最終的數據生成命令保存下來就行

多條命令可以刪除，如：lpush list a、lpush list b、lpush list c可以轉化為：lpush list a b c

等等，就不列舉了

Redis使用bgrewriteaof指令做瘦身，主要也是開辟一個子進程對內存遍歷轉化為一系列指令，并序列化到新的文件中，接下來再將操作期間的增量AOF日志追加到新的日志文件中，最終替換了舊的。

AOF重寫機制兩種方式觸發

手動觸發：bgrewriteaof指令

自動觸發：根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數確定自動觸發時機

• auto-aof-rewrite-min-size：表示運行AOF重寫時文件最小體積，默認為64MB。

• auto-aof-rewrite-percentage：代表當前AOF文件空間 （aof_current_size）和上一次重寫后AOF文件空間（aof_base_size）的比值。

auto-aof-rewrite-min-size????100auto-aof-rewrite-percentage??64mb復制代碼

如上代表AOF文件的大小小于64mb(默認值)，且當前AOF文件大小比基準大小增長了100%時會觸發。

AOF優缺點

優點

數據安全，aof持久化配置appendfsync屬性，有always，每執行一次命令操作就記錄到aof文件一次

缺點

數據集大的時候，比如RDB啟動效率低

混合持久化（Redis 4.0版本）

我們根據上文知道，RDB恢復會存在大量數據，AOF恢復性能又較慢，所以在Redis4.0中，采用混合持久化，將RDB文件內存和增量的AOF日志文件放在一起，這里的AOF日志不再是全量日志。而是自持久化開始到持久化結束的這段時間的增量日志，通常較小，重啟效率因此大幅得到提升

加載的時候，首先會識別AOF文件是否以REDIS字符串開頭，如果是就按照RDB格式加載，加載完成后繼續按AOF加載剩余的部分

總結

總體來說，如果你想轉行從事程序員的工作，Java開發一定可以作為你的第一選擇。但是不管你選擇什么編程語言，提升自己的硬件實力才是拿高薪的唯一手段。

如果你以這份學習路線來學習，你會有一個比較系統化的知識網絡，也不至于把知識學習得很零散。我個人是完全不建議剛開始就看《Java編程思想》、《Java核心技術》這些書籍，看完你肯定會放棄學習。建議可以看一些視頻來學習，當自己能上手再買這些書看又是非常有收獲的事了。

這些視頻如果需要的話，可以無償分享給大家，點擊這里即可免費領取

Java核心技術》這些書籍，看完你肯定會放棄學習。建議可以看一些視頻來學習，當自己能上手再買這些書看又是非常有收獲的事了。

這些視頻如果需要的話，可以無償分享給大家，點擊這里即可免費領取

總結

以上是生活随笔為你收集整理的深入浅出mysql第三版pdf百度云，工作感悟的全部內容，希望文章能夠幫你解決所遇到的問題。

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