六. Redis 持久化機制
參考地址：《Redis持久化機制》
Redis 有兩種持久化機制：快照 (RDB) 和 AOF 日誌。其中快照是一次性全量備份，AOF 是增量備份。
6.1 快照 (RDB)
Redis 使用操作系統的多進程 COW (Copy On Write) 機制實現快照持久化。在持久化時，由於要一邊要持久化，一邊又要滿足 Redis 的正常使用，所以 Redis 在持久化的時候，使用了 glibc 的 fork 函數產生了一個子進程，在子進程中進行快照持久化操作，主進程滿足業務的正常使用。
RDB的原理是fork和cow。fork是指redis通過創建子進程來進行RDB操作，cow指的是copy on write，子進程創建後，父子進程共享數據段，父進程繼續提供讀寫服務，寫髒的頁面數據會逐漸和子進程分離開來。
快照持久化的內存策略是：子進程按照數據頁進行復制。在持久化過程中，子進程負責持久化過程，它將主進程數據段的數據頁複製一份出來，然後對原數據頁進行存儲；同一時間，主進程對那份複製出來的數據進行操作。通過複製小數據量數據頁（通常每個數據頁只有 4KB）的方式，保證了主進程修改數據不會影響子進程存儲，子進程存儲的數據，還是子進程產生一瞬間的數據。
快照觸發方式有自動觸發與手動觸發兩種。
- 自動觸發：通過 redis.conf 配置文件進行配置；
- 手動觸發：
- save: 阻塞式觸發，在未完成前，客戶端無法進行命令操作；
- bgsave: 非阻塞式觸發，主進程 fork 出子進程進行備份操作；
在恢復文件時，將備份文件 (dump.rdb) 放在 Redis 安裝目錄，然後啓動 Redis，就能把 RDB 中的文件加載到 Redis 服務中。
快照存儲的優點缺點：
- 優點：
- 數據結構緊湊，保存了 Redis 服務在某個時間點上的數據集，非常適合做備份和災難恢復；
- 進行 RDB 快照持久化時，主進程會 fork 出一個子進程進行備份工作，主進程不需要額外的 IO 操作；
- RDB 恢復大數據集時，速度比 AOF 快；
- 缺點：
- 版本兼容問題：Redis 版本更新過程中有多個 RDB 版本，存在老版 RDB 兼容性無法兼容新版的問題；
- 無法做到實時持久化，因爲 bgsave 時的 fork 操作每次都會創建子進程，內存中的數據被克隆了一份，屬於重量級操作。
6.2 AOF
AOF 日誌存儲的是 Redis 服務器的順序指令序列，它只記錄對內存進行修改的指令記錄。AOF 使用追加記錄的方式，在 Redis 長期運行的過程中，AOF 日誌會越來越長，所以一旦宕機重啓載入 AOF 日誌，將會是一個非常耗時的功能，因此我們需要對 AOF 進行瘦身，即 AOF 重寫。
AOF 重寫並不是對原始的 AOF 文件進行重新整理，而是 fork 一個子進程遍歷服務器的鍵值對，轉換成一系列 Redis 的操作指令，序列化到一個新的 AOF 日誌文件中。序列化完畢後，將原來的文件替換爲序列化後的文件即可。
AOF 重寫分爲兩個過程，一個是 fork 子進程重寫過程執行的原始數據內容，另一個是在 fork 過程中主進程修改的指令。
6.3 混合持久化
Redis 4.0 之後加入了新的持久化選項：混合持久化。它將 RDB 和 AOF 內容放在一起，其中 AOF 日誌記錄的不是全量日誌，而是持久化開始到持久化結束時間內的 AOF 日誌（通常該部分日誌很小）。
6.4 AOF 的持久化策略
問：如果突然機器掉電會怎樣？
AOF 的持久化策略：AOF 日誌是以文件形式存在的，裏面記錄的是內存的操作記錄，它的實現是將操作系統內核爲文件描述符分配的內存緩存，通過異步的方式刷新到數據磁盤中。這種操作是 glibc 的 fsync 操作，它是一個很慢的操作，與 Redis 的高性能是相反的。
AOF 提供了三種持久化策略：
- no: 無 fsync，由系統保證數據刷新到磁盤，速度最快，但很不安全（通常不使用）；
- always: 每次 fsync，每一個修改內存的 Redis 指令都會執行一次 fsync，速度很慢（通常不使用）；
- everysec: 每秒進行一次 fsync，有可能丟失一秒的 fsync 的數據。通常選擇 everysec 策略，兼顧安全性和效率。
持久化取決於 AOF 日誌 sync 屬性的配置，如果不要求性能，在每條寫指令時都sync一下磁盤，就不會丟失數據。但是在高性能的要求下每次都sync是不現實的，一般都使用定時sync，比如1s1次，這個時候最多就會丟失1s的數據。