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 的優勢在於支持秒級持久化、兼容性好，缺點是文件大、恢復速度慢、對性能影響大。