關(guān)于redis的安裝和基本使用熏矿,參考本人博客:
Redis數(shù)據(jù)庫的學(xué)習與實踐—Redis的常用命令及高級應(yīng)用
1 redis持久化(persistence)
1.1 Redis 提供了多種不同級別的持久化方式
- RDB 持久化可以在指定的時間間隔內(nèi)生成數(shù)據(jù)集的時間點快照(point-in-time snapshot)。
- AOF 持久化記錄服務(wù)器執(zhí)行的所有寫操作命令讲竿,并在服務(wù)器啟動時贴彼,通過重新執(zhí)行這些命令來還原數(shù)據(jù)集。 AOF 文件中的命令全部以 Redis 協(xié)議的格式來保存,新命令會被追加到文件的末尾。 Redis 還可以在后臺對 AOF 文件進行重寫(rewrite)螺戳,使得 AOF 文件的體積不會超出保存數(shù)據(jù)集狀態(tài)所需的實際大小。
Redis 還可以同時使用 AOF 持久化和 RDB 持久化桥氏。 在這種情況下温峭, 當 Redis 重啟時猛铅, 它會優(yōu)先使用 AOF 文件來還原數(shù)據(jù)集字支, 因為 AOF 文件保存的數(shù)據(jù)集通常比 RDB 文件所保存的數(shù)據(jù)集更完整。
也可以關(guān)閉持久化功能奸忽,讓數(shù)據(jù)只在服務(wù)器運行時存在堕伪。
1.2 RDB 模式
1.2.1 配置方式
RDB 復(fù)制模式也稱作快照模式,在指定時間間隔中保存數(shù)據(jù)快照栗菜。
save <seconds> <changes>
在 seconds 時間間隔中發(fā)生changes次數(shù)的變化欠雌,就觸發(fā)一次快照保存「沓铮可以配置多條規(guī)則富俄。
除了在redis的配置文件中配置快照的規(guī)則外,還可以手動直接觸發(fā)一次快照而咆。直接調(diào)用SAVE
或者 BGSAVE
命令霍比。
1.2.2 工作原理
當 Redis 需要保存 dump.rdb 文件時, 服務(wù)器執(zhí)行以下操作:
- Redis 調(diào)用 fork() 暴备,同時擁有父進程和子進程悠瞬。
- 子進程將數(shù)據(jù)集寫入到一個臨時 RDB 文件中。
- 當子進程完成對新 RDB 文件的寫入時,Redis 用新 RDB 文件替換原來的 RDB 文件浅妆,并刪除舊的 RDB 文件望迎。
這種工作方式使得 Redis 可以從寫時復(fù)制(copy-on-write)機制中獲益
1.2.3 優(yōu)缺點
優(yōu)點:
- RDB 是一個非常緊湊(compact)的文件,它保存了 Redis 在某個時間點上的數(shù)據(jù)集凌外。 這種文件非常適合用于進行備份: 比如說辩尊,你可以在最近的 24 小時內(nèi),每小時備份一次 RDB 文件康辑,并且在每個月的每一天对省,也備份一個 RDB 文件。 這樣的話晾捏,即使遇上問題蒿涎,也可以隨時將數(shù)據(jù)集還原到不同的版本。
- RDB 非常適用于災(zāi)難恢復(fù)(disaster recovery):它只有一個文件惦辛,并且內(nèi)容都非常緊湊劳秋,可以(在加密后)將它傳送到別的數(shù)據(jù)中心。
- RDB 可以最大化 Redis 的性能:父進程在保存 RDB 文件時唯一要做的就是 fork 出一個子進程胖齐,然后這個子進程就會處理接下來的所有保存工作玻淑,父進程無須執(zhí)行任何磁盤 I/O 操作。
- RDB 在恢復(fù)大數(shù)據(jù)集時的速度比 AOF 的恢復(fù)速度要快呀伙。
缺點:
- rdb模式按照指定時間發(fā)生幾次變化來持久化數(shù)據(jù)补履,這就有可能在數(shù)據(jù)沒有發(fā)生持久化的時候就宕機,導(dǎo)致當前時間段內(nèi)的數(shù)據(jù)丟失
- 每次rdb回fork子進程進行剿另,當數(shù)據(jù)量比較大的時候fork很耗時間箫锤,CPU緊張的時候更容易出現(xiàn)卡頓。
1.3 AOF(AppendOnly File) 模式
在服務(wù)器突然斷電雨女,死機谚攒,或者調(diào)用kill -9
命令殺死redis的時候,使用rdb的方式持久化是不夠氛堕,這個時候最新的操作是沒有被持久化馏臭。因此redis提供另外的一種持久化方式,append-only file 讼稚。
1.3.1 AOF 配置方式
要啟動AOF的方式括儒,需要在配置文件中設(shè)置
appendonly yes
配置時候,redis沒產(chǎn)生一條指令都會被追加到AOF文件中锐想,當服務(wù)器重啟的時候帮寻,redis就從這個文件中重新執(zhí)行指令來回復(fù)數(shù)據(jù)到內(nèi)存中。
aof重寫
通過上面不難發(fā)現(xiàn)痛倚,如果每次執(zhí)行指令被保存规婆,aof文件會越來遠大。例如,一個increment 100次抒蚜,就有100條指令掘鄙,但是實際可以在回復(fù)數(shù)據(jù)的時候調(diào)用一句set
指令回復(fù)到最后的數(shù)據(jù)就可以了。所以redis也內(nèi)置了重寫機制嗡髓。在不中斷對客戶端的服務(wù)器的情況下操漠,在后臺對aof文件重寫。reids 2.2之前饿这。需要是不是的調(diào)用BGREWRIETAOF
指令浊伙,redis 2.4之后都是自動觸發(fā)此指令。
同步頻率配置 (how durable)
多久把數(shù)據(jù)同步(fsync)一次到文件的策略有三種:
- fsync always 每次新的指令长捧,每條指令都加到aof嚣鄙。此方法非常非常的慢,但是非常安全串结。
- fsync everysec每個一秒鐘同步一次哑子。這種方法速度很快,最壞情況是損失1s內(nèi)的數(shù)據(jù)
- never no 不同步肌割,而是交給操作系統(tǒng)去處理卧蜓。非常快把敞,但是不安全弥奸。
redis默認和推薦的方法是每秒同步方式。
配置方式:
# appendfsync always
appendfsync everysec
# appendfsync no
AOF文件損壞怎么處理
當AOF文件損壞的時候奋早,redis不能再從AOF中恢復(fù)數(shù)據(jù)盛霎,可按找下面的步驟處理:
- 備份當前AOF文件
- 使用redis-check-aof工具修復(fù)原AOF文件,執(zhí)行命令
redis-check-aof --fix
- 選擇性的使用
diff -u
檢測兩個文件的不同 - 用修改后的文件重啟服務(wù)
1.3.2 AOF 工作原理(rewrite)
- redis forks 一個子進程
- 子進程開始把AOF寫到一個臨時文件
- 父進程計算所有的新變化并放在一個內(nèi)存緩沖區(qū)(同時他還把這些變化寫進老的AOF文件伸蚯,所以重寫失敗摩渺,也是安全的)
- 最后。redis自動用新文件替換老文件剂邮。開始往新文件添加數(shù)據(jù)
1.3.3 AOF 優(yōu)缺點
AOF 優(yōu)點:
- 數(shù)據(jù)安全性更高,從同步機制上看横侦。always方式滿挥萌,但每條指令都存儲。
- aof是一個追加文件枉侧,出現(xiàn)問題可以使用redis-check-aof工具修復(fù)
- 文件過大的時候會使用重寫方式引瀑,只要文件存在,數(shù)據(jù)有可以恢復(fù)
- 文件內(nèi)容以redis的協(xié)議存儲榨馁,方便解讀憨栽。能偶方便導(dǎo)出和解析。
AOF 缺點:
- 數(shù)據(jù)量過大的時候,redis的aof體積會比rdb文件大
- 根據(jù)所使用的 fsync 策略屑柔,AOF 的速度可能會慢于 RDB 屡萤。 在一般情況下, 每秒 fsync 的性能依然非常高掸宛, 而關(guān)閉 fsync 可以讓 AOF 的速度和 RDB 一樣快死陆, 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時唧瘾,RDB 可以提供更有保證的最大延遲時間(latency)
1.4 數(shù)據(jù)容災(zāi)
需要經(jīng)常對數(shù)據(jù)數(shù)據(jù)(rdb文件)進行備份
- 使用corn job方式措译,定去備份rdb文件到某個文件夾
- 備份時間打上時間標簽,使用find找到很早期的備份刪除
- 定期把備份放到當前物理機之外的機器備份一份饰序。