建站
咨詢
售后
建站咨詢
新聞中心
小編給大家分享一下redis的持久化和主從復(fù)制機制是什么，希望大家閱讀完這篇文章后大所收獲，下面讓我們一起去探討吧！
網(wǎng)站建設(shè)公司,為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁設(shè)計及定制網(wǎng)站建設(shè)服務(wù),專注于企業(yè)網(wǎng)站設(shè)計,高端網(wǎng)頁制作,對成都VR全景等多個行業(yè)擁有豐富的網(wǎng)站建設(shè)經(jīng)驗的網(wǎng)站建設(shè)公司。專業(yè)網(wǎng)站設(shè)計,網(wǎng)站優(yōu)化推廣哪家好,專業(yè)成都網(wǎng)站營銷優(yōu)化,H5建站,響應(yīng)式網(wǎng)站。
Redis持久化
Redis 提供了多種不同級別的持久化方式：
RDB 持久化可以在指定的時間間隔內(nèi)生成數(shù)據(jù)集的時間點快照（point-in-time snapshot）
AOF 持久化記錄服務(wù)器執(zhí)行的所有寫操作命令，并在服務(wù)器啟動時，通過重新執(zhí)行這些命令來還原數(shù)據(jù)集。 AOF 文件中的命令全部以 Redis 協(xié)議的格式來保存，新命令會被追加到文件的末尾。 Redis 還可以在后臺對 AOF 文件進行重寫（rewrite），使得 AOF 文件的體積不會超出保存數(shù)據(jù)集狀態(tài)所需的實際大小。
Redis 還可以同時使用 AOF 持久化和 RDB 持久化。 在這種情況下， 當 Redis 重啟時， 它會優(yōu)先使用 AOF 文件來還原數(shù)據(jù)集， 因為 AOF 文件保存的數(shù)據(jù)集通常比 RDB 文件所保存的數(shù)據(jù)集更完整。
你甚至可以關(guān)閉持久化功能，讓數(shù)據(jù)只在服務(wù)器運行時存在。
RDB(Redis DataBase)
Rdb:在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤，也就是行話講的 snapshot 快照，它恢復(fù)時就是將快照文件直接讀到內(nèi)存里。
Redis 會單獨的創(chuàng)建(fork) 一個子進程來進行持久化，會先將數(shù)據(jù)寫入到一個臨時文件中，待持久化過程結(jié)束了，再用這個臨時文件替換上次持久化還的文件。整個過程總，主進程是不進行任何 IO 操作，這就確保了極高的性能，如果需要進行大規(guī)模的數(shù)據(jù)恢復(fù)，且對于數(shù)據(jù)恢復(fù)的完整性不是非常敏感，那 RDB 方法要比 AOF 方式更加的高效。RDB 的缺點是最后一次持久化后的數(shù)據(jù)可能丟失。
Fork 的作用是復(fù)制一個與當前進程一樣的進程，新進程的所有數(shù)據(jù)(變量、環(huán)境變量、程序計數(shù)器等)數(shù)值都和原進程一致，但是是一個全新的進程，并作為原進程的子進程
隱患：若當前的進程的數(shù)據(jù)量龐大，那么 fork 之后數(shù)據(jù)量*2,此時就會造成服務(wù)器壓力大，運行性能降低。
Rdb 保存的是 dump.rdb 文件
.jpg)
在測試：執(zhí)行 flushAll 命令, 使用 shutDown 直接關(guān)閉進程時，第二次打開時 redis 會自動讀取 dump.rdb 文件，但是恢復(fù)時，全為空。(此時的原因：在關(guān)閉時刻，redis 系統(tǒng)會保存空的 dump.rdb 替換原來的緩存文件。所以第二次打開的 redis系統(tǒng)時候，自動讀取的是空值文件)
RDB save 操作
Rdb 是整個內(nèi)存的壓縮的 snapshot，RDB 的數(shù)據(jù)結(jié)構(gòu)，可以配置符合快照觸發(fā)條件，默認的是 1 分鐘內(nèi)改動 1 萬次，或者 5 分鐘改動 10 次，或者是 15 分鐘改動一次；
Save 禁用：如果想禁用 RDB 持久化的策略，只要不設(shè)置任何 save 指令，或者是給 save 傳入一個空字符串參數(shù)也可以。
-----> save 指令：即刻保存操作對象
如何觸發(fā) RDB 快照
Save：save 時只管保存，其他不管，全部阻塞。
Bgsave：redis 會在后臺進行快照操作，快照操作的同時還可以響應(yīng)客戶端的請求，可以通過 lastsave 命令獲取最后一次成功執(zhí)行快照的時間。
執(zhí)行 fluhall 命令，也會產(chǎn)生 dump.rdb 文件，但里面是空的。
如何恢復(fù):
將備份文件(dump.rdb)移動到 redis 安裝目錄并啟動服務(wù)即可
Config get dir 命令可獲取目錄
如何停止
動態(tài)停止 RDB 保存規(guī)則的方法：redis -cli config set save “”
AOF(Append Only File)
以日志的形式倆記錄每個寫操作，將 redis 執(zhí)行過的所有寫指令記錄下來(讀操作不記錄)。只許追加文件但不可以改寫文件，redis 啟動之初會讀取該文件重新構(gòu)建數(shù)據(jù)，換言之，redis重啟的話就根據(jù)日志文件的內(nèi)容將寫指令從前到后執(zhí)行一次一完成數(shù)據(jù)恢復(fù)工作。
======APPEND ONLY MODE=====
開啟 aof ：appendonly yes (默認是 no)
.jpg)
注意：
在實際工作生產(chǎn)的時候往往會出現(xiàn)：aof 文件損壞(網(wǎng)絡(luò)傳輸或者其他問題導(dǎo)致 aof 文件破壞)
.jpg)
服務(wù)器啟動報錯(但是 dump.rdb 文件是完整的) 說明啟動先加載 aof 文件
解決方案：執(zhí)行命令 redis-check-aof --fix aof 文件 [自動檢查刪除不和 aof 語法的字段]
Aof策略
.jpg)
Appendfsync 參數(shù)：
Always 同步持久化 每次發(fā)生數(shù)據(jù)變更會被立即記錄到磁盤，性能較差但數(shù)據(jù)完整性較好。
Everysec： 出廠默認推薦，異步操作，每秒記錄，日過一秒宕機，有數(shù)據(jù)丟失
No：從不 fsync ：將數(shù)據(jù)交給操作系統(tǒng)來處理。更快，也更不安全的選擇。
Rewrite
概念：AOF 采用文件追加方式，文件會越來越來大為避免出現(xiàn)此種情況，新增了重寫機制，aof 文件的大小超過所設(shè)定的閾值時，redis 就會自動 aof 文件的內(nèi)容壓縮，值保留可以恢復(fù)數(shù)據(jù)的最小指令集，可以使用命令 bgrewirteaof。
重寫原理：aof 文件持續(xù)增長而大時，會 fork 出一條新進程來將文件重寫(也就
是先寫臨時文件最后再 rename)，遍歷新進程的內(nèi)存中的數(shù)據(jù)，每條記錄有一條 set 語句，重寫 aof 文件的操作，并沒有讀取舊的的 aof 文件，而是將整個內(nèi)存的數(shù)據(jù)庫內(nèi)容用命令的方式重寫了一個新的 aof 文件，這點和快照有點類似。
觸發(fā)機制：redis 會記錄上次重寫的 aof 的大小，默認的配置當 aof 文件大小上次 rewrite 后大小的一倍且文件大于 64M 觸發(fā)(3G)
.jpg)
no-appendfsync-on-rewrite no : 重寫時是否可以運用 Appendfsync 用默認 no 即可，保證數(shù)據(jù)安全
auto-aof-rewrite-percentage 倍數(shù) 設(shè)置基準值
auto-aof-rewrite-min-size 設(shè)置基準值大小
AOF優(yōu)點
使用 AOF 持久化會讓 Redis 變得非常耐久：你可以設(shè)置不同的 fsync 策略，比如無 fsync ，每秒鐘一次 fsync ，或者每次執(zhí)行寫入命令時 fsync 。 AOF 的默認策略為每秒鐘 fsync 一次，在這種配置下，Redis 仍然可以保持良好的性能，并且就算發(fā)生故障停機，也最多只會丟失一秒鐘的數(shù)據(jù)（ fsync 會在后臺線程執(zhí)行，所以主線程可以繼續(xù)努力地處理命令請求）。
AOF 文件是一個只進行追加操作的日志文件（append only log）， 因此對 AOF 文件的寫入不需要進行 seek ， 即使日志因為某些原因而包含了未寫入完整的命令（比如寫入時磁盤已滿，寫入中途停機，等等）， redis-check-aof 工具也可以輕易地修復(fù)這種問題。
Redis 可以在 AOF 文件體積變得過大時，自動地在后臺對 AOF 進行重寫： 重寫后的新 AOF 文件包含了恢復(fù)當前數(shù)據(jù)集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在創(chuàng)建新 AOF 文件的過程中，會繼續(xù)將命令追加到現(xiàn)有的 AOF 文件里面，即使重寫過程中發(fā)生停機，現(xiàn)有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創(chuàng)建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，并開始對新 AOF 文件進行追加操作。
AOF 文件有序地保存了對數(shù)據(jù)庫執(zhí)行的所有寫入操作， 這些寫入操作以 Redis 協(xié)議的格式保存， 因此 AOF 文件的內(nèi)容非常容易被人讀懂， 對文件進行分析（parse）也很輕松。 導(dǎo)出（export） AOF 文件也非常簡單： 舉個例子， 如果你不小心執(zhí)行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那么只要停止服務(wù)器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重啟 Redis ， 就可以將數(shù)據(jù)集恢復(fù)到 FLUSHALL 執(zhí)行之前的狀態(tài)。
AOF缺點
對于相同的數(shù)據(jù)集來說，AOF 文件的體積通常要大于 RDB 文件的體積。
根據(jù)所使用的 fsync 策略，AOF 的速度可能會慢于 RDB 。 在一般情況下， 每秒 fsync 的性能依然非常高， 而關(guān)閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。
AOF 在過去曾經(jīng)發(fā)生過這樣的 bug ： 因為個別命令的原因，導(dǎo)致 AOF 文件在重新載入時，無法將數(shù)據(jù)集恢復(fù)成保存時的原樣。 （舉個例子，阻塞命令 BRPOPLPUSH 就曾經(jīng)引起過這樣的 bug 。）
測試套件里為這種情況添加了測試： 它們會自動生成隨機的、復(fù)雜的數(shù)據(jù)集，并通過重新載入這些數(shù)據(jù)來確保一切正常。雖然這種 bug 在 AOF 文件中并不常見， 但是對比來說， RDB 幾乎是不可能出現(xiàn)這種 bug 的。
備份Redis 數(shù)據(jù)
一定要備份你的數(shù)據(jù)庫！
磁盤故障， 節(jié)點失效， 諸如此類的問題都可能讓你的數(shù)據(jù)消失不見， 不進行備份是非常危險的。
Redis 對于數(shù)據(jù)備份是非常友好的， 因為你可以在服務(wù)器運行的時候?qū)?RDB 文件進行復(fù)制： RDB 文件一旦被創(chuàng)建， 就不會進行任何修改。 當服務(wù)器要創(chuàng)建一個新的 RDB 文件時， 它先將文件的內(nèi)容保存在一個臨時文件里面， 當臨時文件寫入完畢時， 程序才使用 rename(2) 原子地用臨時文件替換原來的 RDB 文件。
這也就是說， 無論何時， 復(fù)制 RDB 文件都是絕對安全的。
建議：
創(chuàng)建一個定期任務(wù)（cron job）， 每小時將一個 RDB 文件備份到一個文件夾， 并且每天將一個 RDB 文件備份到另一個文件夾。
確?？煺盏膫浞荻紟в邢鄳?yīng)的日期和時間信息， 每次執(zhí)行定期任務(wù)腳本時， 使用 find 命令來刪除過期的快照： 比如說， 你可以保留最近 48 小時內(nèi)的每小時快照， 還可以保留最近一兩個月的每日快照。
至少每天一次， 將 RDB 備份到你的數(shù)據(jù)中心之外， 或者至少是備份到你運行 Redis 服務(wù)器的物理機器之外。
容災(zāi)備份
Redis 的容災(zāi)備份基本上就是對數(shù)據(jù)進行備份， 并將這些備份傳送到多個不同的外部數(shù)據(jù)中心。
容災(zāi)備份可以在 Redis 運行并產(chǎn)生快照的主數(shù)據(jù)中心發(fā)生嚴重的問題時， 仍然讓數(shù)據(jù)處于安全狀態(tài)。
有的Redis 用戶是創(chuàng)業(yè)者， 他們沒有大把大把的錢可以浪費， 所以下面介紹的都是一些實用又便宜的容災(zāi)備份方法：
Amazon S3 ，以及其他類似 S3 的服務(wù)，是一個構(gòu)建災(zāi)難備份系統(tǒng)的好地方。 最簡單的方法就是將你的每小時或者每日 RDB 備份加密并傳送到 S3 。 對數(shù)據(jù)的加密可以通過 gpg -c 命令來完成（對稱加密模式）。 記得把你的密碼放到幾個不同的、安全的地方去（比如你可以把密碼復(fù)制給你組織里最重要的人物）。 同時使用多個儲存服務(wù)來保存數(shù)據(jù)文件，可以提升數(shù)據(jù)的安全性。
傳送快照可以使用 SCP 來完成（SSH 的組件）。 以下是簡單并且安全的傳送方法： 買一個離你的數(shù)據(jù)中心非常遠的 vps(虛擬專用服務(wù)器) ， 裝上 SSH ， 創(chuàng)建一個無口令的 SSH 客戶端 key ， 并將這個 key 添加到 VPS 的 authorized_keys 文件中， 這樣就可以向這個 VPS 傳送快照備份文件了。 為了達到最好的數(shù)據(jù)安全性，至少要從兩個不同的提供商那里各購買一個 VPS 來進行數(shù)據(jù)容災(zāi)備份。
需要注意的是， 這類容災(zāi)系統(tǒng)如果沒有小心地進行處理的話， 是很容易失效的。
最低限度下， 你應(yīng)該在文件傳送完畢之后， 檢查所傳送備份文件的體積和原始快照文件的體積是否相同。 如果你使用的是 VPS ， 那么還可以通過比對文件的 SHA1 校驗和來確認文件是否傳送完整。
另外， 你還需要一個獨立的警報系統(tǒng)， 讓它在負責傳送備份文件的傳送器（transfer）失靈時通知你。
Redis主從復(fù)制
Redis 支持簡單且易用的主從復(fù)制（master-slave replication）功能， 該功能可以讓從服務(wù)器(slave server)成為主服務(wù)器(master server)的精確復(fù)制品。
以下是關(guān)于 Redis 復(fù)制功能的幾個重要方面：
Redis 使用異步復(fù)制。 從 Redis 2.8 開始， 從服務(wù)器會以每秒一次的頻率向主服務(wù)器報告復(fù)制流（replication stream）的處理進度。
一個主服務(wù)器可以有多個從服務(wù)器。
不僅主服務(wù)器可以有從服務(wù)器， 從服務(wù)器也可以有自己的從服務(wù)器， 多個從服務(wù)器之間可以構(gòu)成一個圖狀結(jié)構(gòu)。
復(fù)制功能不會阻塞主服務(wù)器： 即使有一個或多個從服務(wù)器正在進行初次同步， 主服務(wù)器也可以繼續(xù)處理命令請求。
復(fù)制功能也不會阻塞從服務(wù)器： 只要在 redis.conf 文件中進行了相應(yīng)的設(shè)置， 即使從服務(wù)器正在進行初次同步， 服務(wù)器也可以使用舊版本的數(shù)據(jù)集來處理命令查詢。
不過， 在從服務(wù)器刪除舊版本數(shù)據(jù)集并載入新版本數(shù)據(jù)集的那段時間內(nèi)， 連接請求會被阻塞。
你還可以配置從服務(wù)器， 讓它在與主服務(wù)器之間的連接斷開時， 向客戶端發(fā)送一個錯誤。
復(fù)制功能可以單純地用于數(shù)據(jù)冗余（data redundancy）， 也可以通過讓多個從服務(wù)器處理只讀命令請求來提升擴展性（scalability）： 比如說， 繁重的 SORT 命令可以交給附屬節(jié)點去運行。
可以通過復(fù)制功能來讓主服務(wù)器免于執(zhí)行持久化操作： 只要關(guān)閉主服務(wù)器的持久化功能， 然后由從服務(wù)器去執(zhí)行持久化操作即可。
關(guān)閉主服務(wù)器持久化時，復(fù)制功能的數(shù)據(jù)安全。
當配置Redis復(fù)制功能時，強烈建議打開主服務(wù)器的持久化功能。 否則的話，由于延遲等問題，部署的服務(wù)應(yīng)該要避免自動拉起。
案例：
假設(shè)節(jié)點A為主服務(wù)器，并且關(guān)閉了持久化。 并且節(jié)點B和節(jié)點C從節(jié)點A復(fù)制數(shù)據(jù)
節(jié)點A崩潰，然后由自動拉起服務(wù)重啟了節(jié)點A. 由于節(jié)點A的持久化被關(guān)閉了，所以重啟之后沒有任何數(shù)據(jù)
節(jié)點B和節(jié)點C將從節(jié)點A復(fù)制數(shù)據(jù)，但是A的數(shù)據(jù)是空的， 于是就把自身保存的數(shù)據(jù)副本刪除。
在關(guān)閉主服務(wù)器上的持久化，并同時開啟自動拉起進程的情況下，即便使用Sentinel來實現(xiàn)Redis的高可用性，也是非常危險的。 因為主服務(wù)器可能拉起得非?？?，以至于Sentinel在配置的心跳時間間隔內(nèi)沒有檢測到主服務(wù)器已被重啟，然后還是會執(zhí)行上面的數(shù)據(jù)丟失的流程。
無論何時，數(shù)據(jù)安全都是極其重要的，所以應(yīng)該禁止主服務(wù)器關(guān)閉持久化的同時自動拉起。
從服務(wù)器配置
配置一個從服務(wù)器非常簡單， 只要在配置文件中增加以下的這一行就可以了：
slaveof 192.168.1.1 6379
另外一種方法是調(diào)用 SLAVEOF 命令，輸入主服務(wù)器的 IP 和端口，然后同步就會開始
127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK
只讀從服務(wù)器
從 Redis 2.6 開始， 從服務(wù)器支持只讀模式， 并且該模式為從服務(wù)器的默認模式。
只讀模式由 redis.conf 文件中的 slave-read-only 選項控制， 也可以通過 CONFIG SET 命令來開啟或關(guān)閉這個模式。
只讀從服務(wù)器會拒絕執(zhí)行任何寫命令， 所以不會出現(xiàn)因為操作失誤而將數(shù)據(jù)不小心寫入到了從服務(wù)器的情況。
另外，對一個從屬服務(wù)器執(zhí)行命令 SLAVEOF NO ONE 將使得這個從屬服務(wù)器關(guān)閉復(fù)制功能，并從從屬服務(wù)器轉(zhuǎn)變回主服務(wù)器，原來同步所得的數(shù)據(jù)集不會被丟棄。
利用『 SLAVEOF NO ONE 不會丟棄同步所得數(shù)據(jù)集』這個特性，可以在主服務(wù)器失敗的時候，將從屬服務(wù)器用作新的主服務(wù)器，從而實現(xiàn)無間斷運行。
從服務(wù)器相關(guān)配置：
如果主服務(wù)器通過 requirepass 選項設(shè)置了密碼， 那么為了讓從服務(wù)器的同步操作可以順利進行， 我們也必須為從服務(wù)器進行相應(yīng)的身份驗證設(shè)置。
對于一個正在運行的服務(wù)器， 可以使用客戶端輸入以下命令：
config set masterauth
要永久地設(shè)置這個密碼， 那么可以將它加入到配置文件中：
masterauth
主服務(wù)器只在有至少 N 個從服務(wù)器的情況下，才執(zhí)行寫操作
從 Redis 2.8 開始， 為了保證數(shù)據(jù)的安全性，可以通過配置， 讓主服務(wù)器只在有至少 N 個當前已連接從服務(wù)器的情況下， 才執(zhí)行寫命令。
不過， 因為 Redis 使用異步復(fù)制， 所以主服務(wù)器發(fā)送的寫數(shù)據(jù)并不一定會被從服務(wù)器接收到， 因此， 數(shù)據(jù)丟失的可能性仍然是存在的。
以下是這個特性的運作原理：
從服務(wù)器以每秒一次的頻率 PING 主服務(wù)器一次， 并報告復(fù)制流的處理情況。
主服務(wù)器會記錄各個從服務(wù)器最后一次向它發(fā)送 PING 的時間。
用戶可以通過配置， 指定網(wǎng)絡(luò)延遲的最大值 min-slaves-max-lag ， 以及執(zhí)行寫操作所需的至少從服務(wù)器數(shù)量 min-slaves-to-write 。
如果至少有 min-slaves-to-write 個從服務(wù)器， 并且這些服務(wù)器的延遲值都少于 min-slaves-max-lag 秒， 那么主服務(wù)器就會執(zhí)行客戶端請求的寫操作。
另一方面， 如果條件達不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的條件， 那么寫操作就不會被執(zhí)行， 主服務(wù)器會向請求執(zhí)行寫操作的客戶端返回一個錯誤。
以下是這個特性的兩個選項和它們所需的參數(shù)：
min-slaves-to-writemin-slaves-max-lag
看完了這篇文章，相信你對Redis的持久化和主從復(fù)制機制是什么有了一定的了解，想了解更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！
分享文章：Redis的持久化和主從復(fù)制機制是什么
當前URL：http://fisionsoft.com.cn/article/psocgp.html
