前言
對於redis來說，持久化是必不可少的
持久化主要做災難恢復，數據恢復
當redis掛了，那redis就不可用了，這樣redis就無法做到高可用性
重啓redis，如果redis發生了數據災難，重啓之後也是不可用的，沒有數據備份，數據也就沒有了
redis 的持久化主要有兩種方式：RDB和AOF
RDB和AOF介紹
RDB持久化機制，對redis中的數據執行週期性的持久化
AOF持久化機制，對每條寫入命令作爲日誌，以append-only的模式寫入一個日誌文件中，在進行redis重啓時，可以通過回放AOF日誌中的寫入指令來重構整個數據集
如果我們僅僅是想用redis作爲純內存的緩存用，就可以禁用AOF和RDB的所有持久化機制
通過RDB和AOF，可以將redis內存中的數據持久化到磁盤上面，然後將這些數據備份到其它地方，如雲平臺
如果redis掛了，或者存放redis 的服務器掛了，徹底無法恢復，可以從雲平臺拷貝回來之前的數據
如果同時使用兩種RDB和AOF持久化機制，redis重啓時，會優先使用AOF來重構數據，AOF數據更加完整
RDB持久化的特點
-
RDB會生成多個數據文件，每個數據文件代表某一時刻中redis的數據，這種多個數據文件的方式，非常適合做冷備，可以將這些數據文件存放到雲上去，以定期備份策略來定期備份redis中的數據
RDB可以做冷備，生成多個文件，每個文件代表某一時刻的完整的數據快照
AOF也可以做冷備，只有一個文件，你可以每個一定時間，去copy一份這個文件RDB做冷備，優點是：由redis去控制固定時長生成快照文件，比較方便
AOF做冷備，需要自己去手寫定時腳本
RDB做冷備，數據恢復，速度比AOF快 -
RDB對redis對外提供讀寫服務，影響非常小，可以保持redis高性能，因爲redis主進程只需要fork一個子進程，讓子進程執行磁盤IO操作來執行RDB持久化
RDB，每次寫，都是寫入內存，在一定時候，纔會把數據寫入磁盤中
AOF，每次都是要寫文件，雖然可以快速寫入os cache，但是，還是需要一定的時間開銷，比RDB慢 -
相對於AOF持久化機制來說，直接基於RDB數據文件來重啓和恢復redis進程，更加快速
AOF，存放的是指令日誌，做恢復的時候，需要回放和執行所有指令日誌
RDB，就是一份數據文件，恢復時，直接加載到內存中
AOF持久化的特點
- 對於同一份數據而言，AOF文件要比RDB文件更大
- AOF開啓後，支持的寫QPS（每秒查詢量）要比RDB的QPS低，因爲AOF一般會設置成每秒fsync一次日誌，當然，每秒性能也是很高。如果要保證一條數據不丟失，可以設置成每寫入一條數據，fsync一次，但是這樣QPS會下降很多
- 唯一的缺點，其實就是做數據恢復的時候，比較慢，做冷備時，定期的備份，不方便，要手寫複雜的腳本去做
RDB和AOF如何選擇
- 不要僅僅使用RDB，那樣會丟失很多數據
- 也不要僅僅使用AOF，那樣會存在兩個問題，第一，使用AOF做冷備，沒有RDB恢復的快。第二，RDB每次簡單粗暴的生成數據快照，更加健壯，可以避免AOF這種複雜的備份和恢復機制的bug
- 綜合考慮，用AOF來保證數據的不丟失，作爲數據恢復的第一選擇
用RDB做冷備，在AOF文件丟失或損壞不可用的時候，還可以用RDB來進行快速的數據恢復