前言
Redis體系學習整理，點我點我
解決問題：redis數據在內存中，機器宕機了斷電了，數據丟失怎麼辦？
Redis作爲Nosql中一員，因其完全基於內存，支持多樣的數據結構，單線程，使用多路複用I/O等特點，逐漸成爲了各企業技術選型中緩存模塊的首選。
因爲數據在內存中，帶來了高性能的同時，也帶來數據易丟失的特點。萬一機器故障宕機，內存中的數據將會丟失，造成難以預估狀態和損失。
所以數據的備份與持久化，就非常有必要了。
所以今天我們來談談，Redis最基本的持久化方案。
持久化數據的常用方案
各系統雖然不同，但是持久化思路是類似的。
最常用的有兩種方式：**複製和日誌。**下面分別介紹一下。
複製（snapshot快照）
將存儲介質中的數據，平移到另一塊存儲介質中。如果存儲的區域比較幾種，是非常非常高效的。 包括大家數據HashMap的Rehash，也會數據搬遷平移的過程。
日誌（操作日誌）
把每條操作，一五一十的記錄下來。一個大家比較熟悉的場景，就是DB中的redolog。 他就是記錄了SQL運行的記錄。在恢復時進行批量操作。
RDB
迴歸到Redis的持久化方式
RDB：redis中的”複製“的模式稱爲RDB， 記錄下內存中二進制數據的快照。
啓動方式
人工啓動
- 指令：sava
* 觸發持久化，存儲到配置的路徑dump.rdb文件中。
* 會阻塞redis線程，線上用肯定崩。 - 指令：bgsave
* 通過操作系統fork一個進程，來異步進行save的操作
配置啓動
如save 60 10000(60秒或者10000次操作)
具體的配置如下：
特殊啓動
* 主從複製時
* 關機shutown時
* 重啓reload時
優缺點
優點
- 緊湊壓縮的二進制的內存數據，存取高效
- 存儲單時間節點上的快照，非常適合全量複製的場景
- 數據恢復明顯快於AOF
缺點
- 無法實時持久化，
- 消耗資源
- 存在一定的RDB文件的兼容問題。
AOF
AOF：redis中的”日誌“的模式被稱爲AOF（append only file），將每條修改內存的指令將會記錄下來。
配置方式在redis.conf文件中有詳細說明，有興趣深入瞭解的可以進文件讀一讀。
開啓方式
appendonly yes
appendsync aways
對應的三種策略：
- always（每次都存）：數據0誤差，性能低下，會成爲瓶頸
- everysec（每秒1次）：
- no （系統配置）
AOF的重寫機制
簡介：
當指令數量特別多的時候，AOF文件會變的巨大。但是並不是所有AOF指令都是有效的，比如如下三條AOF記錄
1：set name1 zhang3
2：set name1 zhang4
3：set name1 zhang5 其實只有這條是內存中的最終狀態。
重寫後就是把1和2幹掉。這樣指令就少了非常多。
啓動命令：
bgrewriteaof，講操作指令存儲到 ”複製擠壓緩衝區“中。
後記
在工作中因爲使用集羣，而集羣的同步，讀寫分離等特點，讓他天生具備了數據備份的特點。所以我們公司的RDB都是默認關閉的。
但是這些知識在集羣的主從複製中，會有非常多的使用。或者說主從複製就是依賴RDB和AOF來完成的。學習這個部分後，我們才能更好的理解集羣和主從複製。
