默認情況下，redis 工作時所有數(shù)據(jù)都是存儲于內(nèi)存中的，不論是否有磁盤上的持久化數(shù)據(jù)，都是工作于內(nèi)存當中，redis 本身就是一個內(nèi)存的數(shù)據(jù)庫，如果 redis 崩潰或斷電導致所有數(shù)據(jù)丟失，所以 redis 提供了持久化功能來保證數(shù)據(jù)的可靠性， redis 持久化有兩種實現(xiàn)：RDB 和 AOF
1、RDB 持久化
RDB 持久化是指在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤，實際操作過程是 fork 一個子進程，先將數(shù)據(jù)集寫入臨時文件，寫入成功后，再替換之前的文件，用二進制壓縮存儲。
RDB 持久化是默認啟動的持久化機制；按事先定制的策略，周期性地將數(shù)據(jù)保存至磁盤，數(shù)據(jù)文件默認為 dump.rdb。
RDB 持久化有兩種方式：
- 借助于配置文件所定義的 save 和策略進行保存。
- 客戶端使用 SAVE 或 BGSAVE 命令啟動快照保存機制。
SAVE 命令: 同步保存，在客戶端使用 save 保存快照時，是在 redis 主線程中保存快照；因為 redis 的主線程是用于處理請求的，所以此時會阻塞所有客戶端請求，每次的保存快照都是把內(nèi)存中的數(shù)據(jù)完整的保存一份，并非是增量的，如果內(nèi)存中的數(shù)據(jù)比較大，而還有大量的寫操作請求時，此方式會引起大量的 I/O，會導致 redis性能下降。
BGSAVE 命令：異步方式，將立即返回結果，但自動在后臺保持操作，所以 BGSAVE命令啟動以后，前臺不會被占用，客戶端的請求是不會被阻塞（主進程不會被阻塞）。如果是在配置文件中定義的 save，那么 redis 在持久化的時候，則會開啟另外的進程去處理，不會阻塞 redis 的主進程redis 的 RDB 持久化不足之處則是，一旦數(shù)據(jù)出現(xiàn)問題，由于 RDB 的數(shù)據(jù)不是最新的，所以基于 RDB 恢復過來的數(shù)據(jù)一定會有一部分數(shù)據(jù)丟失，也就是 RDB 保存之后的修改的數(shù)據(jù)會丟失。
a. RDB 優(yōu)點
① 采用 RDB 方式，那么你的整個 Redis 數(shù)據(jù)庫將只包含一個文件，這對于文件備份而言是非常方便的，因為我們可以非常輕松的將一個單獨的文件壓縮后再轉移到其它存儲介質上。
② 性能最大化。對于 Redis 的服務進程而言，在開始持久化時，它唯一需要做的只是 fork 出子進程，之后再由子進程完成這些持久化的工作，這樣就可以極大的避免服務進程執(zhí)行 IO 操作了。
③ 相比于 AOF 機制，如果數(shù)據(jù)集很大，RDB 的啟動效率會更高。
b. RDB 缺點
① 如果你想保證數(shù)據(jù)的高可用性，即最大限度的避免數(shù)據(jù)丟失，那么 RDB 將不是一個很好的選擇。因為系統(tǒng)一旦在定時持久化之前出現(xiàn)宕機現(xiàn)象，此前沒有來得及寫入磁盤的數(shù)據(jù)都將丟失。
② 由于 RDB 是通過 fork 子進程來協(xié)助完成數(shù)據(jù)持久化工作的，因此，如果當數(shù)據(jù)集較大時，可能會導致整個服務器停止服務幾百毫秒，甚至是 1 秒鐘。
c. 配置RDB相關參數(shù)
# 創(chuàng)建 RDB 文件路徑
mkdir -p /usr/local/redis/data
vim /usr/local/redis/etc/redis.conf
#-----------------配置文件--------------------------------------------------------
# 在進行快照備份時，一旦發(fā)生錯誤的話是否停止寫操作
stop-writes-on-bgsave-error yes
# RDB 文件是否使用壓縮，壓縮會消耗 CPU
rdbcompression yes
#是否對 RDB 文件做校驗碼檢測，此項定義在 redis 啟動時加載 RDB 文件是否對文件檢查校驗碼，
#在 redis 生成 RDB 文件是會生成校驗信息，在 redis 再次啟動或裝載 RDB 文件時，
#是否檢測校驗信息，如果檢測的情況下會消耗時間，會導致 redis 啟動時慢，
#但是能夠判斷 RDB 文件是否產(chǎn)生錯誤
rdbchecksum yes
# 定義 RDB 文件的名稱
dbfilename dump.rdb
# 定義 RDB 文件存放的目錄路徑
dir /usr/local/redis/data
#-----------------配置文件--------------------------------------------------------
#關閉 redis，這里注意，設置完密碼后關閉 redis 需要攜帶密碼
redis-cli -a 123456 shutdown
redis-server /usr/local/redis/etc/redis.conf
redis-cli -a 123456
127.0.0.1:6379> config get dir
2、AOF 持久化
AOF：Append Only File，持久化以日志的形式記錄服務器所處理的每一個寫、刪除操作，查詢操作不會記錄，以文本的方式記錄，可以打開文件看到詳細的操作記錄。AOF 類似于 MySQL 的二進制日志，記錄每一次 redis 的寫操作命令，以順序 IO 方式附加在指定文件的尾部，是使用追加方式實現(xiàn)的，這也叫做一種附加日志類型的持久化機制，由于每一次的操作都記錄，則會隨著時間增長而增大文件的容量， AOF 不像 RDB，RDB 是保存數(shù)據(jù)集的本身。
a. AOF 優(yōu)點
① AOF 機制可以帶來更高的數(shù)據(jù)安全性，即數(shù)據(jù)持久性。Redis 中提供了 3 中同步策略，即每秒同步、每修改同步和不同步。事實上，對于每秒同步，一旦系統(tǒng)出現(xiàn)宕機現(xiàn)象，那么這一秒鐘之內(nèi)修改的數(shù)據(jù)將會丟失。而每修改同步，即每次發(fā)生的數(shù)據(jù)變化都會被立即記錄到磁盤中。至于無同步，無需多言，我想大家都能正確的理解它。
② 由于 AOF 機制對日志文件的寫入操作采用的是 append 模式，因此在寫入過程中即使出現(xiàn)宕機現(xiàn)象，也不會破壞日志文件中已經(jīng)存在的內(nèi)容。然而如果我們本次操作只是寫入了一半數(shù)據(jù)就出現(xiàn)了系統(tǒng)崩潰問題，不用擔心，在 Redis 下一次啟動之前，我們可以通過 redis-check-aof 工具來幫助我們解決數(shù)據(jù)一致性的問題。
③ 如果日志過大，Redis 可以自動啟用 rewrite 機制。即 Redis 以 append 模式不斷的將修改數(shù)據(jù)寫入到老的磁盤文件中，同時 Redis 還會創(chuàng)建一個新的文件用于記錄此期間有哪些修改命令被執(zhí)行。因此在進行 rewrite 切換時可以更好的保證數(shù)據(jù)安全性。
④ AOF 包含一個格式清晰、易于理解的日志文件用于記錄所有的修改操作。事實上，我們也可以通過該文件完成數(shù)據(jù)的重建。
b. AOF 缺點
① 對于相同數(shù)量的數(shù)據(jù)集而言，AOF 文件通常要大于 RDB 文件。RDB 在恢復大數(shù)據(jù)集時的速度比 AOF 的恢復速度要快。
② 根據(jù)同步策略的不同，AOF 在運行效率上往往會慢于 RDB。
c. 配置AOF相關參數(shù)
vim /usr/local/redis/etc/redis.conf
#--------------------------------配置文件Start-----------------------------------------
# 定義是否開啟 AOF 功能，默認為關閉，啟用修改為 yes
appendonly no
# 定義 AOF 文件
appendfilename "appendonly.aof"
# 表示每次收到寫命令時，立即寫到磁盤上的 AOF 文件，
# 雖然是最好的持久化功能，但是每次有寫命令時都會有磁盤的 I/O 操作，容易影響redis 的性能
appendfsync always
# 表示每秒鐘寫一次，不管每秒鐘收到多少個寫請求都往磁盤中的 AOF 文件中寫一次
appendfsync everysec
# 表示 append 功能不會觸發(fā)寫操作，所有的寫操作都是提交給 OS，由 OS 自行決定是如何寫的
appendfsync no
# 當此項為 yes 時，表示在重寫時，對于新的寫操作不做同步，而暫存在內(nèi)存中
no-appendfsync-on-rewrite no
# 表示當前 AOF文件的大小是上次重寫 AOF文件的二倍時，則自動日志重寫過程
auto-aof-rewrite-percentage 100
# 定義 AOF 文件重寫過程的條件，最少為定義大小則觸發(fā)重寫過程
auto-aof-rewrite-min-size 64mb
#--------------------------------配置文件End-----------------------------------------注意：持久本身不能取代備份；還應該制定備份策略，對 redis 數(shù)據(jù)庫定期進行備份；
d. RDB 與 AOF 同時啟用注意事項
① BGSAVE 和 BGREWRITEAOF 不會同時執(zhí)行，為了避免對磁盤的 I/O 影響過大， 在某一時刻只允許一者執(zhí)行； 如果 BGSAVE 在執(zhí)行當中，而用戶手動執(zhí)行 BGREWRITEAOF 時，redis 會立即返回 OK，但是 redis 不會同時執(zhí)行，會等 BGSAVE 執(zhí)行完成，再執(zhí)行 BGREWRITEAOF。
② 在 Redis 服務器啟動用于恢復數(shù)據(jù)時，會優(yōu)先使用 AOF文章來源：http://www.zghlxwxcb.cn/news/detail-802646.html
③ 數(shù)據(jù)恢復：每次 redis 重啟都會去讀取相對應的文件，如果誤刪除可以用備份文件直接替換 原來的文件，dump.rdb 或者 appendonly.aof。文章來源地址http://www.zghlxwxcb.cn/news/detail-802646.html
到了這里，關于Redis 持久化的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
