Redis持久化實(shí)現(xiàn)的方法是什么

持久化套路

OK，一般我們?cè)谏a(chǎn)上采用的持久化策略為

• (1)master關(guān)閉持久化

• (2)slave開(kāi)RDB即可，必要的時(shí)候AOF和RDB都開(kāi)啟

該策略能夠適應(yīng)絕大部分場(chǎng)景，絕大部分集群架構(gòu)。
為什么是絕大部分場(chǎng)景？
因?yàn)檫@套策略存在部分的數(shù)據(jù)丟失可能性。redis的主從復(fù)制是異步的，master執(zhí)行完客戶端請(qǐng)求的命令后會(huì)立即返回結(jié)果給客戶端，然后異步的方式把命令同步給slave。因此master可能還未來(lái)得及將命令傳輸給slave，就宕機(jī)了，此時(shí)slave變?yōu)閙aster，數(shù)據(jù)就丟了。
幸運(yùn)的是，絕大部分業(yè)務(wù)場(chǎng)景，都能容忍數(shù)據(jù)的部分丟失。假設(shè)，真的遇到緩存雪崩的情況，代碼中也有熔斷器來(lái)進(jìn)行資源保護(hù)，不至于所有的請(qǐng)求都轉(zhuǎn)發(fā)到數(shù)據(jù)庫(kù)上，導(dǎo)致我們的服務(wù)崩潰！
ps:這里的緩存雪崩是指同一時(shí)間來(lái)了一堆請(qǐng)求，請(qǐng)求的key在redis中不存在，導(dǎo)致請(qǐng)求全部轉(zhuǎn)發(fā)到數(shù)據(jù)庫(kù)上。
為什么是絕大部分集群架構(gòu)？
因?yàn)樵诩褐写嬖趓edis讀寫(xiě)分離的情況，就不適合這套方案了。
幸運(yùn)的是，由于采用redis讀寫(xiě)分離架構(gòu)，就必須要考慮主從同步的延遲性問(wèn)題，徒增系統(tǒng)復(fù)雜度。目前業(yè)內(nèi)采用redis讀寫(xiě)分離架構(gòu)的項(xiàng)目，真的太少了。

為什么這么做

(1)master關(guān)閉持久化

原因很簡(jiǎn)單，因?yàn)闊o(wú)論哪種持久化方式都會(huì)影響redis的性能，哪一種持久化都會(huì)造成CPU卡頓，影響對(duì)客戶端請(qǐng)求的處理。為了保證讀寫(xiě)最佳性能，將master的持久化關(guān)閉！
RDB持久化
RDB持久化是將當(dāng)前進(jìn)程中的數(shù)據(jù)生成快照保存到硬盤(pán)(因此也稱(chēng)作快照持久化)，保存的文件后綴是rdb；當(dāng)Redis重新啟動(dòng)時(shí)，可以讀取快照文件恢復(fù)數(shù)據(jù)。
那么RDB持久化的過(guò)程，相當(dāng)于在執(zhí)行bgsave命令。該命令執(zhí)行過(guò)程如下圖所示

綜上所述，我們?yōu)榱吮ＷC讀寫(xiě)性能最大化，將master的持久化關(guān)閉。

(2)slave開(kāi)RDB即可，必要的時(shí)候AOF和RDB都開(kāi)啟

首先，我先說(shuō)明一下，我不推薦單開(kāi)AOF的原因是，基于AOF的數(shù)據(jù)恢復(fù)太慢。
你要想，我們已經(jīng)做了主從復(fù)制，數(shù)據(jù)已經(jīng)實(shí)現(xiàn)備份，為什么slave還需要開(kāi)持久化?
因?yàn)槟骋惶炜赡芤驗(yàn)槟衬彻こ?，把機(jī)房的電線挖斷了，就會(huì)導(dǎo)致master和slave機(jī)器同時(shí)宕機(jī)。
那么這個(gè)時(shí)候，我們需要迅速恢復(fù)集群，而RDB文件文件小、恢復(fù)快，因此災(zāi)難恢復(fù)常用RDB文件。

其次，官網(wǎng)也不推薦單開(kāi)AOF，地址如下:
https://redis.io/topics/persistence
截圖如下

所以，如果實(shí)在對(duì)數(shù)據(jù)安全有一定要求，將AOF和RDB持久化都開(kāi)啟。

另外，做好災(zāi)難備份。利用linux的scp命令，定期將rdb文件拷貝到云服務(wù)器上。
ps:scp是secure copy的簡(jiǎn)寫(xiě)，用于在Linux下進(jìn)行遠(yuǎn)程拷貝文件的命令，和它類(lèi)似的命令有cp，不過(guò)cp只是在本機(jī)進(jìn)行拷貝不能跨服務(wù)器，而且scp傳輸是加密的。