Redis的持久化和主從復(fù)制機(jī)制是什么

小編給大家分享一下Redis的持久化和主從復(fù)制機(jī)制是什么，希望大家閱讀完這篇文章后大所收獲，下面讓我們一起去探討吧！

Redis持久化

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

RDB 持久化可以在指定的時(shí)間間隔內(nèi)生成數(shù)據(jù)集的時(shí)間點(diǎn)快照（point-in-time snapshot）

AOF 持久化記錄服務(wù)器執(zhí)行的所有寫(xiě)操作命令，并在服務(wù)器啟動(dòng)時(shí)，通過(guò)重新執(zhí)行這些命令來(lái)還原數(shù)據(jù)集。 AOF 文件中的命令全部以 Redis 協(xié)議的格式來(lái)保存，新命令會(huì)被追加到文件的末尾。 Redis 還可以在后臺(tái)對(duì) AOF 文件進(jìn)行重寫(xiě)（rewrite），使得 AOF 文件的體積不會(huì)超出保存數(shù)據(jù)集狀態(tài)所需的實(shí)際大小。

Redis 還可以同時(shí)使用 AOF 持久化和 RDB 持久化。 在這種情況下， 當(dāng) Redis 重啟時(shí)， 它會(huì)優(yōu)先使用 AOF 文件來(lái)還原數(shù)據(jù)集， 因?yàn)?AOF 文件保存的數(shù)據(jù)集通常比 RDB 文件所保存的數(shù)據(jù)集更完整。
你甚至可以關(guān)閉持久化功能，讓數(shù)據(jù)只在服務(wù)器運(yùn)行時(shí)存在。

RDB(Redis DataBase)

Rdb:在指定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫(xiě)入磁盤(pán)，也就是行話講的 snapshot 快照，它恢復(fù)時(shí)就是將快照文件直接讀到內(nèi)存里。

Redis 會(huì)單獨(dú)的創(chuàng)建(fork) 一個(gè)子進(jìn)程來(lái)進(jìn)行持久化，會(huì)先將數(shù)據(jù)寫(xiě)入到一個(gè)臨時(shí)文件中，待持久化過(guò)程結(jié)束了，再用這個(gè)臨時(shí)文件替換上次持久化還的文件。整個(gè)過(guò)程總，主進(jìn)程是不進(jìn)行任何 IO 操作，這就確保了極高的性能，如果需要進(jìn)行大規(guī)模的數(shù)據(jù)恢復(fù)，且對(duì)于數(shù)據(jù)恢復(fù)的完整性不是非常敏感，那 RDB 方法要比 AOF 方式更加的高效。RDB 的缺點(diǎn)是最后一次持久化后的數(shù)據(jù)可能丟失。

Fork 的作用是復(fù)制一個(gè)與當(dāng)前進(jìn)程一樣的進(jìn)程，新進(jìn)程的所有數(shù)據(jù)(變量、環(huán)境變量、程序計(jì)數(shù)器等)數(shù)值都和原進(jìn)程一致，但是是一個(gè)全新的進(jìn)程，并作為原進(jìn)程的子進(jìn)程

隱患：若當(dāng)前的進(jìn)程的數(shù)據(jù)量龐大，那么 fork 之后數(shù)據(jù)量*2,此時(shí)就會(huì)造成服務(wù)器壓力大，運(yùn)行性能降低。

Rdb 保存的是 dump.rdb 文件

在測(cè)試：執(zhí)行 flushAll 命令, 使用 shutDown 直接關(guān)閉進(jìn)程時(shí)，第二次打開(kāi)時(shí) redis 會(huì)自動(dòng)讀取 dump.rdb 文件，但是恢復(fù)時(shí)，全為空。(此時(shí)的原因：在關(guān)閉時(shí)刻，redis 系統(tǒng)會(huì)保存空的 dump.rdb 替換原來(lái)的緩存文件。所以第二次打開(kāi)的 redis系統(tǒng)時(shí)候，自動(dòng)讀取的是空值文件)

RDB save 操作

Rdb 是整個(gè)內(nèi)存的壓縮的 snapshot，RDB 的數(shù)據(jù)結(jié)構(gòu)，可以配置符合快照觸發(fā)條件，默認(rèn)的是 1 分鐘內(nèi)改動(dòng) 1 萬(wàn)次，或者 5 分鐘改動(dòng) 10 次，或者是 15 分鐘改動(dòng)一次；
Save 禁用：如果想禁用 RDB 持久化的策略，只要不設(shè)置任何 save 指令，或者是給 save 傳入一個(gè)空字符串參數(shù)也可以。

-----> save 指令：即刻保存操作對(duì)象

如何觸發(fā) RDB 快照

Save：save 時(shí)只管保存，其他不管，全部阻塞。

Bgsave：redis 會(huì)在后臺(tái)進(jìn)行快照操作，快照操作的同時(shí)還可以響應(yīng)客戶端的請(qǐng)求，可以通過(guò) lastsave 命令獲取最后一次成功執(zhí)行快照的時(shí)間。

執(zhí)行 fluhall 命令，也會(huì)產(chǎn)生 dump.rdb 文件，但里面是空的。

如何恢復(fù):

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

如何停止

動(dòng)態(tài)停止 RDB 保存規(guī)則的方法：redis -cli config set save “”

AOF(Append Only File)

以日志的形式倆記錄每個(gè)寫(xiě)操作，將 redis 執(zhí)行過(guò)的所有寫(xiě)指令記錄下來(lái)(讀操作不記錄)。只許追加文件但不可以改寫(xiě)文件，redis 啟動(dòng)之初會(huì)讀取該文件重新構(gòu)建數(shù)據(jù)，換言之，redis重啟的話就根據(jù)日志文件的內(nèi)容將寫(xiě)指令從前到后執(zhí)行一次一完成數(shù)據(jù)恢復(fù)工作。
======APPEND ONLY MODE=====

開(kāi)啟 aof ：appendonly yes  (默認(rèn)是 no)

注意：

在實(shí)際工作生產(chǎn)的時(shí)候往往會(huì)出現(xiàn)：aof 文件損壞(網(wǎng)絡(luò)傳輸或者其他問(wèn)題導(dǎo)致 aof 文件破壞)

服務(wù)器啟動(dòng)報(bào)錯(cuò)(但是 dump.rdb 文件是完整的) 說(shuō)明啟動(dòng)先加載 aof 文件

解決方案：執(zhí)行命令 redis-check-aof --fix aof 文件 [自動(dòng)檢查刪除不和 aof 語(yǔ)法的字段]

Aof策略

Appendfsync 參數(shù)：

Always 同步持久化 每次發(fā)生數(shù)據(jù)變更會(huì)被立即記錄到磁盤(pán)，性能較差但數(shù)據(jù)完整性較好。
Everysec： 出廠默認(rèn)推薦，異步操作，每秒記錄，日過(guò)一秒宕機(jī)，有數(shù)據(jù)丟失
No：從不 fsync ：將數(shù)據(jù)交給操作系統(tǒng)來(lái)處理。更快，也更不安全的選擇。

Rewrite

概念：AOF 采用文件追加方式，文件會(huì)越來(lái)越來(lái)大為避免出現(xiàn)此種情況，新增了重寫(xiě)機(jī)制，aof 文件的大小超過(guò)所設(shè)定的閾值時(shí)，redis 就會(huì)自動(dòng) aof 文件的內(nèi)容壓縮，值保留可以恢復(fù)數(shù)據(jù)的最小指令集，可以使用命令 bgrewirteaof。

重寫(xiě)原理：aof 文件持續(xù)增長(zhǎng)而大時(shí)，會(huì) fork 出一條新進(jìn)程來(lái)將文件重寫(xiě)(也就
是先寫(xiě)臨時(shí)文件最后再 rename)，遍歷新進(jìn)程的內(nèi)存中的數(shù)據(jù)，每條記錄有一條 set 語(yǔ)句，重寫(xiě) aof 文件的操作，并沒(méi)有讀取舊的的 aof 文件，而是將整個(gè)內(nèi)存的數(shù)據(jù)庫(kù)內(nèi)容用命令的方式重寫(xiě)了一個(gè)新的 aof 文件，這點(diǎn)和快照有點(diǎn)類似。

觸發(fā)機(jī)制：redis 會(huì)記錄上次重寫(xiě)的 aof 的大小，默認(rèn)的配置當(dāng) aof 文件大小上次 rewrite 后大小的一倍且文件大于 64M 觸發(fā)(3G)

no-appendfsync-on-rewrite no : 重寫(xiě)時(shí)是否可以運(yùn)用 Appendfsync 用默認(rèn) no 即可，保證數(shù)據(jù)安全
auto-aof-rewrite-percentage  倍數(shù) 設(shè)置基準(zhǔn)值
auto-aof-rewrite-min-size  設(shè)置基準(zhǔn)值大小

AOF優(yōu)點(diǎn)

使用 AOF 持久化會(huì)讓 Redis 變得非常耐久：你可以設(shè)置不同的 fsync 策略，比如無(wú) fsync ，每秒鐘一次 fsync ，或者每次執(zhí)行寫(xiě)入命令時(shí) fsync 。 AOF 的默認(rèn)策略為每秒鐘 fsync 一次，在這種配置下，Redis 仍然可以保持良好的性能，并且就算發(fā)生故障停機(jī)，也最多只會(huì)丟失一秒鐘的數(shù)據(jù)（ fsync 會(huì)在后臺(tái)線程執(zhí)行，所以主線程可以繼續(xù)努力地處理命令請(qǐng)求）。

AOF 文件是一個(gè)只進(jìn)行追加操作的日志文件（append only log）， 因此對(duì) AOF 文件的寫(xiě)入不需要進(jìn)行 seek ， 即使日志因?yàn)槟承┰蚨宋磳?xiě)入完整的命令（比如寫(xiě)入時(shí)磁盤(pán)已滿，寫(xiě)入中途停機(jī)，等等）， redis-check-aof 工具也可以輕易地修復(fù)這種問(wèn)題。

Redis 可以在 AOF 文件體積變得過(guò)大時(shí)，自動(dòng)地在后臺(tái)對(duì) AOF 進(jìn)行重寫(xiě)： 重寫(xiě)后的新 AOF 文件包含了恢復(fù)當(dāng)前數(shù)據(jù)集所需的最小命令集合。 整個(gè)重寫(xiě)操作是絕對(duì)安全的，因?yàn)?Redis 在創(chuàng)建新 AOF 文件的過(guò)程中，會(huì)繼續(xù)將命令追加到現(xiàn)有的 AOF 文件里面，即使重寫(xiě)過(guò)程中發(fā)生停機(jī)，現(xiàn)有的 AOF 文件也不會(huì)丟失。 而一旦新 AOF 文件創(chuàng)建完畢，Redis 就會(huì)從舊 AOF 文件切換到新 AOF 文件，并開(kāi)始對(duì)新 AOF 文件進(jìn)行追加操作。

AOF 文件有序地保存了對(duì)數(shù)據(jù)庫(kù)執(zhí)行的所有寫(xiě)入操作， 這些寫(xiě)入操作以 Redis 協(xié)議的格式保存， 因此 AOF 文件的內(nèi)容非常容易被人讀懂， 對(duì)文件進(jìn)行分析（parse）也很輕松。 導(dǎo)出（export） AOF 文件也非常簡(jiǎn)單： 舉個(gè)例子， 如果你不小心執(zhí)行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫(xiě)， 那么只要停止服務(wù)器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重啟 Redis ， 就可以將數(shù)據(jù)集恢復(fù)到 FLUSHALL 執(zhí)行之前的狀態(tài)。

AOF缺點(diǎn)

對(duì)于相同的數(shù)據(jù)集來(lái)說(shuō)，AOF 文件的體積通常要大于 RDB 文件的體積。

根據(jù)所使用的 fsync 策略，AOF 的速度可能會(huì)慢于 RDB 。 在一般情況下， 每秒 fsync 的性能依然非常高， 而關(guān)閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負(fù)荷之下也是如此。 不過(guò)在處理巨大的寫(xiě)入載入時(shí)，RDB 可以提供更有保證的最大延遲時(shí)間（latency）。

AOF 在過(guò)去曾經(jīng)發(fā)生過(guò)這樣的 bug ： 因?yàn)閭€(gè)別命令的原因，導(dǎo)致 AOF 文件在重新載入時(shí)，無(wú)法將數(shù)據(jù)集恢復(fù)成保存時(shí)的原樣。 （舉個(gè)例子，阻塞命令 BRPOPLPUSH 就曾經(jīng)引起過(guò)這樣的 bug 。）

測(cè)試套件里為這種情況添加了測(cè)試： 它們會(huì)自動(dòng)生成隨機(jī)的、復(fù)雜的數(shù)據(jù)集，并通過(guò)重新載入這些數(shù)據(jù)來(lái)確保一切正常。雖然這種 bug 在 AOF 文件中并不常見(jiàn)， 但是對(duì)比來(lái)說(shuō)， RDB 幾乎是不可能出現(xiàn)這種 bug 的。

備份Redis 數(shù)據(jù)

一定要備份你的數(shù)據(jù)庫(kù)！

磁盤(pán)故障， 節(jié)點(diǎn)失效， 諸如此類的問(wèn)題都可能讓你的數(shù)據(jù)消失不見(jiàn)， 不進(jìn)行備份是非常危險(xiǎn)的。

Redis 對(duì)于數(shù)據(jù)備份是非常友好的， 因?yàn)槟憧梢栽诜?wù)器運(yùn)行的時(shí)候?qū)?RDB 文件進(jìn)行復(fù)制： RDB 文件一旦被創(chuàng)建， 就不會(huì)進(jìn)行任何修改。 當(dāng)服務(wù)器要?jiǎng)?chuàng)建一個(gè)新的 RDB 文件時(shí)， 它先將文件的內(nèi)容保存在一個(gè)臨時(shí)文件里面， 當(dāng)臨時(shí)文件寫(xiě)入完畢時(shí)， 程序才使用 rename(2) 原子地用臨時(shí)文件替換原來(lái)的 RDB 文件。

這也就是說(shuō)， 無(wú)論何時(shí)， 復(fù)制 RDB 文件都是絕對(duì)安全的。

建議：

創(chuàng)建一個(gè)定期任務(wù)（cron job）， 每小時(shí)將一個(gè) RDB 文件備份到一個(gè)文件夾， 并且每天將一個(gè) RDB 文件備份到另一個(gè)文件夾。

確?？煺盏膫浞荻紟в邢鄳?yīng)的日期和時(shí)間信息， 每次執(zhí)行定期任務(wù)腳本時(shí)， 使用 find 命令來(lái)刪除過(guò)期的快照： 比如說(shuō)， 你可以保留最近 48 小時(shí)內(nèi)的每小時(shí)快照， 還可以保留最近一兩個(gè)月的每日快照。

至少每天一次， 將 RDB 備份到你的數(shù)據(jù)中心之外， 或者至少是備份到你運(yùn)行 Redis 服務(wù)器的物理機(jī)器之外。

容災(zāi)備份

Redis 的容災(zāi)備份基本上就是對(duì)數(shù)據(jù)進(jìn)行備份， 并將這些備份傳送到多個(gè)不同的外部數(shù)據(jù)中心。

容災(zāi)備份可以在 Redis 運(yùn)行并產(chǎn)生快照的主數(shù)據(jù)中心發(fā)生嚴(yán)重的問(wèn)題時(shí)， 仍然讓數(shù)據(jù)處于安全狀態(tài)。

有的Redis 用戶是創(chuàng)業(yè)者， 他們沒(méi)有大把大把的錢(qián)可以浪費(fèi)， 所以下面介紹的都是一些實(shí)用又便宜的容災(zāi)備份方法：

Amazon S3 ，以及其他類似 S3 的服務(wù)，是一個(gè)構(gòu)建災(zāi)難備份系統(tǒng)的好地方。 最簡(jiǎn)單的方法就是將你的每小時(shí)或者每日 RDB 備份加密并傳送到 S3 。 對(duì)數(shù)據(jù)的加密可以通過(guò) gpg -c 命令來(lái)完成（對(duì)稱加密模式）。 記得把你的密碼放到幾個(gè)不同的、安全的地方去（比如你可以把密碼復(fù)制給你組織里最重要的人物）。 同時(shí)使用多個(gè)儲(chǔ)存服務(wù)來(lái)保存數(shù)據(jù)文件，可以提升數(shù)據(jù)的安全性。

傳送快照可以使用 SCP 來(lái)完成（SSH 的組件）。 以下是簡(jiǎn)單并且安全的傳送方法： 買一個(gè)離你的數(shù)據(jù)中心非常遠(yuǎn)的 VPS(虛擬專用服務(wù)器) ， 裝上 SSH ， 創(chuàng)建一個(gè)無(wú)口令的 SSH 客戶端 key ， 并將這個(gè) key 添加到 VPS 的 authorized_keys 文件中， 這樣就可以向這個(gè) VPS 傳送快照備份文件了。 為了達(dá)到最好的數(shù)據(jù)安全性，至少要從兩個(gè)不同的提供商那里各購(gòu)買一個(gè) VPS 來(lái)進(jìn)行數(shù)據(jù)容災(zāi)備份。

需要注意的是， 這類容災(zāi)系統(tǒng)如果沒(méi)有小心地進(jìn)行處理的話， 是很容易失效的。

最低限度下， 你應(yīng)該在文件傳送完畢之后， 檢查所傳送備份文件的體積和原始快照文件的體積是否相同。 如果你使用的是 VPS ， 那么還可以通過(guò)比對(duì)文件的 SHA1 校驗(yàn)和來(lái)確認(rèn)文件是否傳送完整。

另外， 你還需要一個(gè)獨(dú)立的警報(bào)系統(tǒng)， 讓它在負(fù)責(zé)傳送備份文件的傳送器（transfer）失靈時(shí)通知你。

Redis主從復(fù)制

Redis 支持簡(jiǎn)單且易用的主從復(fù)制（master-slave replication）功能， 該功能可以讓從服務(wù)器(slave server)成為主服務(wù)器(master server)的精確復(fù)制品。

以下是關(guān)于 Redis 復(fù)制功能的幾個(gè)重要方面：

Redis 使用異步復(fù)制。 從 Redis 2.8 開(kāi)始， 從服務(wù)器會(huì)以每秒一次的頻率向主服務(wù)器報(bào)告復(fù)制流（replication stream）的處理進(jìn)度。

一個(gè)主服務(wù)器可以有多個(gè)從服務(wù)器。

不僅主服務(wù)器可以有從服務(wù)器， 從服務(wù)器也可以有自己的從服務(wù)器， 多個(gè)從服務(wù)器之間可以構(gòu)成一個(gè)圖狀結(jié)構(gòu)。

復(fù)制功能不會(huì)阻塞主服務(wù)器： 即使有一個(gè)或多個(gè)從服務(wù)器正在進(jìn)行初次同步， 主服務(wù)器也可以繼續(xù)處理命令請(qǐng)求。

復(fù)制功能也不會(huì)阻塞從服務(wù)器： 只要在 redis.conf 文件中進(jìn)行了相應(yīng)的設(shè)置， 即使從服務(wù)器正在進(jìn)行初次同步， 服務(wù)器也可以使用舊版本的數(shù)據(jù)集來(lái)處理命令查詢。

不過(guò)， 在從服務(wù)器刪除舊版本數(shù)據(jù)集并載入新版本數(shù)據(jù)集的那段時(shí)間內(nèi)， 連接請(qǐng)求會(huì)被阻塞。

你還可以配置從服務(wù)器， 讓它在與主服務(wù)器之間的連接斷開(kāi)時(shí)， 向客戶端發(fā)送一個(gè)錯(cuò)誤。

復(fù)制功能可以單純地用于數(shù)據(jù)冗余（data redundancy）， 也可以通過(guò)讓多個(gè)從服務(wù)器處理只讀命令請(qǐng)求來(lái)提升擴(kuò)展性（scalability）： 比如說(shuō)， 繁重的 SORT 命令可以交給附屬節(jié)點(diǎn)去運(yùn)行。
可以通過(guò)復(fù)制功能來(lái)讓主服務(wù)器免于執(zhí)行持久化操作： 只要關(guān)閉主服務(wù)器的持久化功能， 然后由從服務(wù)器去執(zhí)行持久化操作即可。

關(guān)閉主服務(wù)器持久化時(shí)，復(fù)制功能的數(shù)據(jù)安全。

當(dāng)配置Redis復(fù)制功能時(shí)，強(qiáng)烈建議打開(kāi)主服務(wù)器的持久化功能。 否則的話，由于延遲等問(wèn)題，部署的服務(wù)應(yīng)該要避免自動(dòng)拉起。

案例：

1. 假設(shè)節(jié)點(diǎn)A為主服務(wù)器，并且關(guān)閉了持久化。 并且節(jié)點(diǎn)B和節(jié)點(diǎn)C從節(jié)點(diǎn)A復(fù)制數(shù)據(jù)

2. 節(jié)點(diǎn)A崩潰，然后由自動(dòng)拉起服務(wù)重啟了節(jié)點(diǎn)A. 由于節(jié)點(diǎn)A的持久化被關(guān)閉了，所以重啟之后沒(méi)有任何數(shù)據(jù)

3. 節(jié)點(diǎn)B和節(jié)點(diǎn)C將從節(jié)點(diǎn)A復(fù)制數(shù)據(jù)，但是A的數(shù)據(jù)是空的， 于是就把自身保存的數(shù)據(jù)副本刪除。

在關(guān)閉主服務(wù)器上的持久化，并同時(shí)開(kāi)啟自動(dòng)拉起進(jìn)程的情況下，即便使用Sentinel來(lái)實(shí)現(xiàn)Redis的高可用性，也是非常危險(xiǎn)的。 因?yàn)橹鞣?wù)器可能拉起得非?？?，以至于Sentinel在配置的心跳時(shí)間間隔內(nèi)沒(méi)有檢測(cè)到主服務(wù)器已被重啟，然后還是會(huì)執(zhí)行上面的數(shù)據(jù)丟失的流程。

無(wú)論何時(shí)，數(shù)據(jù)安全都是極其重要的，所以應(yīng)該禁止主服務(wù)器關(guān)閉持久化的同時(shí)自動(dòng)拉起。

從服務(wù)器配置

配置一個(gè)從服務(wù)器非常簡(jiǎn)單， 只要在配置文件中增加以下的這一行就可以了：
slaveof 192.168.1.1 6379
另外一種方法是調(diào)用 SLAVEOF 命令，輸入主服務(wù)器的 IP 和端口，然后同步就會(huì)開(kāi)始
127.0.0.1:6379> SLAVEOF 192.168.1.1 10086
OK

只讀從服務(wù)器

從 Redis 2.6 開(kāi)始， 從服務(wù)器支持只讀模式， 并且該模式為從服務(wù)器的默認(rèn)模式。
只讀模式由 redis.conf 文件中的 slave-read-only 選項(xiàng)控制， 也可以通過(guò) CONFIG SET 命令來(lái)開(kāi)啟或關(guān)閉這個(gè)模式。

只讀從服務(wù)器會(huì)拒絕執(zhí)行任何寫(xiě)命令， 所以不會(huì)出現(xiàn)因?yàn)椴僮魇д`而將數(shù)據(jù)不小心寫(xiě)入到了從服務(wù)器的情況。

另外，對(duì)一個(gè)從屬服務(wù)器執(zhí)行命令 SLAVEOF NO ONE 將使得這個(gè)從屬服務(wù)器關(guān)閉復(fù)制功能，并從從屬服務(wù)器轉(zhuǎn)變回主服務(wù)器，原來(lái)同步所得的數(shù)據(jù)集不會(huì)被丟棄。

利用『 SLAVEOF NO ONE 不會(huì)丟棄同步所得數(shù)據(jù)集』這個(gè)特性，可以在主服務(wù)器失敗的時(shí)候，將從屬服務(wù)器用作新的主服務(wù)器，從而實(shí)現(xiàn)無(wú)間斷運(yùn)行。

從服務(wù)器相關(guān)配置：

如果主服務(wù)器通過(guò) requirepass 選項(xiàng)設(shè)置了密碼， 那么為了讓從服務(wù)器的同步操作可以順利進(jìn)行， 我們也必須為從服務(wù)器進(jìn)行相應(yīng)的身份驗(yàn)證設(shè)置。

對(duì)于一個(gè)正在運(yùn)行的服務(wù)器， 可以使用客戶端輸入以下命令：
config set masterauth <password>
要永久地設(shè)置這個(gè)密碼， 那么可以將它加入到配置文件中：
masterauth <password>

主服務(wù)器只在有至少 N 個(gè)從服務(wù)器的情況下，才執(zhí)行寫(xiě)操作

從 Redis 2.8 開(kāi)始， 為了保證數(shù)據(jù)的安全性，可以通過(guò)配置， 讓主服務(wù)器只在有至少 N 個(gè)當(dāng)前已連接從服務(wù)器的情況下， 才執(zhí)行寫(xiě)命令。

不過(guò)， 因?yàn)?Redis 使用異步復(fù)制， 所以主服務(wù)器發(fā)送的寫(xiě)數(shù)據(jù)并不一定會(huì)被從服務(wù)器接收到， 因此， 數(shù)據(jù)丟失的可能性仍然是存在的。

以下是這個(gè)特性的運(yùn)作原理：

從服務(wù)器以每秒一次的頻率 PING 主服務(wù)器一次， 并報(bào)告復(fù)制流的處理情況。
主服務(wù)器會(huì)記錄各個(gè)從服務(wù)器最后一次向它發(fā)送 PING 的時(shí)間。

用戶可以通過(guò)配置， 指定網(wǎng)絡(luò)延遲的最大值 min-slaves-max-lag ， 以及執(zhí)行寫(xiě)操作所需的至少?gòu)姆?wù)器數(shù)量 min-slaves-to-write 。

如果至少有 min-slaves-to-write 個(gè)從服務(wù)器， 并且這些服務(wù)器的延遲值都少于 min-slaves-max-lag 秒， 那么主服務(wù)器就會(huì)執(zhí)行客戶端請(qǐng)求的寫(xiě)操作。

另一方面， 如果條件達(dá)不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的條件， 那么寫(xiě)操作就不會(huì)被執(zhí)行， 主服務(wù)器會(huì)向請(qǐng)求執(zhí)行寫(xiě)操作的客戶端返回一個(gè)錯(cuò)誤。

以下是這個(gè)特性的兩個(gè)選項(xiàng)和它們所需的參數(shù)：

min-slaves-to-write <number of slaves>
min-slaves-max-lag <number of seconds>

看完了這篇文章，相信你對(duì)Redis的持久化和主從復(fù)制機(jī)制是什么有了一定的了解，想了解更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！