文章目錄
Redis的持久化機制
RDB
每隔一段時間,把內存中的數據寫入磁盤的臨時文件,作爲快照,恢復的時候把快照文件讀進內存。如果宕機重啓,那麼內存裏的數據肯定會沒有的,那麼再次啓動redis後,則會恢復。
優點
1.可以存放不同的版本
2.非常方便的存放和恢復,可以遠程傳輸
3.備份文件完整
4.迅速的恢復
缺點
1.如果在備份的過程中出現問題,備份文件會丟失,有可能有數據的不一致性
2.如果數據集比較大,可能對CPU影響比較大
3.不能實時備份
RDB配置
RDB配置路徑:/usr/local/redis/6379.connf
注:每個人的路徑可能不一樣,就是redis的核心配置文件中。
配置文件都在這個SNAPSHOTTING
下面:
- 首先第一個:save
保存機制
save 900 1 *如果一個緩存更新,則900秒後備份
save 300 10 *如果10個緩存更新,則300秒後備份
save 60 10000 *如果10000個緩存更新,則60秒後備份
- 第二個:stop-writes-on-bgsave-error
設置如果save的過程出錯,是否停止寫操作(用來保證備份文件的穩定)
yes:如果save過程出錯,則停止寫操作
no:可能造成數據不一致
- 第三個:rdbcompression
是否開啓壓縮備份文件
yes:開啓rdb壓縮模式
no:關閉,會節約cpu損耗,但是文件會大
- 第四個:rdbchecksum
是否使用CRC64算法校驗對rdb進行數據校驗
yes:使用CRC64算法校驗對rdb進行數據校驗,有10%性能損耗
no:不校驗
- 第五個:dbfilename
備份文件名稱
第六個:dir
備份文件存放路徑
總結:RDB適合大量數據的恢復,但是數據的完整性和一致性可能會不足。
AOF
以日誌的形式來記錄用戶請求的寫操作。讀操作不會記錄,因爲寫操作纔會存存儲。文件以追加的形式而不是修改的形式。redis的aof恢復其實就是把追加的文件從開始到結尾讀取執行寫操作。
優點
1.AOF更加耐用,可以以秒級別爲單位備份,如果發生問題,也只會丟失最後一秒的數據,大大增加了可靠性和數據完整性。所以AOF可以每秒備份一次,使用fsync操作。
2.以log日誌形式追加,如果磁盤滿了,會執行 redis-check-aof 工具當數據太大的時候,redis可以在後臺自動重寫aof。
3.當redis繼續把日誌追加到老的文件中去時,重寫也是非常安全的,不會影響客戶端的讀寫操作。
AOF 日誌包含的所有寫操作,會更加便於redis的解析恢復。
缺點
1.相同的數據,同一份數據,AOF比RDB大針對不同的同步機制,AOF會比RDB慢,因爲AOF每秒都會備份做寫操作,這樣相對與RDB來說就略低。
2.每秒備份fsync沒毛病,但是如果客戶端的每次寫入就做一次備份fsync的話,那麼redis的性能就會下降。
3.AOF發生過bug,就是數據恢復的時候數據不完整,這樣顯得AOF會比較脆弱,容易出現bug,因爲AOF沒有RDB那麼簡單,但是呢爲了防止bug的產生,AOF就不會根據舊的指令去重構,而是根據當時緩存中存在的數據指令去做重構,這樣就更加健壯和可靠了。
AOF配置
AOF配置路徑:/usr/local/redis/6379.connf
注:每個人的路徑可能不一樣,就是redis的核心配置文件中。
配置文件都在這個APPEND ONLY MODE
下面:
- 第一個appendonly
是否開啓AOF
yes 開啓
no 不開啓
- 第二個appendfilename
備份文件名稱
- 第三個appendfsync
備份模式
# no:不同步
# everysec:每秒備份,推薦使用
# always:每次操作都會備份,安全並且數據完整,但是慢性能差
- 第四個no-appendfsync-on-rewrite
重寫的時候是否要同步
yes 同步
no 不同步,推薦這個,安全
- 第五個auto-aof-rewrite-percentage和auto-aof-rewrite-min-size
重寫機制:避免文件越來越大,自動優化壓縮指令,會fork一個新的進程去完成重寫動作,新進程裏的內存數據會被重寫,此時舊的aof文件不會被讀取使用,類似rdb
# 當前AOF文件的大小是上次AOF大小的100% 並且文件體積達到64m,滿足兩者則觸發重寫
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
到底採用RDB還是AOF呢?
1.如果你能接受一段時間的緩存丟失,那麼可以使用RDB
2.如果你對實時性的數據比較care,那麼就用AOF
3.使用RDB和AOF結合一起做持久化,RDB做冷備,可以在不同時期對不同版本做恢復,AOF做熱備,保證數據僅僅只有1秒的損失。當AOF破損不可用了,那麼再用RDB恢復,這樣就做到了兩者的相互結合,也就是說Redis恢復會先加載AOF,如果AOF有問題會再加載RDB,這樣就達到冷熱備份的目的了。
aof重寫機制
aof的重寫雖然叫做重寫,但其實是以一種更省內存的方式去存儲備份文件。
Redis服務器可以創建一個新的AOF文件來替代現有的AOF文件,新舊兩個文件所保存的數據庫狀態是相同的,但是新的AOF文件不會包含任何浪費空間的冗餘命令,通常體積會較舊AOF文件小很多。
具體可以看這篇文章:Redis之AOF重寫及其實現原理
Redis的主從複製,讀寫分離
主從複製原理解析
首先我們會有兩種節點,一種master主節點,一種slave從節點也就是奴隸節點,主要是用來處理一些讀的請求,首先我們會啓動master,然後我們會配置master配置到slave節點裏面,然後我們配置並啓動slave節點,當slave節點啓動後會ping我們的master節點,告訴master節點,我啓動了給我點事情做吧,這個時候master節點會把自己的RDB文件先拷貝到自己的磁盤裏面然後傳遞到slave節點中,slave先把這個RDB文件下載到本地,然後在加載到內存裏面去,這樣就完成複製過程,這個過程是第一次初始話的過程,在第一次以後,第二次第三次每次master寫一條都會同步的傳遞到slave節點下面,如此就做到了同步。
Redis主從複製配置
需要那臺Redis當從機,就修改那臺機器的配置文件
配置路徑:/usr/local/redis/6379.connf
注:每個人的路徑可能不一樣,就是redis的核心配置文件中。
配置文件都在這個REPLICATION
下面:
- 第一步配置主節點replicaof
# masterip 主節點內網ip
# masterport 主節點redis端口
replicaof <masterip> <masterport>
- 第二步配置主節點的密碼masterauth
masterauth root
- 第三步 設置從節點只讀replica-read-only
replica-read-only yes
- 最後實現效果
# 查看redis信息
info replication
這樣就實現了redis的讀寫分離
Redis緩存過期機制(清理過期的緩存)
(主動)定期刪除
redis定期定時的做一個檢查,抽查隨機一批key,key的多少可以進行設置,一旦發現key過期了就會給他刪掉
hz配置
#設置一次抽查多少個kye
hz 10
(被動)惰性刪除
當客戶端請求一個已經過期的key的時候,那麼redis會檢查這個key是否過期,如果過期了,則刪除,然後返回一個nil。這種策略對cpu比較友好,不會有太多的損耗,但是內存佔用會比較高。
內存淘汰機制(清理沒有過期的緩存)
內存佔滿了,可以使用硬盤,來保存,但是沒意義,因爲硬盤沒有內存快,會影響redis性能。所以,當內存佔用滿了以後,redis提供了一套緩存淘汰機制:MEMORY MANAGEMENT,清理的放到內存中沒有過期的key,這個在配置文件中也可以配置,有幾種清理機制
maxmemory:當內存已使用率到達,則開始清理緩存
maxmemory-policy:可以在這塊選擇清理機制
清理機制解讀:
* noeviction:舊緩存永不過期,新緩存設置不了,返回錯誤
* allkeys-lru:清除最少用的舊緩存,然後保存新的緩存(推薦使用)
* allkeys-random:在所有的緩存中隨機刪除(不推薦)
* volatile-lru:在那些設置了expire過期時間的緩存中,清除最少用的舊緩存,然後保存新的緩存
* volatile-random:在那些設置了expire過期時間的緩存中,隨機刪除緩存
* volatile-ttl:在那些設置了expire過期時間的緩存中,刪除即將過期的
如果覺得寫得還可以,希望可以給我贊,您的贊是我前進的最大動力!!!