持久化套路

OK，一般我們在生產上采用的持久化策略為

• (1)master關閉持久化

• (2)slave開RDB即可，必要的時候AOF和RDB都開啟

該策略能夠適應絕大部分場景，絕大部分集群架構。
為什么是絕大部分場景？
因為這套策略存在部分的數據丟失可能性。redis的主從復制是異步的，master執行完客戶端請求的命令后會立即返回結果給客戶端，然后異步的方式把命令同步給slave。因此master可能還未來得及將命令傳輸給slave，就宕機了，此時slave變為master，數據就丟了。
幸運的是，絕大部分業務場景，都能容忍數據的部分丟失。假設，真的遇到緩存雪崩的情況，代碼中也有熔斷器來進行資源保護，不至于所有的請求都轉發到數據庫上，導致我們的服務崩潰！
ps:這里的緩存雪崩是指同一時間來了一堆請求，請求的key在redis中不存在，導致請求全部轉發到數據庫上。
為什么是絕大部分集群架構？
因為在集群中存在redis讀寫分離的情況，就不適合這套方案了。
幸運的是，由于采用redis讀寫分離架構，就必須要考慮主從同步的延遲性問題，徒增系統復雜度。目前業內采用redis讀寫分離架構的項目，真的太少了。

為什么這么做

(1)master關閉持久化

原因很簡單，因為無論哪種持久化方式都會影響redis的性能，哪一種持久化都會造成CPU卡頓，影響對客戶端請求的處理。為了保證讀寫最佳性能，將master的持久化關閉！
RDB持久化
RDB持久化是將當前進程中的數據生成快照保存到硬盤(因此也稱作快照持久化)，保存的文件后綴是rdb；當Redis重新啟動時，可以讀取快照文件恢復數據。
那么RDB持久化的過程，相當于在執行bgsave命令。該命令執行過程如下圖所示

綜上所述，我們為了保證讀寫性能最大化，將master的持久化關閉。

(2)slave開RDB即可，必要的時候AOF和RDB都開啟

首先，我先說明一下，我不推薦單開AOF的原因是，基于AOF的數據恢復太慢。
你要想，我們已經做了主從復制，數據已經實現備份，為什么slave還需要開持久化?
因為某一天可能因為某某工程，把機房的電線挖斷了，就會導致master和slave機器同時宕機。
那么這個時候，我們需要迅速恢復集群，而RDB文件文件小、恢復快，因此災難恢復常用RDB文件。

其次，官網也不推薦單開AOF，地址如下:
https://redis.io/topics/persistence
截圖如下

所以，如果實在對數據安全有一定要求，將AOF和RDB持久化都開啟。

另外，做好災難備份。利用linux的scp命令，定期將rdb文件拷貝到云服務器上。
ps:scp是secure copy的簡寫，用于在Linux下進行遠程拷貝文件的命令，和它類似的命令有cp，不過cp只是在本機進行拷貝不能跨服務器，而且scp傳輸是加密的。