Redis持久化意義
我們在網際網路場景應用裡，緩存服務是必不可少了，提高讀寫性能，對DB流量保護等。那麼，常見的緩存服務就有redis、memcache等。那麼，其中，redis最大的一個特點，就是支援持久化。支援持久化的意義在于什麼呢？舉一個例子，當我們的緩存服務當機了，再重新開機的時候，如果沒有持久化機制，那麼重新開機後記憶體中就丢失了當機前的所有資料，沒有了緩存命中，接下來所有的請求都會打到DB上，發生雪崩，你會發現應用剛啟動又報錯了。有了持久化這種容災機制，我們就不必擔心，大面積丢失命中問題。
持久化實作
redis的持久是怎麼實作的呢，首先redis支援兩種持久化方式：rdb（資料全量的快照）,aof（append only 操作指令）。
rdb
先說說rdb的流程原理。在redis.conf裡預設有rdb觸發的定時規則，如圖
預設的觸發規則為，60s内有1W條資料change，300s（5min）内有10條資料change，900s（15min）内有1條資料change。都會觸發redis 執行 fork函數 複制出一個子程序，來進行快照操作生成目前時刻記憶體中全量資料的rdb檔案。rdb是一個資料的壓縮檔案。當啟動redis時，redis又可以根據rdb檔案把資料初始化到記憶體中。由于，rdb的定時觸發規則，我們可以備份不同版本的資料。
當然，這個定時觸發規則，我們也可以根據自己的實際應用場景做調配。但要注意：1，觸發太頻繁會加重磁盤io操作。2，如果間隔太長，有可能會導緻較多資料丢失，另外，如果cpu處理能力不夠強大，加上資料集較大fork的子程序執行io時間較長，會影響用戶端服務，出現卡頓（這是一個坑）。
aof
aof的原理是，會把對redis的指令操作記錄到aof檔案中。流程是當對redis有新增資料指令時，首先redis會把指令append到Linux的os cache中，再由fsync政策覺定持久化到磁盤上（預設為每秒）。 另外，fsync政策有3種可配：1，always（來一條，持久化一條），2，everysec（每秒把os cache資料sync到磁盤上），3，no（隻在os cache中，持久化靠作業系統自身政策）。 always，資料持久化有保證，資料不丢失，但吞吐性能大降。 everysec，因為是每秒，是以會丢失前一秒資料，但性能良好。 no，雖然性能最優，但依靠作業系統持久機制，不可控，不穩定。
由于，aof這種方式是把指令都append到一個檔案中，檔案打到一定，會觸發rewrite機制。 觸發rewirte auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb rewirte，首先，redis會觸發垃圾回收機制。比如LRU算法，清除後的資料會重寫成一個新的aof檔案，那麼在rewirte過程中有新增的資料會先持久化到就aof檔案上，當新aof同步完，再把rewirte過程中新增的資料指令再同步給新的aof。
擴充 我們可以根據，redis的持久化機制，做一些備份政策。比如，弄一台遠端的雲服務做冷備伺服器，按照RDB的各個版本按時間備份，以便錯誤資料故障恢複等。也可以，自己寫較複雜shell把aof的檔案按照rewirte節點前copy走備份。這裡有一個深坑，要注意一下，當aof和rdb同時存在時，那redis預設按照aof檔案去初始化記憶體資料，再去覆寫掉rdb檔案，作者本人就掉過坑。是以，應該怎麼處理，你懂的！