Redis為持久化提供了兩種方式：

• RDB：在指定的時間間隔能對你的數(shù)據(jù)進行快照存儲。
• AOF：記錄每次對服務(wù)器寫的操作,當服務(wù)器重啟的時候會重新執(zhí)行這些命令來恢復(fù)原始的數(shù)據(jù)。

　　本文將通過下面內(nèi)容的介紹，希望能夠讓大家更全面、清晰的認識這兩種持久化方式，同時理解這種保存數(shù)據(jù)的思路，應(yīng)用于自己的系統(tǒng)設(shè)計中。

• 持久化的配置
• RDB與AOF持久化的工作原理
• 如何從持久化中恢復(fù)數(shù)據(jù)
• 關(guān)于性能與實踐建議

　持久化的配置

　　為了使用持久化的功能，我們需要先知道該如何開啟持久化的功能。

　　RDB的持久化配置

# 時間策略
save 900 1
save 300 10
save 60 10000

# 文件名稱
dbfilename dump.rdb

# 文件保存路徑
dir /home/work/app/redis/data/

# 如果持久化出錯，主進程是否停止寫入
stop-writes-on-bgsave-error yes

# 是否壓縮
rdbcompression yes

# 導(dǎo)入時是否檢查
rdbchecksum yes

　　配置其實非常簡單，這里說一下持久化的時間策略具體是什么意思。

• save 900 1 表示900s內(nèi)如果有1條是寫入命令，就觸發(fā)產(chǎn)生一次快照，可以理解為就進行一次備份
• save 300 10 表示300s內(nèi)有10條寫入，就產(chǎn)生快照

　　下面的類似，那么為什么需要配置這么多條規(guī)則呢？因為Redis每個時段的讀寫請求肯定不是均衡的，為了平衡性能與數(shù)據(jù)安全，我們可以自由定制什么情況下觸發(fā)備份。所以這里就是根據(jù)自身Redis寫入情況來進行合理配置。

　　stop-writes-on-bgsave-error yes 這個配置也是非常重要的一項配置，這是當備份進程出錯時，主進程就停止接受新的寫入操作，是為了保護持久化的數(shù)據(jù)一致性問題。如果自己的業(yè)務(wù)有完善的監(jiān)控系統(tǒng)，可以禁止此項配置， 否則請開啟。

　　關(guān)于壓縮的配置 rdbcompression yes ，建議沒有必要開啟，畢竟Redis本身就屬于CPU密集型服務(wù)器，再開啟壓縮會帶來更多的CPU消耗，相比硬盤成本，CPU更值錢。

　　當然如果你想要禁用RDB配置，也是非常容易的，只需要在save的最后一行寫上：save ""

　　AOF的配置

# 是否開啟aof
appendonly yes

# 文件名稱
appendfilename "appendonly.aof"

# 同步方式
appendfsync everysec

# aof重寫期間是否同步
no-appendfsync-on-rewrite no

# 重寫觸發(fā)配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加載aof時如果有錯如何處理
aof-load-truncated yes

# 文件重寫策略
aof-rewrite-incremental-fsync yes

　　還是重點解釋一些關(guān)鍵的配置：

　　appendfsync everysec 它其實有三種模式:

• always：把每個寫命令都立即同步到aof，很慢，但是很安全
• everysec：每秒同步一次，是折中方案
• no：redis不處理交給OS來處理，非�？�，但是也最不安全

　　一般情況下都采用 everysec 配置，這樣可以兼顧速度與安全，最多損失1s的數(shù)據(jù)。

　　aof-load-truncated yes 如果該配置啟用，在加載時發(fā)現(xiàn)aof尾部不正確是，會向客戶端寫入一個log，但是會繼續(xù)執(zhí)行，如果設(shè)置為 no ，發(fā)現(xiàn)錯誤就會停止，必須修復(fù)后才能重新加載。

　工作原理

　　關(guān)于原理部分，我們主要來看RDB與AOF是如何完成持久化的，他們的過程是如何。

　　在介紹原理之前先說下Redis內(nèi)部的定時任務(wù)機制，定時任務(wù)執(zhí)行的頻率可以在配置文件中通過 hz 10 來設(shè)置（這個配置表示1s內(nèi)執(zhí)行10次，也就是每100ms觸發(fā)一次定時任務(wù)）。該值最大能夠設(shè)置為：500，但是不建議超過：100，因為值越大說明執(zhí)行頻率越頻繁越高，這會帶來CPU的更多消耗，從而影響主進程讀寫性能。

　　定時任務(wù)使用的是Redis自己實現(xiàn)的 TimeEvent，它會定時去調(diào)用一些命令完成定時任務(wù)，這些任務(wù)可能會阻塞主進程導(dǎo)致Redis性能下降。因此我們在配置Redis時，一定要整體考慮一些會觸發(fā)定時任務(wù)的配置，根據(jù)實際情況進行調(diào)整。

　　RDB的原理

　　在Redis中RDB持久化的觸發(fā)分為兩種：自己手動觸發(fā)與Redis定時觸發(fā)。

　　針對RDB方式的持久化，手動觸發(fā)可以使用：

• save：會阻塞當前Redis服務(wù)器，直到持久化完成，線上應(yīng)該禁止使用。
• bgsave：該觸發(fā)方式會fork一個子進程，由子進程負責(zé)持久化過程，因此阻塞只會發(fā)生在fork子進程的時候。

　　而自動觸發(fā)的場景主要是有以下幾點：

• 根據(jù)我們的 save m n 配置規(guī)則自動觸發(fā)；
• 從節(jié)點全量復(fù)制時，主節(jié)點發(fā)送rdb文件給從節(jié)點完成復(fù)制操作，主節(jié)點會觸發(fā) bgsave；
• 執(zhí)行 debug reload 時；
• 執(zhí)行 shutdown時，如果沒有開啟aof，也會觸發(fā)。

　　由于 save 基本不會被使用到，我們重點看看 bgsave 這個命令是如何完成RDB的持久化的。

　　這里注意的是 fork 操作會阻塞，導(dǎo)致Redis讀寫性能下降。我們可以控制單個Redis實例的最大內(nèi)存，來盡可能降低Redis在fork時的事件消耗。以及上面提到的自動觸發(fā)的頻率減少fork次數(shù)，或者使用手動觸發(fā)，根據(jù)自己的機制來完成持久化。

　　AOF的原理

　　AOF的整個流程大體來看可以分為兩步，一步是命令的實時寫入（如果是 appendfsync everysec 配置，會有1s損耗），第二步是對aof文件的重寫。

　　對于增量追加到文件這一步主要的流程是：命令寫入=》追加到aof_buf =》同步到aof磁盤。那么這里為什么要先寫入buf在同步到磁盤呢？如果實時寫入磁盤會帶來非常高的磁盤IO，影響整體性能。

　　aof重寫是為了減少aof文件的大小，可以手動或者自動觸發(fā)，關(guān)于自動觸發(fā)的規(guī)則請看上面配置部分。fork的操作也是發(fā)生在重寫這一步，也是這里會對主進程產(chǎn)生阻塞。

　　手動觸發(fā)： bgrewriteaof，自動觸發(fā) 就是根據(jù)配置規(guī)則來觸發(fā)，當然自動觸發(fā)的整體時間還跟Redis的定時任務(wù)頻率有關(guān)系。

　　下面來看看重寫的一個流程圖：

　　對于上圖有四個關(guān)鍵點補充一下：

1. 在重寫期間，由于主進程依然在響應(yīng)命令，為了保證最終備份的完整性；因此它依然會寫入舊的AOF file中，如果重寫失敗，能夠保證數(shù)據(jù)不丟失。
2. 為了把重寫期間響應(yīng)的寫入信息也寫入到新的文件中，因此也會為子進程保留一個buf，防止新寫的file丟失數(shù)據(jù)。
3. 重寫是直接把當前內(nèi)存的數(shù)據(jù)生成對應(yīng)命令，并不需要讀取老的AOF文件進行分析、命令合并。
4. AOF文件直接采用的文本協(xié)議，主要是兼容性好、追加方便、可讀性高可認為修改修復(fù)。

不能是RDB還是AOF都是先寫入一個臨時文件，然后通過 rename 完成文件的替換工作。

　從持久化中恢復(fù)數(shù)據(jù)

　　數(shù)據(jù)的備份、持久化做完了，我們?nèi)绾螐倪@些持久化文件中恢復(fù)數(shù)據(jù)呢？如果一臺服務(wù)器上有既有RDB文件，又有AOF文件，該加載誰呢？

　　其實想要從這些文件中恢復(fù)數(shù)據(jù)，只需要重新啟動Redis即可。我們還是通過圖來了解這個流程：

　　啟動時會先檢查AOF文件是否存在，如果不存在就嘗試加載RDB。那么為什么會優(yōu)先加載AOF呢？因為AOF保存的數(shù)據(jù)更完整，通過上面的分析我們知道AOF基本上最多損失1s的數(shù)據(jù)。

　性能與實踐

　　通過上面的分析，我們都知道RDB的快照、AOF的重寫都需要fork，這是一個重量級操作，會對Redis造成阻塞。因此為了不影響Redis主進程響應(yīng)，我們需要盡可能降低阻塞。

1. 降低fork的頻率，比如可以手動來觸發(fā)RDB生成快照、與AOF重寫；
2. 控制Redis最大使用內(nèi)存，防止fork耗時過長；
3. 使用更牛逼的硬件；
4. 合理配置Linux的內(nèi)存分配策略，避免因為物理內(nèi)存不足導(dǎo)致fork失敗。

　　在線上我們到底該怎么做？我提供一些自己的實踐經(jīng)驗。

1. 如果Redis中的數(shù)據(jù)并不是特別敏感或者可以通過其它方式重寫生成數(shù)據(jù)，可以關(guān)閉持久化，如果丟失數(shù)據(jù)可以通過其它途徑補回；
2. 自己制定策略定期檢查Redis的情況，然后可以手動觸發(fā)備份、重寫數(shù)據(jù)；
3. 單機如果部署多個實例，要防止多個機器同時運行持久化、重寫操作，防止出現(xiàn)內(nèi)存、CPU、IO資源競爭，讓持久化變?yōu)榇�行�?/li>
4. 可以加入主從機器，利用一臺從機器進行備份處理，其它機器正常響應(yīng)客戶端的命令；
5. RDB持久化與AOF持久化可以同時存在，配合使用。

　　本文的內(nèi)容主要是運維上的一些注意點，但我們開發(fā)者了解到這些知識，在某些時候有助于我們發(fā)現(xiàn)詭異的bug。接下來會介紹Redis的主從復(fù)制與集群的知識。

標簽： linux 安全 服務(wù)器 開發(fā)者

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。