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

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

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

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

　持久化的配置

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

　　RDB的持久化配置

# 時(shí)間策略
save 900 1
save 300 10
save 60 10000

# 文件名稱
dbfilename dump.rdb

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

# 如果持久化出錯(cuò)，主進(jìn)程是否停止寫入
stop-writes-on-bgsave-error yes

# 是否壓縮
rdbcompression yes

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

　　配置其實(shí)非常簡(jiǎn)單，這里說(shuō)一下持久化的時(shí)間策略具體是什么意思。

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

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

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

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

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

　　AOF的配置

# 是否開(kāi)啟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時(shí)如果有錯(cuò)如何處理
aof-load-truncated yes

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

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

　　appendfsync everysec 它其實(shí)有三種模式:

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

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

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

　工作原理

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

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

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

　　RDB的原理

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

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

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

　　而自動(dòng)觸發(fā)的場(chǎng)景主要是有以下幾點(diǎn)：

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

　　由于 save 基本不會(huì)被使用到，我們重點(diǎn)看看 bgsave 這個(gè)命令是如何完成RDB的持久化的。

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

　　AOF的原理

　　AOF的整個(gè)流程大體來(lái)看可以分為兩步，一步是命令的實(shí)時(shí)寫入（如果是 appendfsync everysec 配置，會(huì)有1s損耗），第二步是對(duì)aof文件的重寫。

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

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

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

　　下面來(lái)看看重寫的一個(gè)流程圖：

　　對(duì)于上圖有四個(gè)關(guān)鍵點(diǎn)補(bǔ)充一下：

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

不能是RDB還是AOF都是先寫入一個(gè)臨時(shí)文件，然后通過(guò) rename 完成文件的替換工作。

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

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

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

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

　性能與實(shí)踐

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

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

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

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

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

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

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