Redis 高可用之"持久化"

Redis高可用概述

在Redis中，實現高可用的技術主要包括：持久化、複製(讀寫分離)、哨兵、集群。

• 持久化：

  持久化是最簡單的高可用方法(有時甚至不被歸為高可用手段)，主要作用是數據備份，即將數據存儲在硬碟，保證數據不會因進程退出而丟失。

• 複製：

  複製是高可用Redis的基礎，哨兵和集群都是在複製的基礎上實現高可用的。複製主要實現了數據的多機備份，以及對於讀操作的負載均衡和簡單的故障恢復。

  缺陷：故障恢復無法自動化，寫操作無法負載均衡，存儲能力受到單機的限制。

• 哨兵：

  在複製的基礎上，哨兵實現了自動化的故障恢復。

  缺陷：寫操作無法負載均衡；存儲能力收到單機限制。

• 集群：

  通過集群，Redis解決了操作無法負載均衡，以及存儲能力收到單機限制的問題，實現了較為完善的高可用解決方案。

Redis持久化概述

持久化的功能：Redis 是記憶體資料庫，數據都是存儲在記憶體中。

Redis 的持久化分為 RDB 和 AOF 持久化：

• 前者是將數據保存到硬碟。
• 後者是將每次執行的寫命令保存到硬碟。

RDB 持久化

​ RDB持久化是將當前進程中的數據生成快照保存到硬碟中(因此也叫做快照持久化)，保存的文件尾碼是RDB；

​ 當Redis重新啟動時，可以讀取快照文件恢複數據。

觸發條件：

• 手動觸發
• 自動觸發

手動觸發：save命令和bgsave命令都可以生成 RDB 文件。

​ save命令會阻塞 Redis 服務進程，直到 RDB 文件創建完畢為止，在 Redis 伺服器 阻塞期間，伺服器不能執行任 何命令請求。

​ bgsave命令會創建一個子進程，由子進程來創建 RDB 文件，父進程(即 Redis 主進程) 繼續處理請求。bgsave 命令執行過程中，只有fork(ork了進程，子進程中的redis連接沒法用了，要重連) 子進程會阻塞伺服器，而對於 save 命令，整個過程都會阻塞伺服器。

在自動觸發 RDB 持久化時，Redis 也會使用 bgsave 而不是 save 來進行持久化；下麵介紹自動觸發 RDB 持久化條件。

自動觸發：最常見的情況是在配置文件中通過 save m n ，指定 m 秒內發生了 n 次變化時，會觸發 bgsave。

​ 在Redis 配置文件Redis.conf中，可以看到如下配置信息：

save 900 1  #當時間到 900 秒時，如果 Redis 數據發生了至少 1 次變化，則執行 bgsave。
save 300 10 
save 60 10000 

除了 save m n 以外，還有一些其他情況會觸發 bgsave：

• 在主從複製場景下，如果從節點執行全量複製操作，則主節點會執行 bgsave 命令，並將 RDB 文件發送給從節點。
• 執行 shutdown 命令時，也會自動執行 RDB 持久化。

啟動時載入

​ RDB 的載入工作實在伺服器啟動時自動執行的，並沒有專門的命令。但是由於 AOF 的優先順序更高，因此當 AOF 開啟時，會優先載入 AOF 文件來恢複數據。

文件校驗：

​ Redis 載入 RDB 文件時，會對 RDB 文件進行校驗，如果文件損壞，則日誌中會列印錯誤，Redis 啟動失敗。

AOF 持久化

​ RDB 持久化是將進程數據寫入硬碟，而 AOF 持久化(即 Append Only File 持久化)，則是將 Redis 執行的每次寫 命令記錄到單獨的日誌文件中，當 Redis 重啟的時候再次執行 AOF 來恢複數據。

與 RDB 相比 ，AOF 實時性更好，因此已成為當前主流的持久化方案。

開啟 AOF：Redis 伺服器預設開啟 RDB，關閉 AOF；要開啟 AOF，需要在配置文件中配置：appendonly yes。

文件校驗：

​ 與載入 RDB 文件類似，Redis 載入 AOF 文件時，會對 AOF 文件進行校驗，如果文件損壞，則日誌中會列印錯 誤，Redis 啟動失敗。

RDB與AOF的優缺點

RDB 持久化：

• 優點：RDB 文件緊湊，體積小，網路傳輸快，適合全量複製；恢復速度比 AOF 快很多。當然，與 AOF 相比，RDB 最重要的優點之一是對性能的影響相對較小。

• 缺點：RDB 文件的致命缺點在於其數據快照的持久化方式決定了必然做不到實時持久化，而在數據越來越重要的今天，數據的大量丟失很多時候是無法接受的，因此 AOF 持久化成為主流。

  此外，RDB 需要滿足特定的格式，相容性差/

AOF 持久化：

• 與 RDB 持久化相對應，AOF 的優點在於支持秒級持久化、相容性好，缺點是文件大、恢復速度慢、對性能影響大。