一、持久化

實現持久化的方式有兩種RDB、AOF

基于RDB方式做持久化

RDB是基于快照模式實現的，所保存的數據文件默認dump.rdb，具體產生這個數據文件的方式有兩種：
方式1：客戶端執行save或者bgsave命令

用save方式你的話，是在主線程中保存快照，也就是說在save執行完成之前所有的操作都會被阻塞，因為這是同步保存的。

在執行save保存數據的時候，不是做增量保存，而是將內存中的全部數據做一次同步，所以這個過程會很慢。

用bgsave的話，這個是基于異步的方式，也就是執行這個命令以后，會立刻告訴你已經執行啟動，但是不會阻塞用戶，而是在后臺悄悄的運行。

方式2：提前做好計劃任務

基于計劃任務自動做同步的話，是在子進程中實現。具體過程是子進程會會打開一個文件，將數據保存到這個新文件中，在完成以后改名為dump.rdb就可以了。

基于AOF方式做持久化

相對而言，AOF模式比RDB更為可靠。這種方式之所以可靠是因為快照的方式是周期性的，比如每隔10秒做一次，但是如果在做了一次持久化之后，還沒有到下一次系統就崩潰了，那么這段時間的數據就丟失了。
AOF有有點類似于mysql的二進制日志，這個文件會記錄下每次所執行的語句（主要是寫操作），每次的操作都會追加到文件的末尾。當Redis重啟的時候，可以通過aof文件中的命令實現在內存中重建數據庫。

但是aof這種方式也是有缺點的：

可能會有很多重復的內容，比如執行100次incre，文件就會記錄100條，這明顯是不合理的（事實上redis進程會掃描aof中重復的事件，并進行合并）

aof文件會變得越來越大，為了解決這個問題，redis提供了一個命令BGREWRITEAOF，通過這個命令可以實現AOF文件的重寫，需要注意的是這種重寫機制是比較特殊的，因為在重寫的時候，是不會去讀取原來的aof文件，而是直接讀取內存中的數據，將內存中的數據生成一個指令集，并將指令集保存在一個臨時文件，在這個臨時文件保存完成之后，就會用這個歷史文件去替換原來的那個aof文件，完成重寫aof文件的過程。so，aof文件可以通過重寫的方式將其變小。

重寫過程：

Redis主進程通過fork創建子進程；

子進程根據Redis內存中的數據創建數據庫重建命令序列于臨時文件中；

父進程繼承 client的請求，并會把這些請求中的寫操作繼續追加到原來的aof文件，額外地，這些新的寫請求還會被防止于一個新的緩沖隊列中；

子進程重寫完成，會通知父進程，父進程把緩沖中的命令寫到臨時文件中

父進程用臨時文件替代aof文件；

相關配置

與RDB相關的配置

# 設置同步周期 save 900 1 save 300 10 save 60 10000 # 進行快照備份的時候，一旦監控到持久化發生了錯誤，是否停止下來 stop-writes-on-bgsave-error yes # rdb文件是否執行壓縮來節省空間 rdbcompression yes # 是否校驗rdb文件 rdbchecksum yes # rdb文件的文件名 dbfilename dump.rdb # rdb文件的位置 dir /var/lib/redis

與AOF相關的配置

# 指定是否啟用aof持久化 appendonly yes # 當aof文件的大小增長了指定比例的時候，執行一次重寫操作 auto-aof-rewrite-percentage 100 # 指定aof文件做重寫最小值 auto-aof-rewrite-min-size 64mb # aof持久化信息保存在哪個文件中（相當于mysql的二進制日志文件） appendfilename "appendonly.aof" # 一旦執行了操作，會立刻將操作的語句記錄到aof文件中 # appendfsync always # 每秒向aof文件進行一次寫入操作 appendfsync everysec # 不主動向aof執行寫入操作，由系統自行判斷何時向磁盤執行寫入操作 # appendfsync no #在做重寫的時候，新的寫操作不做fsync no-appendfsync-on-rewrite no # 當aof文件備被損壞時，redis返回錯誤并推出 aof-load-truncated yes

實際生產環境中肯定是同時使用rdb和aof的，那么就會有一個問題，就是如果在某個時間點同時出發了AOF和RDB持久化，那么會對磁盤熊帶來很大的壓力，所以通常我們的Redis會禁止同時做持久化操作，如果正在做RDB的持久化，那么及時此時觸發了AOF的持久化也是不會執行的。

二、備份

在有持久化的情況下，數據會自動保存在文件中，這里為了演示現將持久化關閉。

# 修改配置文件 [root@BIGBOSS ~]# vim /etc/redis.conf # 禁止快照方式的持久存儲 save ""#save 900 1 #save 300 10 #save 60 10000 # 禁止AOF方式的持久存儲 appendonly no

刪除之前的數據,并重啟服務

[root@BIGBOSS ~]# rm -rf /var/lib/redis/dump.rdb [root@BIGBOSS ~]# systemctl restart redis

在redis中填充一些數據

10.220.5.171:6379> DBSIZE (integer) 0 10.220.5.171:6379> set name cx OK 10.220.5.171:6379> set age 20 OK 10.220.5.171:6379> set addr tianjin OK 10.220.5.171:6379> DBSIZE (integer) 3

退出redis，再重新進入發現這些key依然存在（這些值是存在內存中的）

10.220.5.171:6379> exit [root@BIGBOSS ~]# redis-cli -h 10.220.5.171 10.220.5.171:6379> DBSIZE (integer) 3

但是如果重啟Redis這些數據就沒有了

10.220.5.171:6379> exit [root@BIGBOSS ~]# systemctl restart redis [root@BIGBOSS ~]# redis-cli -h 10.220.5.171 10.220.5.171:6379> DBSIZE (integer) 0

重新插入數據,并手動執行保存

10.220.5.171:6379> DBSIZE (integer) 0 10.220.5.171:6379> set name cx OK 10.220.5.171:6379> set age 20 OK 10.220.5.171:6379> set addr tianjin OK 10.220.5.171:6379> save OK

可以看到生成了新的數據文件

[root@BIGBOSS ~]# ls /var/lib/redis/ dump.rdb

而我們做備份工作的時候，其實就是備份的這個文件，現在我將這個文件備份到tmp下

[root@BIGBOSS ~]# cp /var/lib/redis/dump.rdb /tmp/

模擬故障，將/var/lib/redis/dump.rdb刪除并重啟redis,可以看到數據已經沒有了，不過不要慌我們做了備份

[root@BIGBOSS ~]# rm -rf /var/lib/redis/dump.rdb [root@BIGBOSS ~]# systemctl restart redis [root@BIGBOSS ~]# redis-cli -h 10.220.5.171 10.220.5.171:6379> DBSIZE (integer) 0

將備份數據挪回來，重啟Redis查看數據

[root@BIGBOSS ~]# cp /tmp/dump.rdb /var/lib/redis/ [root@BIGBOSS ~]# ls /var/lib/redis/ dump.rdb [root@BIGBOSS ~]# systemctl restart redis [root@BIGBOSS ~]# redis-cli -h 10.220.5.171 10.220.5.171:6379> DBSIZE (integer) 3

通過上面的操作很明顯的我們看到了備份數據和恢復數據的過程，在企業中數據備份也是很重要的一份工作。

------做運維之前很矯情的小年輕-----

總結

以上是生活随笔為你收集整理的Redis持久化和备份数据的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。