Redis – 2 – 聊聊Redis的RDB和AOF持久化 – 更新完畢
1、RDB
1.1）、RDB是什麼？
- RDB，全稱Redis Database
- RDB是Redis進行持久化的一種方式，當然：Redis默認的持久化方式也是RDB
1.2）、Redis配置RDB
1.2.1）、編寫配置
-
註：保證自己的linux中安裝了docker和docker-compose，安裝教程鏈接如下：
-
另：老衲的方法是採用docker和docker-compose來進行安裝的Redis。官網讓下載壓縮包，然後安裝gcc，使用make編譯，從而安裝的方式，老衲並沒有採用
-
配製編寫如下：
version: '3.1'
services:
redis:
image: redis:6.2.6
restart: always
container_name: redis
environment:
- TZ=Asia/Shanghai
ports:
- 6379:6379
volumes:
- ./conf/:/usr/local/redis/
- ./conf/:/data/
command: ["redis-server","/usr/local/redis/redis.conf"]
- 然後保存即可
1.2.2）、編寫RDB配置
-
註：老衲的Redis是已經啟動過了的，因此：接下來的一步如果看老衲部落格的人當初不是採用的docker和docker-compose安裝的Redis，那麼經過上面的步驟之後，啟動一下Redis就可以了，怎麼啟動這裡不做說明，可以看一下老衲的docker-compose安裝Redis教程，鏈接如下：
-
回到正題，編寫RDB配置
- 最後，保存即可
# 設置redis登錄密碼
requirepass 自己要設置的Redis登錄密碼
# RDB設置
save 900 1
save 300 100
save 60 5 # 這裡使用5，是為了本部落格中好測試，這些後面不說了，因為：這是基操，說起來煩得很
dbfilename dump.rdb
1.2.3）、重新啟動Redis，進到Redis的docker容器內部
- 測試：觸發RDB，save自己設定的次數次數據即可
1.2.4）、回到映射的生成rdb文件的目錄
- 經過如上的操作之後，RDB就配置成功了，但是：老衲想說的其實不是上面這些，接下來才是我想說的
2、Redis的RDB原理
3、RDB的觸發條件
-
1、肯定是使用save命令了（ 先刪掉生成的rdb文件，從而進行測試 ）
-
-
-
可見：成功觸發了，後續的演示老衲不再做了，直說有哪些觸發條件
-
這個命令觸發RDB的原理：
- save命令會阻塞Redis伺服器進程，直到RDB文件創建完畢為止，在Redis伺服器阻塞期間，伺服器不能處理任何命令請求
-
2、使用bgsave命令
-
這個命令也是推薦的一種，創建一個子進程，由子進程來負責創建RDB文件，父進程(即Redis主進程)則繼續處理請求
-
註：bgsave命令執行過程中，只有fork子進程時會阻塞伺服器，而對於save命令，整個過程都會阻塞伺服器，因此save已基本被廢棄，線上環境要杜絕save的使用
-
-
3、自動觸發
- 這個就簡單了，所謂的自動觸發就是前面自己在redis.conf文件中配置哪些save，滿足條件就觸發了嘛
-
4、使用flushall命令、以及退出Redis也會觸發（ 先登進去，然後開另一個創建刪掉rdb文件，再退出就發現也生成了 ）
4、RDB的優缺點
- 缺點：
-
進行持久化時有一定的時間間隔（ sava配置那裡 ），如果剛好在哪個時間點內在保存數據，而此時出現宕機了，則：會導致要保存的數據沒有保存成功（ 不能保證數據的絕對安全 ）
- 舉個例子：假如900內是有一次key發生改變就保存數據，但是：在key正在準備改變時，redis宕機了呢？這數據不就沒了嗎（ redis的數據一開始是在記憶體中的，還沒持久化到磁碟 ）
-
RDB是開了一個子進程來進行創建rdb文件，因此：會造成空間的浪費
-
———————————————————官方話如下：—————————————————————————————
-
如果你希望在redis意外停止工作（例如電源中斷）的情況下丟失的數據最少的話，那麼RDB不適合你.雖然你可以配置不同的save時間點(例如每隔5分鐘並且對數據集有100個寫的操作),是Redis要完整的保存整個數據集是一個比較繁重的工作,你通常會每隔5分鐘或者更久做一次完整的保存,萬一在Redis意外宕機,你可能會丟失幾分鐘的數據
-
RDB 需要經常fork子進程來保存數據集到硬碟上,當數據集比較大的時候,fork的過程是非常耗時的,可能會導致Redis在一些毫秒級內不能響應客戶端的請求.如果數據集巨大並且CPU性能不是很好的情況下,這種情況會持續1秒,AOF也需要fork,但是你可以調節重寫日誌文件的頻率來提高數據集的耐久度
-
優點：
- 適合大規模的數據恢復
- 持久化速度快，相對AOF來說：數據安全（ 二進位文件嘛 ）
—————————————————————官方話如下：—————————————————————————————
- RDB是一個非常緊湊的文件,它保存了某個時間點得數據集,非常適用於數據集的備份,比如你可以在每個小時報保存一下過去24小時內的數據,同時每天保存過去30天的數據,這樣即使出了問題你也可以根據需求恢復到不同版本的數據集
- RDB是一個緊湊的單一文件,很方便傳送到另一個遠端數據中心或者亞馬遜的S3（可能加密），非常適用於災難恢復
- RDB在保存RDB文件時父進程唯一需要做的就是fork出一個子進程,接下來的工作全部由子進程來做，父進程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
- 與AOF相比,在恢復大的數據集的時候，RDB方式會更快一些
2、AOF
2.1）、什麼是AOF
- 全稱：append only file
- AOF是Redis進行持久化的另外一種操作方式
2.2）、配置AOF
2.2.1）、編寫redis.conf文件
- 編寫內容如下：
# 配置AOF
appendonly yes
appendfilename redis.aof
appendfsync everysec
# 下面這兩個是另外一種配置措施，一般都不考慮
# appendfsync always
# # appendfsync no
- appendfsync always：每執行一個寫操作，立即持久化到AOF文件中，性能比較低
- appendfsync everysec：每秒執行一次持久化
- appendfsync no：會根據你的作業系統不同，環境的不同，在一定時間內執行一次持久化
2.2.2）、重啟Redis即可
- 重啟之後，測試如下：
2.2.3）、檢查數據卷映射的文件目錄
-
可見：多出了 .aof文件
-
查看一下這個 aof文件
- 發現：這個aof文件中存儲的就是我們剛剛在redis中存儲key-value時的指令
-
還是老話，前面這些不是老衲想說的，下面的才是老衲準備說的內容
2、AOF的原理
3、AOF的觸發條件
- 一句話：只要配置了，那麼只要啟動Redis就會觸發（ 可以把aof文件刪掉，然後重啟Redis，再看映射文件路徑，就會發現有了aof文件 ）
4、AOF的優缺點
- 缺點：
-
數據恢復慢（ 大數據時，它是去重新執行一遍aof文件中的數據 ，它存的是指令，是一個文本文件，大數據時，這就會變得很大 ，但是：）
- 可以加入這個配置，從而限定：內容超過多大之後，就另起一個aof文件來記錄內容[專業詞：重寫]（ 重新寫一個aof文件 ）
-
—————————————————————官方話如下：—————————————————————————————
-
對於相同的數據集來說，AOF 文件的體積通常要大於 RDB 文件的體積
-
根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。 在一般情況下， 每秒 fsync 的性能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）
-
優點：
- 採用每修改詞義就同步的話，數據的完整性比較好
- 採用每秒同步一次的話，持久化也快，註：容易丟失這一份的數據，對照RDB來看
- 採用從不同步的話，效率蠻高，但是：不建議
—————————————————————官方話如下：—————————————————————————————
-
AOF文件是一個只進行追加的日誌文件,所以不需要寫入seek,即使由於某些原因(磁碟空間已滿，寫的過程中宕機等等)未執行完整的寫入命令,你也也可使用redis-check-aof工具修復這些問題
-
Redis 可以在 AOF 文件體積變得過大時，自動地在後台對 AOF 進行重寫： 重寫後的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在創建新 AOF 文件的過程中，會繼續將命令追加到現有的 AOF 文件裡面，即使重寫過程中發生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，並開始對新 AOF 文件進行追加操作
-
AOF 文件有序地保存了對資料庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析（parse）也很輕鬆。 導出（export） AOF 文件也非常簡單： 舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那麼只要停止伺服器， 移除 AOF 文件末尾的 FLUSHALL 命令， 並重啟 Redis ， 就可以將數據集恢復到 FLUSHALL 執行之前的狀態
-
註：AOF記錄的是每次寫操作，讀操作並不會記錄滴
3、建議
- 同時開啟rdb和aof
