溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“Redis如何配置快照持久化”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
整體上來說，redis持久化有兩種方式，快照持久化和AOF，在項目中我們可以根據實際情況選擇合適的持久化方式，也可以不用持久化，這關鍵看我們的redis在項目中扮演了什么樣的角色。那么我將分別用兩篇文章來介紹這兩種不同的持久化方式，本文我們先來看看第一種方式。
快照持久化，顧名思義，就是通過拍攝快照的方式實現數據的持久化，redis可以在某個時間點上對內存中的數據創建一個副本文件，副本文件中的數據在redis重啟時會被自動加載，我們也可以將副本文件拷貝到其他地方一樣可以使用。
redis中的快照持久化默認是開啟的，redis.conf中相關配置主要有如下幾項：
save 900 1 save 300 10 save 60 10000 stop-writes-on-bgsave-error yes rdbcompression yes dbfilename dump.rdb dir ./
前面三個save相關的選項表示備份的頻率，分別表示900秒內至少一個鍵被更改則進行快照，300秒內至少10個鍵被更改則進行快照，60秒內至少10000個鍵被更改則進行快照，stop-writes-on-bgsave-error表示在快照創建出錯后，是否繼續執行寫命令，rdbcompression則表示是否對快照文件進行壓縮，dbfilename表示生成的快照文件的名字，dir則表示生成的快照文件的位置，在redis中，快照持久化默認就是開啟的。我們可以通過如下步驟驗證快照持久化的效果：
1.進入redis安裝目錄，如果有dump.rdb文件，先將之刪除。如下：
![p299]()
2.啟動redis，隨便向redis中存儲幾個數據，然后關閉redis并退出，如下：
[root@localhost redis-4.0.8]# redis-server redis.conf [root@localhost redis-4.0.8]# redis-cli 127.0.0.1:6379> set k1 v1 OK 127.0.0.1:6379> set k2 v2 OK 127.0.0.1:6379> SHUTDOWN not connected> exit
3.退出來后，我們發現剛剛刪掉的dump.rdb文件又回來了，這就是生成的備份文件。
4.此時再次啟動redis并進入，發現剛剛存儲的數據都還在，這是因為redis在啟動時加載了dump.rdb中的數據。好了，關閉redis并退出。
5.將redis目錄下的dump.rdb文件刪除。
6.再次啟動redis并進入到控制臺，所有的數據都不存在了。
通過上面的介紹，小伙伴們對快照持久化都有一個大致的認識了，那么這個東西到底是怎么運行的？持久化的時機是什么？我們來仔細扒一扒。
1.在redis運行過程中，我們可以向redis發送一條save命令來創建一個快照，save是一個阻塞命令，redis在接收到save命令之后，開始執行備份操作之后，在備份操作執行完畢之前，將不再處理其他請求，其他請求將被掛起，因此這個命令我們用的不多。save命令執行如下：
127.0.0.1:6379> SAVE OK
2.在redis運行過程中，我們也可以發送一條bgsave命令來創建一個快照，不同于save命令，bgsave命令會fork一個子進程，然后這個子進程負責執行將快照寫入硬盤，而父進程則繼續處理客戶端發來的請求，這樣就不會導致客戶端命令阻塞了。如下：
127.0.0.1:6379> BGSAVE Background saving started
3.如果我們在redis.conf中配置了如下選項：
save 900 1 save 300 10 save 60 10000
那么當條件滿足時，比如900秒內有一個key被操作了，那么redis就會自動觸發bgsava命令進行備份。我們可以根據實際需求在redis.conf中配置多個這種觸發規則。
4.還有一種情況也會觸發save命令，那就是我們執行shutdown命令時，當我們用shutdown命令關閉redis時，此時也會執行一個save命令進行備份操作，并在備份操作完成后將服務器關閉。
5.還有一種特殊情況也會觸發bgsave命令，就是在主從備份的時候。當從機連接上主機后，會發送一條sync命令來開始一次復制操作，此時主機會開始一次bgsave操作，并在bgsave操作結束后向從機發送快照數據實現數據同步。
快照持久化有一些缺點，比如save命令會發生阻塞，bgsave雖然不會發生阻塞，但是fork一個子進程又要耗費資源，在一些極端情況下，fork子進程的時間甚至超過數據備份的時間。定期的持久化也會讓我們存在數據丟失的風險，最壞的情況我們可能丟失掉最近一次備份到當下的數據，具體丟失多久的數據，要看我們項目的承受能力，我們可以根據項目的承受能力配飾save參數。
“Redis如何配置快照持久化”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
