???????????????????????????????????????????????????????????Redis主從復(fù)制下的工作原理

Redis主從復(fù)制的配置十分簡單，它可以使從服務(wù)器是主服務(wù)器的完全拷貝。需要清楚Redis主從復(fù)制的幾點(diǎn)重要內(nèi)容：

1）Redis使用異步復(fù)制。但從Redis 2.8開始，從服務(wù)器會周期性的應(yīng)答從復(fù)制流中處理的數(shù)據(jù)量。

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

3）從服務(wù)器也可以接受其他從服務(wù)器的連接。除了多個(gè)從服務(wù)器連接到一個(gè)主服務(wù)器之外，多個(gè)從服務(wù)器也可以連接到一個(gè)從服務(wù)器上，形成一個(gè)圖狀結(jié)構(gòu)。

4）Redis主從復(fù)制不阻塞主服務(wù)器端。也就是說當(dāng)若干個(gè)從服務(wù)器在進(jìn)行初始同步時(shí)，主服務(wù)器仍然可以處理請求。5）主從復(fù)制也不阻塞從服務(wù)器端。當(dāng)從服務(wù)器進(jìn)行初始同步時(shí)，它使用舊版本的數(shù)據(jù)來應(yīng)對查詢請求，假設(shè)你在redis.conf配置文件是這么配置的。???否則的話，你可以配置當(dāng)復(fù)制流關(guān)閉時(shí)讓從服務(wù)器給客戶端返回一個(gè)錯誤。但是，當(dāng)初始同步完成后，需要刪除舊的數(shù)據(jù)集和加載新的數(shù)據(jù)集，在???這個(gè)短暫的時(shí)間內(nèi)，從服務(wù)器會阻塞連接進(jìn)來的請求。6）主從復(fù)制可以用來增強(qiáng)擴(kuò)展性，使用多個(gè)從服務(wù)器來處理只讀的請求（比如，繁重的排序操作可以放到從服務(wù)器去做），也可以簡單的用來做數(shù)據(jù)冗余。7）使用主從復(fù)制可以為主服務(wù)器免除把數(shù)據(jù)寫入磁盤的消耗：在主服務(wù)器的redis.conf文件中配置“避免保存”（注釋掉所有“保存“命令），然后連接一個(gè)配

???置為“進(jìn)行保存”的從服務(wù)器即可。但是這個(gè)配置要確保主服務(wù)器不會自動重啟

當(dāng)主服務(wù)器不進(jìn)行持久化時(shí)復(fù)制的安全性

在進(jìn)行主從復(fù)制設(shè)置時(shí)，強(qiáng)烈建議在主服務(wù)器上開啟持久化，當(dāng)不能這么做時(shí)，比如考慮到延遲的問題，應(yīng)該將實(shí)例配置為避免自動重啟。為什么不持久化的主服務(wù)器自動重啟非常危險(xiǎn)呢？

為了更好的理解這個(gè)問題，看下面這個(gè)失敗的例子，其中主服務(wù)器和從服務(wù)器中數(shù)據(jù)庫都被刪除了。

設(shè)置節(jié)點(diǎn)A為主服務(wù)器，關(guān)閉持久化，節(jié)點(diǎn)B和C從節(jié)點(diǎn)A復(fù)制數(shù)據(jù)。這時(shí)出現(xiàn)了一個(gè)崩潰，但Redis具有自動重啟系統(tǒng)，重啟了進(jìn)程，因?yàn)殛P(guān)閉了持久化，節(jié)點(diǎn)重啟后只有一個(gè)空的數(shù)據(jù)集。節(jié)點(diǎn)B和C從節(jié)點(diǎn)A進(jìn)行復(fù)制，現(xiàn)在節(jié)點(diǎn)A是空的，所以節(jié)點(diǎn)B和C上的復(fù)制數(shù)據(jù)也會被刪除。當(dāng)在高可用系統(tǒng)中使用Redis Sentinel，關(guān)閉了主服務(wù)器的持久化，并且允許自動重啟，這種情況是很危險(xiǎn)的。比如主服務(wù)器可能在很短的時(shí)間就完成了重啟，以至于Sentinel都無法檢測到這次失敗，那么上面說的這種失敗的情況就發(fā)生了。

如果數(shù)據(jù)比較重要，并且在使用主從復(fù)制時(shí)關(guān)閉了主服務(wù)器持久化功能的場景中，都應(yīng)該禁止實(shí)例自動重啟。

Redis主從復(fù)制是如何工作的

如果設(shè)置了一個(gè)從服務(wù)器，在連接時(shí)它發(fā)送了一個(gè)SYNC命令，不管它是第一次連接還是再次連接都沒有關(guān)系。?然后主服務(wù)器開始后臺存儲，并且開始緩存新連接進(jìn)來的修改數(shù)據(jù)的命令。當(dāng)后臺存儲完成后，主服務(wù)器把數(shù)據(jù)文件發(fā)送到從服務(wù)器，從服務(wù)器將其保存在磁盤上，然后加載到內(nèi)存中。然后主服務(wù)器把剛才緩存的命令發(fā)送到從服務(wù)器。這是作為命令流來完成的，并且和Redis協(xié)議本身格式相同。?你可以通過telnet自己嘗試一下。在Redis服務(wù)器工作時(shí)連接到Redis端口，發(fā)送SYNC命令，會看到一個(gè)批量的傳輸，并且主服務(wù)器接收的每一個(gè)命令都會通過telnet會話重新發(fā)送一遍。?當(dāng)主從服務(wù)器之間的連接由于某些原因斷開時(shí)，從服務(wù)器可以自動進(jìn)行重連接。當(dāng)有多個(gè)從服務(wù)器同時(shí)請求同步時(shí)，主服務(wù)器只進(jìn)行一個(gè)后臺存儲。?當(dāng)連接斷開又重新連上之后，一般都會進(jìn)行一個(gè)完整的重新同步，但是從Redis2.8開始，只重新同步一部分也可以。

部分重新同步

從Redis 2.8開始，如果遭遇連接斷開，重新連接之后可以從中斷處繼續(xù)進(jìn)行復(fù)制，而不必重新同步。?它的工作原理是這樣：主服務(wù)器端為復(fù)制流維護(hù)一個(gè)內(nèi)存緩沖區(qū)（in-memory backlog）。主從服務(wù)器都維護(hù)一個(gè)復(fù)制偏移量（replication offset）和master run?id?，當(dāng)連接斷開時(shí)，從服務(wù)器會重新連接上主服務(wù)器，然后請求繼續(xù)復(fù)制，假如主從服務(wù)器的兩個(gè)master run?id相同，并且指定的偏移量在內(nèi)存緩沖區(qū)中還有效，復(fù)制就會從上次中斷的點(diǎn)開始繼續(xù)。如果其中一個(gè)條件不滿足，就會進(jìn)行完全重新同步（在2.8版本之前就是直接進(jìn)行完全重新同步）。因?yàn)橹鬟\(yùn)行id不保存在磁盤中，如果從服務(wù)器重啟了的話就只能進(jìn)行完全同步了。?部分重新同步這個(gè)新特性內(nèi)部使用PSYNC命令，舊的實(shí)現(xiàn)中使用SYNC命令。Redis2.8版本可以檢測出它所連接的服務(wù)器是否支持PSYNC命令，不支持的話使用SYNC命令。

無磁盤復(fù)制

通常來講，一個(gè)完全重新同步需要在磁盤上創(chuàng)建一個(gè)RDB文件，然后加載這個(gè)文件以便為從服務(wù)器發(fā)送數(shù)據(jù)。?如果使用比較低速的磁盤，這種操作會給主服務(wù)器帶來較大的壓力。Redis從2.8.18版本開始嘗試支持無磁盤的復(fù)制。使用這種設(shè)置時(shí)，子進(jìn)程直接將RDB通過網(wǎng)絡(luò)發(fā)送給從服務(wù)器，不使用磁盤作為中間存儲。

配置

主從復(fù)制的配置十分簡單：把下面這行加入到從服務(wù)器的配置文件中即可。slaveof 192.168.1.1 6379?當(dāng)然你需要把其中的192.168.1.1 6379替換為你自己的主服務(wù)器IP（或者主機(jī)名hostname）和端口。另外你可以調(diào)用SLAVEOF命令，主服務(wù)器就會開始與從服務(wù)器同步。?關(guān)于部分重新同步，還有一些針對復(fù)制內(nèi)存緩沖區(qū)的優(yōu)化參數(shù)。查看Redis介質(zhì)中的Redis.conf示例獲得更多信息。?使用repl-diskless-sync配置參數(shù)來啟動無磁盤復(fù)制。使用repl-diskless-sync-delay 參數(shù)來配置傳輸開始的延遲時(shí)間，以便等待更多的從服務(wù)器連接上來。查看Redis介質(zhì)中的Redis.conf示例獲得更多信息。

只讀從服務(wù)器

從Redis 2.6開始，從服務(wù)器支持只讀模式，并且是默認(rèn)模式。這個(gè)行為是由Redis.conf文件中的slave-read-only 參數(shù)控制的，可以在運(yùn)行中通過CONFIG SET來啟用或者禁用。?只讀的從服務(wù)器會拒絕所有寫命令，所以對從服務(wù)器不會有誤寫操作。但這不表示可以把從服務(wù)器實(shí)例暴露在危險(xiǎn)的網(wǎng)絡(luò)環(huán)境下，因?yàn)橄馜EBUG或者CONFIG這樣的管理命令還是可以運(yùn)行的。不過你可以通過使用rename-command命令來為這些命令改名來增加安全性。?你可能想知道為什么只讀限制還可以被還原，使得從服務(wù)器還可以進(jìn)行寫操作。雖然當(dāng)主從服務(wù)器進(jìn)行重新同步或者從服務(wù)器重啟后，這些寫操作都會失效，還是有一些使用場景會想從服務(wù)器中寫入臨時(shí)數(shù)據(jù)的，但將來這個(gè)特性可能會被去掉。

限制有N個(gè)以上從服務(wù)器才允許寫入

從Redis 2.8版本開始，可以配置主服務(wù)器連接N個(gè)以上從服務(wù)器才允許對主服務(wù)器進(jìn)行寫操作。但是，因?yàn)镽edis使用的是異步主從復(fù)制，沒辦法確保從服務(wù)器確實(shí)收到了要寫入的數(shù)據(jù)，所以還是有一定的數(shù)據(jù)丟失的可能性。?這一特性的工作原理如下：1）從服務(wù)器每秒鐘ping一次主服務(wù)器，確認(rèn)處理的復(fù)制流數(shù)量。2）主服務(wù)器記住每個(gè)從服務(wù)器最近一次ping的時(shí)間。3）用戶可以配置最少要有N個(gè)服務(wù)器有小于M秒的確認(rèn)延遲。4）如果有N個(gè)以上從服務(wù)器，并且確認(rèn)延遲小于M秒，主服務(wù)器接受寫操作。?還可以把這看做是CAP原則（一致性，可用性，分區(qū)容錯性）不嚴(yán)格的一致性實(shí)現(xiàn)，雖然不能百分百確保一致性，但至少保證了丟失的數(shù)據(jù)不會超過M秒內(nèi)的數(shù)據(jù)量。?如果條件不滿足，主服務(wù)器會拒絕寫操作并返回一個(gè)錯誤。1）min-slaves-to-write（最小從服務(wù)器數(shù)）2）min-slaves-max-lag（從服務(wù)器最大確認(rèn)延遲）

轉(zhuǎn)載于:https://blog.51cto.com/13362895/2135255

總結(jié)

以上是生活随笔為你收集整理的Redis主从复制下的工作原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。