其他更多java基礎文章:
java基礎學習(目錄)
這一系列主要是針對慕課網的redis實戰寫的一個覆盤文章,對視訊內容進行一次整理和輸出。在整理輸出找資料的過程中,發現了一個也是慕課網系列的整理文章,覺得還挺不錯的。
高可用Redis(一):通用命令,資料結構和內部編碼,單執行緒架構
高可用Redis(二):字串型別
高可用Redis(三):Hash型別
高可用Redis(四):列表,集合與有序集合
高可用Redis(五):瑞士軍刀之慢查詢,Pipeline和釋出訂閱
高可用Redis(六):瑞士軍刀之bitmap,HyperLoglog和GEO
高可用Redis(七):Redis持久化
高可用Redis(八):Redis主從複製
高可用Redis(九):Redis Sentinel
高可用Redis(十):Redis原生命令搭建叢集
高可用Redis(十一):使用redis-trib.rb工具搭建叢集
高可用Redis(十二):Redis Cluster
高可用Redis(十三):Redis快取的使用和設計
總結
RBD
RDB持久化功能可以將Redis中所有資料生成快照並以二進行檔案的形式儲存到硬碟裡,檔名為.RDB檔案。
在Redis啟動時載入RDB檔案,Redis讀取RDB檔案內容,還原伺服器原有的資料庫資料
RBD的三種方式
1. 使用SAVE命令手動同步建立RDB檔案
客戶端向Redis服務端傳送SAVE命令,服務端把當前所有的資料同步儲存為一個RDB檔案 通過向伺服器傳送SAVE命令,Redis會建立一個新的RDB檔案。在執行SAVE命令的過程中(也就是即時建立RDB檔案的過程中),Redis服務端將被阻塞,無法處理客戶端傳送的其他命令請求。
2. 使用BGSAVE命令非同步建立RDB檔案
BGSAVE不會造成redis伺服器阻塞:在執行BGSAVE命令的過程中,Redis服務端仍然可以正常的處理其他的命令請求。Redis服務端通過fork()來生成一個名叫redis-rdb-bgsave的程式,由redis-rdb-bgsave子程式來建立RDB檔案,而Redis主程式則繼續處理客戶端的命令請求。
BGSAVE是一個非同步命令,Redis客戶端向Redis服務端傳送BGSAVE命令後會立即得到回覆,而實際的操作在Redis服務端回覆之後才開始
3. 自動建立RDB檔案
開啟Redis的配置檔案/etc/redis.conf
save 900 1
save 300 10
save 60 10000
複製程式碼
自動持久化配置解釋:
save 900 1表示:如果距離上一次建立RDB檔案已經過去的900秒時間內,Redis中的資料發生了1次改動,則自動執行BGSAVE命令
save 300 10表示:如果距離上一次建立RDB檔案已經過去的300秒時間內,Redis中的資料發生了10次改動,則自動執行BGSAVE命令
save 60 10000表示:如果距離上一次建立RDB檔案已經過去了60秒時間內,Redis中的資料發生了10000次改動,則自動執行BGSAVE命令
複製程式碼
當三個條件中的任意一個條件被滿足時,Redis就會自動執行BGSAVE命令
RDB現存問題
1. 耗時耗效能
Redis把記憶體中的資料dump到硬碟中生成RDB檔案,首先要把所有的資料都進行持久化,所需要的時間複雜度為O(N),同時把資料dump到檔案中,也需要消耗CPU資源, 由於BGSAVE命令有一個fork子程式的過程,雖然不是完整的記憶體拷貝,而是基於copy-on-write的策略,但是如果Redis中的資料非常多,佔用的記憶體頁也會非常大,fork子程式時消耗的記憶體資源也會很多 磁碟IO效能的消耗,生成RDB檔案本來就是把記憶體中的資料儲存到硬碟當中,如果生成的RDB檔案非常大,儲存到硬碟的過程中消耗非常多的硬碟IO
2. 不可控,丟失資料
自動建立RDB檔案的過程中,在上一次建立RDB檔案以後,又向Redis中寫入多條資料,如果此時Redis服務停止,則從上一次建立RDB檔案到Redis服務掛機這個時間段內的資料就丟失了
AOF(AppendOnlyFile)方式
AOF持久化儲存資料庫的方法是:每當有修改的資料庫的命令被執行時,伺服器就會將執行的命令寫入到AOF檔案的末尾。
因為AOF檔案裡面儲存了伺服器執行過的所有資料庫修改的命令,所以Redis只要重新執行一遍AOF檔案裡面儲存的命令,就可以達到還原資料庫的目的
AOF三種策略
為了控制Redis伺服器在遇到意外停機時丟失的資料量,Redis為AOF持久化提供了appendfsync
選項,這個選項的值可以是always
,everysec
或者no
- Always
Redis每寫入一個命令,always會把每條命令都重新整理到硬碟的緩衝區當中然後將緩衝區裡的資料寫入到硬碟裡。 這種模式下,Redis即使用遭遇意外停機,也不會丟失任何自己已經成功執行的資料
- Everysec
Redis每一秒呼叫一次fdatasync,將緩衝區裡的命令寫入到硬碟裡, 這種模式下,當Redis的資料交換很多的時候可以保護硬碟 即使Redis遭遇意外停機時,最多隻丟失一秒鐘內的執行的資料
- No
伺服器不主動呼叫fdatasync,由作業系統決定任何將緩衝區裡面的命令寫入到硬碟裡,這種模式下,伺服器遭遇意外停機時,丟失的命令的數量是不確定的
AOF三種方式比較
執行速度:always的速度慢,everysec和no都很快
- always不丟失資料,但是硬碟IO開銷很多,一般的SATA硬碟一秒種只能寫入幾百次資料
- everysec每秒同步一次資料,如果Redis發生故障,可能會丟失1秒鐘的資料
- no則系統控制,不可控,不知道會丟失多少資料
AOF重寫功能簡介
隨著伺服器的不斷執行,為了記錄Redis中資料的變化,Redis會將越來越多的命令寫入到AOF檔案中,使得AOF檔案的體積來斷增大。 為了讓AOF檔案的大小控制在合理的範圍,redis提供了AOF重寫功能,通過這個功能,伺服器可以產生一個新的AOF檔案。
新的AOF檔案記錄的資料庫資料和原有AOF檔案記錄的資料庫資料完全一樣
新的AOF檔案會使用盡可能少的命令來記錄資料庫資料,因此新的AOF檔案的體積通常會比原有AOF檔案的體積要小得多
AOF重寫期間,伺服器不會被阻塞,可以正常處理客戶端傳送的命令請求
通過配置選項自動執行BGREWRITEAOF命令
- auto-aof-rewrite-min-size
觸發AOF重寫所需的最小體積:只要在AOF檔案的大小超過設定的size時,Redis會進行AOF重寫,這個選項用於避免對體積過小的AOF檔案進行重寫
- auto-aof-rewrite-percentage
指定觸發重寫所需的AOF檔案體積百分比:當AOF檔案的體積大於auto-aof-rewrite-min-size
指定的體積,並且超過上一次重寫之後的AOF檔案體積的percent%時,就會觸發AOF重寫,如果伺服器剛啟動不久,還沒有進行過AOF重寫,那麼使用伺服器啟動時載入的AOF檔案的體積來作為基準值。
將這個值設定為0表示關閉自動AOF重寫功能
只有當上面兩個條件同時滿足時才會觸發Redis的AOF重寫功能