如何解密Redis的持久化和主從復制機制

這篇文章將為大家詳細講解有關如何解密Redis的持久化和主從復制機制，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

小編將為大家解密redis的持久化和主從復制機制。

Redis持久化

Redis 提供了多種不同級別的持久化方式：

• RDB 持久化可以在指定的時間間隔內生成數據集的時間點快照（point-in-time snapshot）。

• AOF 持久化記錄服務器執行的所有寫操作命令，并在服務器啟動時，通過重新執行這些命令來還原數據集。 AOF 文件中的命令全部以 Redis 協議的格式來保存，新命令會被追加到文件的末尾。 Redis 還可以在后臺對 AOF 文件進行重寫（rewrite），使得 AOF 文件的體積不會超出保存數據集狀態所需的實際大小。

• Redis 還可以同時使用 AOF 持久化和 RDB 持久化。 在這種情況下， 當 Redis 重啟時， 它會優先使用 AOF 文件來還原數據集， 因為 AOF 文件保存的數據集通常比 RDB 文件所保存的數據集更完整。

• 你甚至可以關閉持久化功能，讓數據只在服務器運行時存在。

RDB(Redis DataBase)

Rdb:在指定的時間間隔內將內存中的數據集快照寫入磁盤，也就是行話講的 snapshot 快照，它恢復時就是將快照文件直接讀到內存里。
Redis 會單獨的創建(fork) 一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，待持久化過程結束了，再用這個臨時文件替換上次持久化還的文件。整個過程總，主進程是不進行任何 IO 操作，這就確保了極高的性能，如果需要進行大規模的數據恢復，且對于數據恢復的完整性不是非常敏感，那 RDB 方法要比 AOF 方式更加的高效。RDB 的缺點是最后一次持久化后的數據可能丟失。
Fork 的作用是復制一個與當前進程一樣的進程，新進程的所有數據(變量、環境變量、程序計數器等)數值都和原進程一致，但是是一個全新的進程，并作為原進程的子進程
 
隱患：若當前的進程的數據量龐大，那么 fork 之后數據量*2,此時就會造成服務器壓力大，運行性能降低
Rdb 保存的是 dump.rdb 文件
 
 
 
 
在測試：執行 flushAll 命令, 使用 shutDown 直接關閉進程時，第二次打開時 redis 會自動讀取 dump.rdb 文件，但是恢復時，全為空。(此時的原因：在關閉時刻，redis 系統會保存空的 dump.rdb 替換原來的緩存文件。所以第二次打開的 redis系統時候，自動讀取的是空值文件)

 
RDB save 操作
Rdb 是整個內存的壓縮的 snapshot，RDB 的數據結構，可以配置符合快照觸發條件，默認的是 1 分鐘內改動 1 萬次，或者 5 分鐘改動 10 次，或者是 15 分鐘改動一次；
Save 禁用：如果想禁用 RDB 持久化的策略，只要不設置任何 save 指令，或者是給 save 傳入一個空字符串參數也可以。
 
 -----> save 指令：即刻保存操作對象
 

如何觸發 RDB 快照

Save：save 時只管保存，其他不管，全部阻塞。
Bgsave：redis 會在后臺進行快照操作，快照操作的同時還可以響應客戶端的請求，可以通過 lastsave 命令獲取最后一次成功執行快照的時間。
 
執行 fluhall 命令，也會產生 dump.rdb 文件，但里面是空的。
 

如何恢復:

將備份文件(dump.rdb)移動到 redis 安裝目錄并啟動服務即可
Config get dir 命令可獲取目錄
 

如何停止

動態停止 RDB 保存規則的方法：redis -cli config set save “”
 
 

AOF(Append Only File)

以日志的形式倆記錄每個寫操作，將 redis 執行過的所有寫指令記錄下來(讀操作不記錄)。只許追加文件但不可以改寫文件，redis 啟動之初會讀取該文件重新構建數據，換言之，redis重啟的話就根據日志文件的內容將寫指令從前到后執行一次一完成數據恢復工作。
======APPEND ONLY MODE=====
 
開啟 aof ：appendonly yes  (默認是 no)
 
 
 
 
注意：
 
 
在實際工作生產的時候往往會出現：aof 文件損壞(網絡傳輸或者其他問題導致 aof 文件破壞)
 
 
 
 
 
服務器啟動報錯(但是 dump.rdb 文件是完整的) 說明啟動先加載 aof 文件
解決方案：執行命令 redis-check-aof --fix aof 文件 [自動檢查刪除不和 aof 語法的字段]
 

Aof策略

 
Appendfsync 參數：
Always 同步持久化 每次發生數據變更會被立即記錄到磁盤，性能較差但數據完整性較好。
Everysec： 出廠默認推薦，異步操作，每秒記錄，日過一秒宕機，有數據丟失
No：從不 fsync ：將數據交給操作系統來處理。更快，也更不安全的選擇。
 
 

Rewrite

概念：AOF 采用文件追加方式，文件會越來越來大為避免出現此種情況，新增了重寫機制，aof 文件的大小超過所設定的閾值時，redis 就會自動 aof 文件的內容壓縮，值保留可以恢復數據的最小指令集，可以使用命令 bgrewirteaof。
重寫原理：aof 文件持續增長而大時，會 fork 出一條新進程來將文件重寫(也就
是先寫臨時文件最后再 rename)，遍歷新進程的內存中的數據，每條記錄有一條 set 語句，重寫 aof 文件的操作，并沒有讀取舊的的 aof 文件，而是將整個內存的數據庫內容用命令的方式重寫了一個新的 aof 文件，這點和快照有點類似。
觸發機制：redis 會記錄上次重寫的 aof 的大小，默認的配置當 aof 文件大小上次 rewrite 后大小的一倍且文件大于 64M 觸發(3G)
 

 
 
no-appendfsync-on-rewrite no : 重寫時是否可以運用 Appendfsync 用默認 no 即可，保證數據安全
auto-aof-rewrite-percentage  倍數 設置基準值
auto-aof-rewrite-min-size  設置基準值大小

AOF優點

使用 AOF 持久化會讓 Redis 變得非常耐久：你可以設置不同的 fsync 策略，比如無 fsync ，每秒鐘一次 fsync ，或者每次執行寫入命令時 fsync 。 AOF 的默認策略為每秒鐘 fsync 一次，在這種配置下，Redis 仍然可以保持良好的性能，并且就算發生故障停機，也最多只會丟失一秒鐘的數據（ fsync 會在后臺線程執行，所以主線程可以繼續努力地處理命令請求）。
AOF 文件是一個只進行追加操作的日志文件（append only log）， 因此對 AOF 文件的寫入不需要進行 seek ， 即使日志因為某些原因而包含了未寫入完整的命令（比如寫入時磁盤已滿，寫入中途停機，等等）， redis-check-aof 工具也可以輕易地修復這種問題。
Redis 可以在 AOF 文件體積變得過大時，自動地在后臺對 AOF 進行重寫： 重寫后的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在創建新 AOF 文件的過程中，會繼續將命令追加到現有的 AOF 文件里面，即使重寫過程中發生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，并開始對新 AOF 文件進行追加操作。
AOF 文件有序地保存了對數據庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析（parse）也很輕松。 導出（export） AOF 文件也非常簡單： 舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那么只要停止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重啟 Redis ， 就可以將數據集恢復到 FLUSHALL 執行之前的狀態。

AOF缺點

對于相同的數據集來說，AOF 文件的體積通常要大于 RDB 文件的體積。
根據所使用的 fsync 策略，AOF 的速度可能會慢于 RDB 。 在一般情況下， 每秒 fsync 的性能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。
AOF 在過去曾經發生過這樣的 bug ： 因為個別命令的原因，導致 AOF 文件在重新載入時，無法將數據集恢復成保存時的原樣。 （舉個例子，阻塞命令 BRPOPLPUSH 就曾經引起過這樣的 bug 。） 測試套件里為這種情況添加了測試： 它們會自動生成隨機的、復雜的數據集，并通過重新載入這些數據來確保一切正常。雖然這種 bug 在 AOF 文件中并不常見， 但是對比來說， RDB 幾乎是不可能出現這種 bug 的。
 
 

備份Redis 數據

一定要備份你的數據庫！
磁盤故障， 節點失效， 諸如此類的問題都可能讓你的數據消失不見， 不進行備份是非常危險的。
Redis 對于數據備份是非常友好的， 因為你可以在服務器運行的時候對 RDB 文件進行復制： RDB 文件一旦被創建， 就不會進行任何修改。 當服務器要創建一個新的 RDB 文件時， 它先將文件的內容保存在一個臨時文件里面， 當臨時文件寫入完畢時， 程序才使用 rename(2) 原子地用臨時文件替換原來的 RDB 文件。
這也就是說， 無論何時， 復制 RDB 文件都是絕對安全的。
建議：
創建一個定期任務（cron job）， 每小時將一個 RDB 文件備份到一個文件夾， 并且每天將一個 RDB 文件備份到另一個文件夾。
確保快照的備份都帶有相應的日期和時間信息， 每次執行定期任務腳本時， 使用 find 命令來刪除過期的快照： 比如說， 你可以保留最近 48 小時內的每小時快照， 還可以保留最近一兩個月的每日快照。
至少每天一次， 將 RDB 備份到你的數據中心之外， 或者至少是備份到你運行 Redis 服務器的物理機器之外。

容災備份

Redis 的容災備份基本上就是對數據進行備份， 并將這些備份傳送到多個不同的外部數據中心。
容災備份可以在 Redis 運行并產生快照的主數據中心發生嚴重的問題時， 仍然讓數據處于安全狀態。
有的Redis 用戶是創業者， 他們沒有大把大把的錢可以浪費， 所以下面介紹的都是一些實用又便宜的容災備份方法：
Amazon S3 ，以及其他類似 S3 的服務，是一個構建災難備份系統的好地方。 最簡單的方法就是將你的每小時或者每日 RDB 備份加密并傳送到 S3 。 對數據的加密可以通過 gpg -c 命令來完成（對稱加密模式）。 記得把你的密碼放到幾個不同的、安全的地方去（比如你可以把密碼復制給你組織里最重要的人物）。 同時使用多個儲存服務來保存數據文件，可以提升數據的安全性。
傳送快照可以使用 SCP 來完成（SSH 的組件）。 以下是簡單并且安全的傳送方法： 買一個離你的數據中心非常遠的 VPS(虛擬專用服務器) ， 裝上 SSH ， 創建一個無口令的 SSH 客戶端 key ， 并將這個 key 添加到 VPS 的 authorized_keys 文件中， 這樣就可以向這個 VPS 傳送快照備份文件了。 為了達到最好的數據安全性，至少要從兩個不同的提供商那里各購買一個 VPS 來進行數據容災備份。
需要注意的是， 這類容災系統如果沒有小心地進行處理的話， 是很容易失效的。
最低限度下， 你應該在文件傳送完畢之后， 檢查所傳送備份文件的體積和原始快照文件的體積是否相同。 如果你使用的是 VPS ， 那么還可以通過比對文件的 SHA1 校驗和來確認文件是否傳送完整。
另外， 你還需要一個獨立的警報系統， 讓它在負責傳送備份文件的傳送器（transfer）失靈時通知你。
 
 

Redis主從復制

Redis 支持簡單且易用的主從復制（master-slave replication）功能， 該功能可以讓從服務器(slave server)成為主服務器(master server)的精確復制品。
以下是關于 Redis 復制功能的幾個重要方面：

• Redis 使用異步復制。 從 Redis 2.8 開始， 從服務器會以每秒一次的頻率向主服務器報告復制流（replication stream）的處理進度。

• 一個主服務器可以有多個從服務器。

• 不僅主服務器可以有從服務器， 從服務器也可以有自己的從服務器， 多個從服務器之間可以構成一個圖狀結構。

• 復制功能不會阻塞主服務器： 即使有一個或多個從服務器正在進行初次同步， 主服務器也可以繼續處理命令請求。

• 復制功能也不會阻塞從服務器： 只要在 redis.conf 文件中進行了相應的設置， 即使從服務器正在進行初次同步， 服務器也可以使用舊版本的數據集來處理命令查詢。

不過， 在從服務器刪除舊版本數據集并載入新版本數據集的那段時間內， 連接請求會被阻塞。
你還可以配置從服務器， 讓它在與主服務器之間的連接斷開時， 向客戶端發送一個錯誤。

• 復制功能可以單純地用于數據冗余（data redundancy）， 也可以通過讓多個從服務器處理只讀命令請求來提升擴展性（scalability）： 比如說， 繁重的 SORT 命令可以交給附屬節點去運行。

• 可以通過復制功能來讓主服務器免于執行持久化操作： 只要關閉主服務器的持久化功能， 然后由從服務器去執行持久化操作即可。

關閉主服務器持久化時，復制功能的數據安全

當配置Redis復制功能時，強烈建議打開主服務器的持久化功能。 否則的話，由于延遲等問題，部署的服務應該要避免自動拉起。案例：
1. 假設節點A為主服務器，并且關閉了持久化。 并且節點B和節點C從節點A復制數據
2. 節點A崩潰，然后由自動拉起服務重啟了節點A. 由于節點A的持久化被關閉了，所以重啟之后沒有任何數據
3. 節點B和節點C將從節點A復制數據，但是A的數據是空的， 于是就把自身保存的數據副本刪除。
在關閉主服務器上的持久化，并同時開啟自動拉起進程的情況下，即便使用Sentinel來實現Redis的高可用性，也是非常危險的。 因為主服務器可能拉起得非常快，以至于Sentinel在配置的心跳時間間隔內沒有檢測到主服務器已被重啟，然后還是會執行上面的數據丟失的流程。
無論何時，數據安全都是極其重要的，所以應該禁止主服務器關閉持久化的同時自動拉起。

從服務器配置

配置一個從服務器非常簡單， 只要在配置文件中增加以下的這一行就可以了：
slaveof 192.168.1.1 6379
另外一種方法是調用 SLAVEOF 命令，輸入主服務器的 IP 和端口，然后同步就會開始
127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK

只讀從服務器

從 Redis 2.6 開始， 從服務器支持只讀模式， 并且該模式為從服務器的默認模式。
只讀模式由 redis.conf 文件中的 slave-read-only 選項控制， 也可以通過 CONFIG SET 命令來開啟或關閉這個模式。
只讀從服務器會拒絕執行任何寫命令， 所以不會出現因為操作失誤而將數據不小心寫入到了從服務器的情況。
另外，對一個從屬服務器執行命令 SLAVEOF NO ONE 將使得這個從屬服務器關閉復制功能，并從從屬服務器轉變回主服務器，原來同步所得的數據集不會被丟棄。
利用『 SLAVEOF NO ONE 不會丟棄同步所得數據集』這個特性，可以在主服務器失敗的時候，將從屬服務器用作新的主服務器，從而實現無間斷運行。
 
 

從服務器相關配置：

 
如果主服務器通過 requirepass 選項設置了密碼， 那么為了讓從服務器的同步操作可以順利進行， 我們也必須為從服務器進行相應的身份驗證設置。
對于一個正在運行的服務器， 可以使用客戶端輸入以下命令：
config set masterauth
要永久地設置這個密碼， 那么可以將它加入到配置文件中：
masterauth

主服務器只在有至少 N 個從服務器的情況下，才執行寫操作

從 Redis 2.8 開始， 為了保證數據的安全性，可以通過配置， 讓主服務器只在有至少 N 個當前已連接從服務器的情況下， 才執行寫命令。
不過， 因為 Redis 使用異步復制， 所以主服務器發送的寫數據并不一定會被從服務器接收到， 因此， 數據丟失的可能性仍然是存在的。
以下是這個特性的運作原理：

• 從服務器以每秒一次的頻率 PING 主服務器一次， 并報告復制流的處理情況。

• 主服務器會記錄各個從服務器最后一次向它發送 PING 的時間。

• 用戶可以通過配置， 指定網絡延遲的最大值 min-slaves-max-lag ， 以及執行寫操作所需的至少從服務器數量 min-slaves-to-write 。

如果至少有 min-slaves-to-write 個從服務器， 并且這些服務器的延遲值都少于 min-slaves-max-lag 秒， 那么主服務器就會執行客戶端請求的寫操作。
另一方面， 如果條件達不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的條件， 那么寫操作就不會被執行， 主服務器會向請求執行寫操作的客戶端返回一個錯誤。
以下是這個特性的兩個選項和它們所需的參數：
min-slaves-to-write 
min-slaves-max-lag 

關于如何解密Redis的持久化和主從復制機制就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。