redis持久化的兩種方式及其優缺點

企業級redis集群架構：海量資料，高併發、高可用

持久化主要是做災難恢復，資料恢復，也可以歸類到高可用的乙個環節裡面去

比如redis整個掛了，然後redis就不可用了，你要做的事情是讓redis盡快變得可用

重啟redis，盡快讓他對外提供服務，但是沒做資料備份，即使redis啟動了，也不可用啊，資料讀沒了

大量的請求過來，快取全部無法命中，在redis裡面根本找不到資料，這個時候就死定了，快取雪崩問題，所有請求都沒有辦法在redis中命中，就會去mysql資料庫這種資料源頭中去找，一下子mysql承接高併發，然後就掛了

mysql掛了，都沒辦法找資料恢復到redis裡面去

把redis持久化做好，備份和恢復方案做到企業及的程度，那麼即使redis故障了，也可以通過備份資料，快速恢復，一旦恢復立即對外提供服務

redis持久化方式：rdb和aof

rdb：

1）對redis中的資料執行週期性的持久化

2）rdb檔案可以有多個，大小達到一定程度會分檔案儲存

3）適合做冷備

aof:

1）對redis的寫命令日誌進行備份

2）只會存在1個aof檔案

3）可以做到丟失的資料盡可能少

4）redis在恢復資料時，會以aof中檔案作為最優先的恢復方式

rdb持久化優點

1）會生成多個資料檔案，每個資料檔案代表了某乙個時刻中redis的資料，這種多個資料檔案的方式，非常適合做冷備，可以定時將這種完整的資料檔案傳送到一些雲安全儲存上去

2）rdb對redis對外提供的讀寫服務，影響非常小，可以讓redis保持高效能，因為redis主程序只需fork乙個子程序，讓子程序執行磁碟io操作來進行rdb持久化即可

3）相對於aof的持久化機制來說，直接基於rdb資料檔案來重啟和恢復redis程序，更加快速

rdb持久化的缺點

1）如果想要在redis故障時，盡可能少的丟失資料，那麼rdb沒有aof好，一般來說，rdb資料快照檔案，都是每個5分鐘，或者更長時間生成一次，redis死機會丟失最近一段時間的資料

2）rdb每次在fork子程序來執行rdb快照資料檔案生成的時候，如果資料檔案特別大，可能會導致對客戶端暫停服務數毫秒或者數秒

aof持久化機制的優點

1）可以更好的保護資料不丟失，一般每隔1秒，通過乙個後台執行緒執行一次fsync操作，最多丟失1秒鐘的資料

3）檔案過大時，出現後台重寫操作，也不會影響客戶端的讀寫。因為rewrite log的時候，會對其中的指令進行壓縮，建立出乙份需要恢復資料的最小日誌出來。再建立新日誌檔案的時候，老的日誌檔案還是照常寫入。當新的merge後的日誌檔案ready的時候，再交換新老日誌檔案即可。

aof持久化的缺點

1）對於同乙份資料來說，aof日誌檔案通常比rdb資料快照檔案更大，因為add和del同乙個key都會進行儲存

2）aof開啟後，支援的寫qps會比rdb支援的寫qps低，因為aof一般會配置成每秒fsync一次日誌檔案

3）aof發生過bug，通過aof記錄日誌，進行資料恢復的時候，沒有恢復一模一樣的資料出來。