(本文改編自生活真實案例,若有類同,毫不是巧合!)
端午節,煙哥正在一邊愉快的學習....
忽然,微信一陣抖動。原來是老劉呼喚煙哥!善良的煙哥本覺得人家是要約我出去玩!然而,打開微信一看,出現下圖聊天記錄
因而本文的主題就這麼展開了。因爲我須要迅速讓老劉明白,這種問題的回答套路,因此我回答的時候,教她的是一種通用作法。
ps
:附《那些年用過的redis集羣架構(含面試解析)》的鏈接地址。
固然,必須的,我必定要先問一下老劉答了哪一種redis集羣架構!老劉的回答是用了redis cluster集羣架構。
因而,我一聽內心就有底,開始balabala....html
OK,通常咱們在生產上採用的持久化策略爲linux
該策略可以適應絕大部分場景,絕大部分集羣架構。
爲何是絕大部分場景?
由於這套策略存在部分的數據丟失可能性。redis的主從複製是異步的,master執行完客戶端請求的命令後會當即返回結果給客戶端,而後異步的方式把命令同步給slave。所以master可能還將來得及將命令傳輸給slave,就宕機了,此時slave變爲master,數據就丟了。
幸運的是,絕大部分業務場景,都能容忍數據的部分丟失。假設,真的遇到緩存雪崩的狀況,代碼中也有熔斷器來進行資源保護,不至於全部的請求都轉發到數據庫上,致使咱們的服務崩潰!
ps
:這裏的緩存雪崩是指同一時間來了一堆請求,請求的key在redis中不存在,致使請求所有轉發到數據庫上。
爲何是絕大部分集羣架構?
由於在集羣中存在redis讀寫分離的狀況,就不適合這套方案了。
幸運的是,因爲採用redis讀寫分離架構,就必需要考慮主從同步的延遲性問題,徒增系統複雜度。目前業內採用redis讀寫分離架構的項目,真的太少了。面試
緣由很簡單,由於不管哪一種持久化方式都會影響redis的性能,哪種持久化都會形成CPU卡頓,影響對客戶端請求的處理。爲了保證讀寫最佳性能,將master的持久化關閉!
RDB持久化
RDB持久化是將當前進程中的數據生成快照保存到硬盤(所以也稱做快照持久化),保存的文件後綴是rdb;當Redis從新啓動時,能夠讀取快照文件恢復數據。
那麼RDB持久化的過程,至關於在執行bgsave命令。該命令執行過程以下圖所示
如圖所示,主線程須要調用系統函數fork(),構建出一個子進程進行持久化!很不幸的是,在構建子進程的過程當中,父進程就會阻塞,沒法響應客戶端的請求!
並且,在測試中發現,fork函數在虛擬機上較慢,真機上較快。考慮到如今都是部署在docker容器中,不多部署在真機上,爲了性能,master不建議打開RDB持久化!
AOF持久化
RDB持久化是將進程數據寫入文件,而AOF持久化(即Append Only File持久化),則是將Redis執行的每次寫命令記錄到單獨的日誌文件中。
隨着時間的流逝,你會發現這個AOF文件愈來愈大,因而redis有一套rewrite機制,來縮小AOF文件的體積。然而,在rewrite的過程當中也是須要父進程來fork出一個子進程進行rewrite操做。至於fork函數的影響,上面提到過了。
還有一個就是刷盤策略fsync,這個值推薦是配everysec,也就是Redis會默認每隔一秒進行一次fsync調用,將緩衝區中的數據寫到磁盤。
然而,若是磁盤性能不穩定,fsync的調用時間超過1秒鐘。此時主線程進行AOF的時候會對比上次fsync成功的時間;若是距上次不到2s,主線程直接返回;若是超過2s,則主線程阻塞直到fsync同步完成。
所以AOF也是會影響redis的性能的。
ps
:linux函數中,wrtie函數將數據寫入文件的時候,是將數據寫入操做系統的緩衝區,還並未刷入磁盤。而fsync函數,能夠強制讓操做系統將緩衝區數據刷入磁盤。redis
綜上所述,咱們爲了保證讀寫性能最大化,將master的持久化關閉。docker
首先,我先說明一下,我不推薦單開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傳輸是加密的。服務器
本文提出的是一種通用的持久化策略,主要目的是在面試的時候被問到,給出一個合理的回答,而不至於一臉懵逼。微信