本篇內(nèi)容介紹了“redis的持久化和主從復(fù)制詳細(xì)講解”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的瓊海網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！

什么是Redis持久化?

Redis作為一個鍵值對內(nèi)存數(shù)據(jù)庫(NOSQL)，數(shù)據(jù)都存儲在內(nèi)存當(dāng)中，在處理客戶端請求時，所有操作都在內(nèi)存當(dāng)中進行，如下所示：

這樣做有什么問題呢？

其實，只要稍微有點計算機基礎(chǔ)知識的人都知道，存儲在內(nèi)存當(dāng)中的數(shù)據(jù)，只要服務(wù)器關(guān)機(各種原因引起的)，內(nèi)存中的數(shù)據(jù)就會消失了，不僅服務(wù)器關(guān)機會造成數(shù)據(jù)消失，Redis服務(wù)器守護進程退出，內(nèi)存中的數(shù)據(jù)也一樣會消失。

對于只把Redis當(dāng)緩存來用的項目來說，數(shù)據(jù)消失或許問題不大，重新從數(shù)據(jù)源把數(shù)據(jù)加載進來就可以了，但如果直接把用戶提交的業(yè)務(wù)數(shù)據(jù)存儲在Redis當(dāng)中，把Redis作為數(shù)據(jù)庫來使用，在其放存儲重要業(yè)務(wù)數(shù)據(jù)，那么Redis的內(nèi)存數(shù)據(jù)丟失所造成的影響也許是毀滅性。為了避免內(nèi)存中數(shù)據(jù)丟失，Redis提供了對持久化的支持，我們可以選擇不同的方式將數(shù)據(jù)從內(nèi)存中保存到硬盤當(dāng)中，使數(shù)據(jù)可以持久化保存。

Redis提供了RDB和AOF兩種不同的數(shù)據(jù)持久化方式，下面我們就來詳細(xì)介紹一下這種不同的持久化方式吧。

RDB

RDB是一種快照存儲持久化方式，具體就是將Redis某一時刻的內(nèi)存數(shù)據(jù)保存到硬盤的文件當(dāng)中，默認(rèn)保存的文件名為dump.rdb，而在Redis服務(wù)器啟動時，會重新加載dump.rdb文件的數(shù)據(jù)到內(nèi)存當(dāng)中恢復(fù)數(shù)據(jù)。

開啟RDB持久化方式

開啟RDB持久化方式很簡單，客戶端可以通過向Redis服務(wù)器發(fā)送save或bgsave命令讓服務(wù)器生成rdb文件，或者通過服務(wù)器配置文件指定觸發(fā)RDB條件。

1. save命令

save命令是一個同步操作。

# 異步保存數(shù)據(jù)集到磁盤上> bgsave

當(dāng)客戶端發(fā)服務(wù)發(fā)出bgsave命令時，Redis服務(wù)器主進程會forks一個子進程來數(shù)據(jù)同步問題，在將數(shù)據(jù)保存到rdb文件之后，子進程會退出。

所以，與save命令相比，Redis服務(wù)器在處理bgsave采用子線程進行IO寫入，而主進程仍然可以接收其他請求，但forks子進程是同步的，所以forks子進程時，一樣不能接收其他請求，這意味著，如果forks一個子進程花費的時間太久(一般是很快的)，bgsave命令仍然有阻塞其他客戶的請求的情況發(fā)生。

3. 服務(wù)器配置自動觸發(fā)

除了通過客戶端發(fā)送命令外，還有一種方式，就是在Redis配置文件中的save指定到達觸發(fā)RDB持久化的條件，比如【多少秒內(nèi)至少達到多少寫操作】就開啟RDB數(shù)據(jù)同步。

例如我們可以在配置文件redis.conf指定如下的選項：

# 900s內(nèi)至少達到一條寫命令
save 900 1# 300s內(nèi)至少達至10條寫命令
save 300 10# 60s內(nèi)至少達到10000條寫命令
save 60 10000

之后在啟動服務(wù)器時加載配置文件。

# 啟動服務(wù)器加載配置文件
redis-server redis.conf

這種通過服務(wù)器配置文件觸發(fā)RDB的方式，與bgsave命令類似，達到觸發(fā)條件時，會forks一個子進程進行數(shù)據(jù)同步，不過最好不要通過這方式來觸發(fā)RDB持久化，因為設(shè)置觸發(fā)的時間太短，則容易頻繁寫入rdb文件，影響服務(wù)器性能，時間設(shè)置太長則會造成數(shù)據(jù)丟失。

rdb文件

前面介紹了三種讓服務(wù)器生成rdb文件的方式，無論是由主進程生成還是子進程來生成，其過程如下：

1. 生成臨時rdb文件，并寫入數(shù)據(jù)。

2. 完成數(shù)據(jù)寫入，用臨時文代替代正式rdb文件。

3. 刪除原來的db文件。

RDB默認(rèn)生成的文件名為dump.rdb，當(dāng)然，我可以通過配置文件進行更加詳細(xì)配置，比如在單機下啟動多個redis服務(wù)器進程時，可以通過端口號配置不同的rdb名稱，如下所示：

# 是否壓縮rdb文件
rdbcompression yes
# rdb文件的名稱
dbfilename redis-6379.rdb
# rdb文件保存目錄
dir ~/redis/

RDB的幾個優(yōu)點

1. 與AOF方式相比，通過rdb文件恢復(fù)數(shù)據(jù)比較快。

2. rdb文件非常緊湊，適合于數(shù)據(jù)備份。

3. 通過RDB進行數(shù)據(jù)備，由于使用子進程生成，所以對Redis服務(wù)器性能影響較小。

RDB的幾個缺點

1. 如果服務(wù)器宕機的話，采用RDB的方式會造成某個時段內(nèi)數(shù)據(jù)的丟失，比如我們設(shè)置10分鐘同步一次或5分鐘達到1000次寫入就同步一次，那么如果還沒達到觸發(fā)條件服務(wù)器就死機了，那么這個時間段的數(shù)據(jù)會丟失。

2. 使用save命令會造成服務(wù)器阻塞，直接數(shù)據(jù)同步完成才能接收后續(xù)請求。

3. 使用bgsave命令在forks子進程時，如果數(shù)據(jù)量太大，forks的過程也會發(fā)生阻塞，另外，forks子進程會耗費內(nèi)存。

AOF

聊完了RDB，來聊聊Redis的另外一個持久化方式：AOF(Append-only file)。
與RDB存儲某個時刻的快照不同，AOF持久化方式會記錄客戶端對服務(wù)器的每一次寫操作命令，并將這些寫操作以Redis協(xié)議追加保存到以后綴為aof文件末尾，在Redis服務(wù)器重啟時，會加載并運行aof文件的命令，以達到恢復(fù)數(shù)據(jù)的目的。

開啟AOF持久化方式

Redis默認(rèn)不開啟AOF持久化方式，我們可以在配置文件中開啟并進行更加詳細(xì)的配置，如下面的redis.conf文件：

# 開啟aof機制
appendonly yes
# aof文件名
appendfilename "appendonly.aof"# 寫入策略,always表示每個寫操作都保存到aof文件中,也可以是everysec或no
appendfsync always
# 默認(rèn)不重寫aof文件
no-appendfsync-on-rewrite no
# 保存目錄
dir ~/redis/

三種寫入策略

在上面的配置文件中，我們可以通過appendfsync選項指定寫入策略，有三個選項。

#appendfsync always
# appendfsync everysec
# appendfsync no

1. always

客戶端的每一個寫操作都保存到aof文件當(dāng)，這種策略很安全，但是每個寫請注都有IO操作，所以也很慢。

2. everysec

appendfsync的默認(rèn)寫入策略，每秒寫入一次aof文件，因此，最多可能會丟失1s的數(shù)據(jù)。

3. no

Redis服務(wù)器不負(fù)責(zé)寫入aof，而是交由操作系統(tǒng)來處理什么時候?qū)懭隺of文件。更快，但也是最不安全的選擇，不推薦使用。

AOF文件重寫

AOF將客戶端的每一個寫操作都追加到aof文件末尾，比如對一個key多次執(zhí)行incr命令，這時候，aof保存每一次命令到aof文件中，aof文件會變得非常大。

incr num 1incr num 2incr num 3incr num 4incr num 5incr num 6...
incr num 100000

aof文件太大，加載aof文件恢復(fù)數(shù)據(jù)時，就會非常慢，為了解決這個問題，Redis支持aof文件重寫，通過重寫aof，可以生成一個恢復(fù)當(dāng)前數(shù)據(jù)的最少命令集，比如上面的例子中那么多條命令，可以重寫為：

set num 100000

aof文件是一個二進制文件，并不是像上面的例子一樣，直接保存每個命令，而使用Redis自己的格式，上面只是方便演示。

兩種重寫方式

通過在redis.conf配置文件中的選項no-appendfsync-on-rewrite可以設(shè)置是否開啟重寫，這種方式會在每次fsync時都重寫，影響服務(wù)器性以，因此默認(rèn)值為no，不推薦使用。

# 默認(rèn)不重寫aof文件
no-appendfsync-on-rewrite no

客戶端向服務(wù)器發(fā)送bgrewriteaof命令，也可以讓服務(wù)器進行AOF重寫。

# 讓服務(wù)器異步重寫追加aof文件命令> bgrewriteaof

重寫aof文件的好處

1. 壓縮aof文件，減少磁盤占用量。

2. 將aof的命令壓縮為最小命令集，加快了數(shù)據(jù)恢復(fù)的速度。

AOF文件損壞

在寫入aof日志文件時，如果Redis服務(wù)器宕機，則aof日志文件文件會出格式錯誤，在重啟Redis服務(wù)器時，Redis服務(wù)器會拒絕載入這個aof文件，可以通過以下步驟修復(fù)aof并恢復(fù)數(shù)據(jù)。

1. 備份現(xiàn)在aof文件，以防萬一。

2. 使用redis-check-aof命令修復(fù)aof文件，該命令格式如下：

# 修復(fù)aof日志文件
$ redis-check-aof -fix file.aof

1. 重啟Redis服務(wù)器，加載已經(jīng)修復(fù)的aof文件，恢復(fù)數(shù)據(jù)。

AOF的優(yōu)點

AOF只是追加日志文件，因此對服務(wù)器性能影響較小，速度比RDB要快，消耗的內(nèi)存較少。

AOF的缺點

1. AOF方式生成的日志文件太大，即使通過AFO重寫，文件體積仍然很大。

2. 恢復(fù)數(shù)據(jù)的速度比RDB慢。

選擇RDB還是AOF呢？

通過上面的介紹，我們了解了RDB與AOF各自的優(yōu)點與缺點，到底要如何選擇呢？

通過下面的表示，我們可以從幾個方面對比一下RDB與AOF,在應(yīng)用時，要根本自己的實際需求，選擇RDB或者AOF，其實，如果想要數(shù)據(jù)足夠安全，可以兩種方式都開啟，但兩種持久化方式同時進行IO操作，會嚴(yán)重影響服務(wù)器性能，因此有時候不得不做出選擇。

當(dāng)RDB與AOF兩種方式都開啟時，Redis會優(yōu)先使用AOF日志來恢復(fù)數(shù)據(jù)，因為AOF保存的文件比RDB文件更完整。

“Redis的持久化和主從復(fù)制詳細(xì)講解”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！

新聞名稱：Redis的持久化和主從復(fù)制詳細(xì)講解
路徑分享：http://sd-ha.com/article4/jsjeoe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)建站、網(wǎng)站營銷、建站公司、虛擬主機、品牌網(wǎng)站建設(shè)、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)