1.持久化的意義
災難恢復，數據恢復。可以歸類到類似高可用的環節；如果redis掛了，重啓redis，從磁盤上讀取數據到內存中
2.RDB和AOF兩種持久化機制
RDB，12：00，redis中有100條數據，生成RDB文件，有100條數據
12：05 ，redis中有150條數據，生成RDB文件，有150條
週期性的，生成一份完整的快照。
AOF，每次redis中寫入一條數據，先寫到 os cache中，再寫入磁盤文件 AOF文件。redis每隔固定時間，調用系統fsync,
強制將cache中的數據刷入磁盤文件中。對每條寫入命令作爲日誌，以append-only模式寫入日誌文件中。可以通過回放aof日誌中的寫入指令來重構整個數據集
redis中數據有一定限量，aof不能無限增長，redis中的數據到達一定數量時，採用緩存淘汰算法，LRU（最不經常使用）.，自動將一部分數據從內 存中清除。當aof大到一定時候，AOF做rewrite（重寫）操作（基於當時內存中的數據，構造更小的AOF文件，刪除舊AOF文件）。可能存在一種情況，redis中50w數據（淘汰過後），aof100萬，此時重寫aof，aof數據量變小。aof的一定程度？
如果同時使用2中機制，redis會使用AOF重構數據
3.RDB持久化機制的優點
（1）RDB會生成多個數據文件（全量快照），每個文件代表某一個時刻中redis的數據。非常適合做冷備份，可以將完整數據發送到遠程安全存儲上。 AOF 冷備份，需要藉助腳本
（2）RDB 對redis 對外提供的讀寫服務，影響非常小，可以讓redis保持高性能，redis主進程只需要fork一個子進程，讓子進程執行磁盤IO操作進行持久化。
RDB每次寫，都是寫redis內存，週期性IO
AOF，每次都要寫文件，
（3）相對於AOF，RDB數據文件啓功和恢復redis進程更快；AOF存放的指令日誌，做數據恢復時候，需要回放和執行所有指令日誌。RDB 就是一份數據文件，恢復時直接加載到內存中
4.RDB持久化缺點
（1）可能存在丟失數據問題，週期性備份，會失去最近週期的數據
（2）生成數據文件過大時，可能會導致對客戶端提供服務暫停數毫秒，甚至秒。一般不要讓RDB的間隔太長
5.AOF持久化機制
（1）可以更好的保護數據不丟失，一般AOF每隔一秒，通過後臺線程執行一次fsync操作，最多丟失1秒的數據
（2）AOF日誌文件以append-only模式寫入，沒有磁盤尋址開銷，寫入性能非常高，文件不易破損，即使文件尾部破損，也容易恢復
（3）後臺重寫，不影響客戶端的讀寫。在創建新的日誌文件時，老的日誌文件照常寫入。當新的merge後的日誌文件ready的時候，再交換新老日誌文件即可
（4）AOF日誌文件的命令通過非常可讀的方式進行記錄。可以通過拷貝AOF文件（未重寫），將部分命令刪除，再將AOF放回去，恢復文件。
6.AOF缺點
（1）對於同一份數據，aof日誌文件通常比RDB快照文件更大
（2）aof的寫qps比RDB的寫qps低，aof一般配置成每秒fsync一次日誌文件
（3）數據恢復的時候比較慢，做冷備份，定期備份不方便
7.RDB持久化配置
redis.conf文件中，配置 持久化（默認開啓）
save 60 1000, 每隔60s，如果超過1000個key發生了變更，就生成一個新的dump.rdb文件。snapshotting(檢查點）
可以設置多個檢查點。
也可以手動調用save 或bgsave命令，同步或異步執行rdb快照生成
RDB持久化機制工作流程：
（1）redis根據配置，嘗試生成rdb快照文件
（2）fork一個子進程出來
（3）子進程嘗試將數據dump到臨時的rdb快照文件中
（4）rdb文件生成後，替換舊的快照。每次生成新的快照，都會覆蓋之前的老快照
RDB數據恢復測試流程
（1）設置幾個key，通過 redis-cli shutdown 方式停止redis服務 ，該方式是redis安全退出的模式，redis會將內存中（並非追加）的數據立即生成一份完整的rdb快照。 通過cat dump.rdb可查看，該文件位置可在 redis.conf中 dir 向配置，默認 ./。
（2）kill -9 方式殺死redis進程，redis可能會丟失數據
（3）手動設置幾個save檢查點，寫入幾條數據，殺死進程看rdb文件是否存在數據。
redis 啓動命令：reids-server redis.config (一定要帶上redis.conf,否則新配置的文件不生效）
8 AOF持久化配置
默認關閉，打開： appendonly yes 。在生產環境，默認要打開aof
可以配置aof的fsync策略，有3種， 每次寫入一條數據就執行fsync,每隔一秒執行fsync,不主動執行fsync
appendfsync always: 每次寫入一條數據就執行fsync，性能低
appendfsync everysec:每秒將 os cache 中的數據fsync到磁盤，常用，生產用 ，可以上萬QPS
appendfsync no: 由操作系統策略寫入磁盤，不可控
redis重啓，優先使用 aof文件恢復。
aof自動重寫策略：auto-aof-rewrite-percentage 100, 增長百分比（相對上次的aof文件大小）閾值，超過則進程重寫
auto-aof-rewrite-min-size 64mb ,上條規則執行的條件，aof文件最小64mb，超過觸發上條規則
AOF重寫流程
（1）redis fork 一個子進程
（2）子進程基於當前內存數據，創建一個新的aof日誌文件
（3）客戶端寫入，將日誌保存舊aof日誌文件，同時在內存中寫入日誌
（4）子進程寫完新日誌文件後，redis主進程將內存中的新日誌追加到新aof文件
（5）新的日誌文件替換舊 的日誌文件
9數據恢復和備份思路
（1）RDB和AOF同時工作，同一時刻只允許 一種工作機制進行 備份
（2）如果dump.rdb 和aof文件同時存在，redis重啓只會恢復aof中的文件。
停止redis，如果配置文件中開啓了aof，即使aof文件不存在，redis自動創建aof文件，使用空的aof文件恢復，數據不存在。 需要先關掉 aof ，重啓redis才能恢復RDB文件中的數據。此時可以使用命令行，熱修改redis配置aof（將數據刷入aof）。但是redis的配置文件沒有被持久化修改。此時停止redis，開啓aof，重啓redis
命令： config get appendonly 查看aof開關
config set appendonly yes 開啓aof
後臺手動出發重寫機制：bgrewriteaof （根據需要，當使用RDB快照進行恢復時，可以使用該命令，將生成一份基於內存的AOF文件）
備份思路：每小時將rdb文件備份一份，將48小時之前的rdb文件刪除（小時級）
#!/bin/sh
cur_date=`date +%Y%m%d%k`
mkdir -p /opt/redis/rediscopy/$cur_date
cp /opt/redis/redis-3.2.1/data/* /opt/redis/rediscopy/$cur_date
towday_date=`date -d -48hour +%Y%m%d%k`
rm -rf /opt/redis/rediscopy/$towday_date
每天將rdb文件備份一份，將一個月前的數據文件刪除（天級）
每天晚上將當前內存中的數據備份，發送到遠程雲服務器