1、默認(rèn)持久化
表示在900s存一個(gè)對(duì)象，300s存10個(gè)對(duì)象，60s存10000個(gè)對(duì)象時(shí)就會(huì)自動(dòng)觸發(fā)RDB的持久化
save 900 1
save 300 10
save 60 10000
快照文件名，可自定義
dbfilename dump.rdb
快照文件保存目錄
dir ./
如果bgsave出現(xiàn)錯(cuò)誤,是否停止寫入，一般都配置為yes
stop-writes-on-bgsave-error yes
開啟壓縮rdb
rdbcompression yes?
檢驗(yàn)和
rdbchecksum yes
如果想要關(guān)閉快照持久化，做下面修改：
注釋快照持久化規(guī)則
#save 900 1
#save 300 10
#save 60 10000
設(shè)置為空
save ""
之后重啟redis
備份 save 說明：
可以使用 SAVE 和 BGSAVE 命令手動(dòng)備份，兩者有區(qū)別 ： SAVE命令表示使用主進(jìn)程將當(dāng)前數(shù)據(jù)庫快照到dump文件 ， BGSAVE命令表示，主進(jìn)程會(huì)fork一個(gè)子進(jìn)程來進(jìn)行快照備份。前者會(huì)阻塞主進(jìn)程，而后者不會(huì)，所以一般使用BGSAVE進(jìn)行手動(dòng)備份。
可以使用命令關(guān)閉db，不需要重啟服務(wù)
config set save ""
查看是否生效
config get save
2、如果想使用aof方式做持久化
開啟appendonlylog，開啟的話每次寫操作會(huì)記一條log。相當(dāng)于mysql的binlog；不同的是，每次redis啟動(dòng)都會(huì)讀此文件構(gòu)建完整數(shù)據(jù)。即使刪除rdb文件，數(shù)據(jù)也是安全的
appendonly no
>>
appendonly yes?
aof文件保存目錄和文件名可以自定義
dir ./
appendfilename "appendonly.aof"
aof策略，每秒鐘強(qiáng)制寫入磁盤一次
appendfsync everysec
在重寫時(shí)是否不需要append,這個(gè)配置需要根據(jù)實(shí)際權(quán)衡，因?yàn)樵谥貙懙耐瑫r(shí)進(jìn)行append會(huì)有性能開銷，當(dāng)然如果不append也可能會(huì)丟失少量數(shù)據(jù)，以性能為優(yōu)先的時(shí)候關(guān)閉append
no-appendfsync-on-rewrite no
>>
no-appendfsync-on-rewrite yes
使用命令關(guān)閉aof
config set appendfsync no?
查看是否生效
config get appendfsync
3、RDB和AOF方式持久化比較
RDB觸發(fā)機(jī)制：
save(同步)
執(zhí)行一條save命令,就會(huì)生成一個(gè)RDB文件
阻塞（保存是阻塞主進(jìn)程，客戶端無法連接redis，等SAVE完成后，主進(jìn)程才開始工作，客戶端可以連接）
bgsave(異步)
執(zhí)行bgsave命令
fork()一個(gè)子進(jìn)程在后臺(tái)去創(chuàng)建RDB文件
不影響主進(jìn)程，客戶端可以正常鏈接redis，等子進(jìn)程fork執(zhí)行save完成后，通知主進(jìn)程，子進(jìn)程關(guān)閉。
RDB持久化是指在指定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)和操作通過快照的方式保存到dump.rdb文件，RDB 是一個(gè)非常緊湊（compact）的文件，本身文件比較小， 這種文件非常適合用于進(jìn)行備份?；謴?fù)直接載入到內(nèi)存即可，所以恢復(fù)數(shù)據(jù)比較快。但是如果服務(wù)器在非備份時(shí)間跨度內(nèi)發(fā)生了故障，無法做到對(duì)當(dāng)前狀態(tài)的實(shí)時(shí)保存，導(dǎo)致數(shù)據(jù)丟失，另外遇到宕機(jī)等情況的時(shí)候快照的數(shù)據(jù)可能會(huì)不完整。每次保存 RDB文件時(shí)，save會(huì)阻塞Redis， bgsave不會(huì)阻塞Redis，但是需要 fork()出一個(gè)子進(jìn)程，由子進(jìn)程來執(zhí)行具體的持久化工作，在數(shù)據(jù)集比較龐大時(shí)，fork()可能會(huì)非常耗時(shí)，造成服務(wù)器在某某毫秒內(nèi)停止處理客戶端，對(duì)CPU資源消耗較大，甚至可能使得這種停止時(shí)間長(zhǎng)達(dá)整整一秒。
AOF持久化是在每次接受到的寫命令通過 write函數(shù)追加到appendonly.aof文件，使用策略可以大限度的保證意外情況下的數(shù)據(jù)完整性，每秒鐘一次 fsync ，或者每次執(zhí)行寫入命令時(shí) fsync。AOF 的默認(rèn)策略為每秒鐘 fsync 一次，在這種配置下，Redis 仍然可以保持良好的性能，并且就算發(fā)生故障停機(jī)，也最多只會(huì)丟失一秒鐘的數(shù)據(jù)，（ fsync 會(huì)在后臺(tái)線程執(zhí)行，所以主線程可以繼續(xù)努力地處理命令請(qǐng)求）。因?yàn)?AOF 的運(yùn)作方式是不斷地將命令追加到文件的末尾，恢復(fù)數(shù)據(jù)就是逐條的執(zhí)行命令，所以隨著寫入命令的不斷增加， AOF 文件的體積也會(huì)變得越來越大，也會(huì)使得恢復(fù)過程變得漫長(zhǎng)。
兩種方式恢復(fù)數(shù)據(jù)：
RDB：
制定策略，自動(dòng)定時(shí)的把dump.rdb文件備份到備機(jī)上，恢復(fù)過程就是把備機(jī)的文件拷貝到redis服務(wù)器快照文件存放目錄下，命名為dump.rdb，然后啟動(dòng)redis服務(wù)即可。
AOF：
假如當(dāng)不小心執(zhí)行了 flushall 清除了所有的數(shù)據(jù)后，打開 appendonly.aof 的文件，刪除末尾的命令 flushall ，最好利用 redis-check-aof這個(gè)工具來檢測(cè)一下你修改過后的 aof 文件是否正常，以防啟動(dòng)恢復(fù)數(shù)據(jù)的時(shí)候出錯(cuò)，顯示 AOF is valid aof 說明文件是有效的，那么可以重啟 redis 恢復(fù)數(shù)據(jù)了。
兩種方式選擇：
只做緩存，如果希望數(shù)據(jù)在服務(wù)器運(yùn)行的時(shí)候存在，可以不使用任何持久化。
如果可以忍受一段時(shí)間的數(shù)據(jù)丟失可以使用RDB方式
如果要求數(shù)據(jù)實(shí)時(shí)備份，就需要選擇AOF方式
建議同時(shí)開啟兩種持久化：
在這種情況下,當(dāng)redis重啟的時(shí)候會(huì)優(yōu)先載入AOF文件來恢復(fù)原始的數(shù)據(jù)
不建議只使用AOF，因?yàn)锳OF持久化存在潛在的BUG
RDB文件用作后備用途，建議只保留 save 900 1 這條規(guī)則
應(yīng)該盡量減少AOF rewrite的頻率，AOF重寫的基礎(chǔ)大小默認(rèn)值64M太小，可以設(shè)到5G以上。默認(rèn)超過原大小100%大小時(shí)重寫可以改到適當(dāng)?shù)臄?shù)值。
4、解決redis aof文件過大的問題
執(zhí)行BGREWRITEAOF命令對(duì)redis的AOF進(jìn)行重寫
redis-cli BGREWRITEAOF
AOF重寫：
(1) 隨著AOF文件越來越大，里面會(huì)有大部分是重復(fù)命令或者可以合并的命令（100次incr = set key 100）
(2) 重寫的好處：減少AOF日志尺寸，減少內(nèi)存占用，加快數(shù)據(jù)庫恢復(fù)時(shí)間。
執(zhí)行一個(gè) AOF文件重寫操作，重寫會(huì)創(chuàng)建一個(gè)當(dāng)前 AOF 文件的體積優(yōu)化版本。
即使 BGREWRITEAOF 執(zhí)行失敗，也不會(huì)有任何數(shù)據(jù)丟失，因?yàn)榕f的 AOF 文件在 BGREWRITEAOF 成功之前不會(huì)被修改。
默認(rèn)自動(dòng)觸發(fā)重寫規(guī)則
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
percentage是指，當(dāng)redis當(dāng)前的aof文件大小相對(duì)于上一次進(jìn)行rewriteaof操作時(shí)的大小增長(zhǎng)率大于100%時(shí)，就會(huì)進(jìn)行rewrite。
但是，當(dāng)增長(zhǎng)率大于了100%，實(shí)際上aof文件其實(shí)很小，這樣rewrite就沒有必要了，所以，還需要設(shè)置一個(gè)min-size，當(dāng)redis的增長(zhǎng)率大于100%，并且min-size的大于64mb時(shí)，就會(huì)執(zhí)行rewriteaof操作。
5、RDB和AOF其他
5.1、重寫
如果想關(guān)閉rewriteaof操作，可以將percentage設(shè)置為0。
redis會(huì)在以下三個(gè)時(shí)候進(jìn)行rewrite操作
Redis接收到客戶端發(fā)送的bgrewriteaof命令
Redis aof文件增長(zhǎng)率和增長(zhǎng)大小達(dá)到auto-aof-rewrite
Redis接收到客戶端發(fā)送的”CONFIG SET appendonly yes”命令
5.2、 數(shù)據(jù)恢復(fù)順序
當(dāng)redis重啟時(shí)，會(huì)按照以下優(yōu)先級(jí)進(jìn)行啟動(dòng)：
如果只配置AOF,重啟時(shí)加載AOF文件恢復(fù)數(shù)據(jù)；
如果同時(shí) 配置了RBD和AOF,啟動(dòng)是只加載AOF文件恢復(fù)數(shù)據(jù);
如果只配置RBD,啟動(dòng)時(shí)將加載dump文件恢復(fù)數(shù)據(jù)。
5.3、AOF配置文件損壞修復(fù)方法
對(duì)于錯(cuò)誤格式的AOF文件，先進(jìn)行備份，然后采用redis-check-aof--fix命令進(jìn)行修復(fù)，修復(fù)后使用diff-u對(duì)比數(shù)據(jù)的差異，找出丟失的數(shù)據(jù)，有些可以人工修改補(bǔ)全。AOF文件可能存在結(jié)尾不完整的情況，比如機(jī)器突然掉電導(dǎo)致AOF尾部文件命令寫入不全。Redis為我們提供了aof-load-truncated配置來兼容這種情況，默認(rèn)開啟。加載AOF時(shí)，當(dāng)遇到此問題時(shí)會(huì)忽略并繼續(xù)啟動(dòng)。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。
重慶分公司
重慶分公司
