<dl id="3wz6h"></dl><li id="3wz6h"></li>

      1. <dl id="3wz6h"></dl>

      2. <dl id="3wz6h"><ins id="3wz6h"></ins></dl>

            <dl id="3wz6h"></dl>

            <dl id="3wz6h"><ins id="3wz6h"></ins></dl>
            1. 
              
              <output id="3wz6h"><ins id="3wz6h"><nobr id="3wz6h"></nobr></ins></output>

              <li id="3wz6h"><ins id="3wz6h"></ins></li>
              
              

            2. <output id="3wz6h"><ins id="3wz6h"><nobr id="3wz6h"></nobr></ins></output>
              首頁»數據庫»一起看懂Redis兩種持久化方式的原理

              一起看懂Redis兩種持久化方式的原理

              來源:大愚Talk 發布時間:2018-08-14 閱讀次數:

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

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

                本文將通過下面內容的介紹,希望能夠讓大家更全面、清晰的認識這兩種持久化方式,同時理解這種保存數據的思路,應用于自己的系統設計中。

              • 持久化的配置
              • RDB與AOF持久化的工作原理
              • 如何從持久化中恢復數據
              • 關于性能與實踐建議

               持久化的配置

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

                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
              
              # 導入時是否檢查
              rdbchecksum yes

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

              • save 900 1 表示900s內如果有1條是寫入命令,就觸發產生一次快照,可以理解為就進行一次備份
              • save 300 10 表示300s內有10條寫入,就產生快照

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

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

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

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

                AOF的配置

              # 是否開啟aof
              appendonly yes
              
              # 文件名稱
              appendfilename "appendonly.aof"
              
              # 同步方式
              appendfsync everysec
              
              # aof重寫期間是否同步
              no-appendfsync-on-rewrite no
              
              # 重寫觸發配置
              auto-aof-rewrite-percentage 100
              auto-aof-rewrite-min-size 64mb
              
              # 加載aof時如果有錯如何處理
              aof-load-truncated yes
              
              # 文件重寫策略
              aof-rewrite-incremental-fsync yes

                還是重點解釋一些關鍵的配置:

                appendfsync everysec 它其實有三種模式:

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

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

                aof-load-truncated yes 如果該配置啟用,在加載時發現aof尾部不正確是,會向客戶端寫入一個log,但是會繼續執行,如果設置為 no ,發現錯誤就會停止,必須修復后才能重新加載。

               工作原理

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

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

                定時任務使用的是Redis自己實現的 TimeEvent,它會定時去調用一些命令完成定時任務,這些任務可能會阻塞主進程導致Redis性能下降。因此我們在配置Redis時,一定要整體考慮一些會觸發定時任務的配置,根據實際情況進行調整。

                RDB的原理

                在Redis中RDB持久化的觸發分為兩種:自己手動觸發與Redis定時觸發。

                針對RDB方式的持久化,手動觸發可以使用:

              • save:會阻塞當前Redis服務器,直到持久化完成,線上應該禁止使用。
              • bgsave:該觸發方式會fork一個子進程,由子進程負責持久化過程,因此阻塞只會發生在fork子進程的時候。

                而自動觸發的場景主要是有以下幾點:

              • 根據我們的 save m n 配置規則自動觸發;
              • 從節點全量復制時,主節點發送rdb文件給從節點完成復制操作,主節點會觸發 bgsave;
              • 執行 debug reload 時;
              • 執行 shutdown時,如果沒有開啟aof,也會觸發。

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

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

                AOF的原理

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

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

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

                手動觸發: bgrewriteaof,自動觸發 就是根據配置規則來觸發,當然自動觸發的整體時間還跟Redis的定時任務頻率有關系。

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

                對于上圖有四個關鍵點補充一下:

              1. 在重寫期間,由于主進程依然在響應命令,為了保證最終備份的完整性;因此它依然會寫入舊的AOF file中,如果重寫失敗,能夠保證數據不丟失。
              2. 為了把重寫期間響應的寫入信息也寫入到新的文件中,因此也會為子進程保留一個buf,防止新寫的file丟失數據。
              3. 重寫是直接把當前內存的數據生成對應命令,并不需要讀取老的AOF文件進行分析、命令合并。
              4. AOF文件直接采用的文本協議,主要是兼容性好、追加方便、可讀性高可認為修改修復。
              不能是RDB還是AOF都是先寫入一個臨時文件,然后通過 rename 完成文件的替換工作。

               從持久化中恢復數據

                數據的備份、持久化做完了,我們如何從這些持久化文件中恢復數據呢?如果一臺服務器上有既有RDB文件,又有AOF文件,該加載誰呢?

                其實想要從這些文件中恢復數據,只需要重新啟動Redis即可。我們還是通過圖來了解這個流程:

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

               性能與實踐

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

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

                在線上我們到底該怎么做?我提供一些自己的實踐經驗。

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

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

              QQ群:WEB開發者官方群(515171538),驗證消息:10000
              微信群:加小編微信 849023636 邀請您加入,驗證消息:10000
              提示:更多精彩內容關注微信公眾號:全棧開發者中心(fsder-com)
              網友評論(共0條評論) 正在載入評論......
              理智評論文明上網,拒絕惡意謾罵 發表評論 / 共0條評論
              登錄會員中心
              云南十一选往期