前言

Redis持久化，一個老掉牙的問題，但是面試官就是喜歡問。這也是我們學Redis必會的一個知識點。Redis作為內存數據庫，它工作時，數據都保存在內存里，這也是它為什么很快的一個原因。但存到內存里肯定是有丟數據的風險，所以Redis是有設計持久化的。Redis持久化分為兩種：RDB和AOF。

RDB持久化

RDB（Redis DataBase），是redis默認的存儲方式，RDB持久化其實就是將內存的數據直接做了一份快照到磁盤上。觸發RDB持久化的方式有：

符合配置的快照保存規則（配置文件里save開頭的配置）；

執行save或者bgsave命令；

執行flushall命令；

執行主從復制操作 (第一次)。

配置文件redis.conf中，save開頭的配置為RDB持久化相關配置。具體解釋如下：

save "" 表示關閉rdb持久化；

save 3600 1 表示每1小時至少有1個key改變，就觸發一次持久化可以寫多個條件；

save 3600 1 300 100 60 10000 這里定義了三個策略，它們相互之間為或的關系。

AOF持久化

AOF（AppendOnly File）持久化，是其將Reids執行過的所有寫指令記錄下來，保存到日志里，類似MySQL的bin-log。默認配置文件里該持久化方式是關閉的，需要將配置修改為：

appendonly yes

由于AOF是將Redis服務的寫操作日志寫到日志文件里，當寫操作非常頻繁時，那么它對磁盤也會造成很大的壓力。所以，AOF的磁盤數據落地（fsync函數）也有三個策略： Always：表示只要有寫入就會調用fsync函數； Everysec：表示每秒調用fsync函數一次； No：表示不調用fscyn函數，完全跟著系統走；

建議選擇everysec，比較保守一些。

AOF重寫

AOF文件如果不做干預，它會一直增漲，直到將你的磁盤寫滿。好在Redis給AOF提供了重寫機制。我們可以直接執行如下命令，進行AOF重寫：

bgrewriteaof;

執行完該命令后，AOF文件會根據已經持久化的RDB文件和現有AOF文件重新整理，它會把無用的寫日志清空，最終達到瘦身目的。 當然，AOF還有一個重寫的配置，兩個參數：

參數	說明
auto-aof-rewrite-min-size	AOF文件必須要不低于這個尺寸時才會觸發重寫，后面的每次重寫就不會根據這個變量了(根據上一次重寫完成之后的大小)。此變量僅初始化啟動redis有效
auto-aof-rewrite-percentage	如果該數值定義為80，則表示當AOF文件增長的尺寸超過上次大小（AOF文件上次重寫后的大小會被記錄下來）百分80時就會觸發重寫操作

RDB和AOF如何選

在實際生產環境中，根據數據量、應用對數據的安全要求、預算限制等不同情況，會有各種各樣的持久化策略。 如，完全不使用任何持久化、使用RDB持久化或AOF持久化的一種，或同時開啟快照持久化和AOF持久化等。此外，持久化的選擇必須與Redis的主從策略一起考慮，因為主從復制與持久化同樣具有數據備份的功能，而且主機Master和從機Slave可以獨立的選擇持久化方案。

如果Redis中的數據完全丟棄也沒有關系（如Redis完全用作DB層數據的cache），那么無論是單機，還是主從架構，都可以不進行任何持久化。 在單機環境下（對于個人開發者，這種情況可能比較常見），如果可以接受十幾分鐘或更多的數據丟失，選擇RDB持久化對Redis的性能更加有利，如果只能接受秒級別的數據丟失，應該選擇AOF。

但在多數情況下，我們都會配置主從環境，Slave的存在既可以實現數據的熱備，也可以進行讀寫分離分擔Redis讀請求，以及在Master宕掉后繼續提供服務。在這種情況下，一種可行的做法是：

Master：完全關閉持久化，這樣可以讓Master的性能達到最好；

Slave：關閉RDB持久化，開啟AOF（如果對數據安全要求不高，開啟RDB持久化關閉AOF也可以），并定時對持久化文件進行備份（如備份到其他文件夾，并標記好備份的時間）。然后關閉AOF的自動重寫，然后添加定時任務，在每天Redis閑時（如凌晨12點）調用bgrewriteaof。

審核編輯：劉清