Redis6的持久化配置，你知道多少？
本文轉載自微信公眾號「零零后程序員小三」，作者003 。轉載本文請聯(lián)系零零后程序員小三公眾號。
本文是對Redis6的持久化配置，了解什么是AOF和RDB，它們的優(yōu)缺點是什么，該如何使用。
什么是Redis持久化?
我們都知道Redis是一個基于內(nèi)存的數(shù)據(jù)庫，如果沒有給Redis配置持久化的話，每當重啟后Redis的數(shù)據(jù)就會全部丟失，會很麻煩。因此Redis需要開啟持久化功能，將數(shù)據(jù)保存到磁盤上，當Redis重啟后可以在磁盤中恢復數(shù)據(jù)。這樣緩存數(shù)據(jù)就不容易丟失了。
開啟持久化的兩種方式
Redis開啟持久化有兩種方式：RDB(Redis DataBase)與AOF(append only file)
RDB持久化
RDB其實就是把數(shù)據(jù)以快照的形式保存到磁盤上。什么是快照呢?你可以把快照理解成當前這一時刻的數(shù)據(jù)拍成一張照片保存下來。RDB持久化是指在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照形式寫入磁盤。也是默認的持久化方式，這種方式就是將內(nèi)存中的數(shù)據(jù)寫入到二進制文件當中，默認的文件名為dump.rdb
既然RDB機制是通過某個時刻把所有數(shù)據(jù)生成一張快照來進行保存的，那么就應該會有一種觸發(fā)機制來實現(xiàn)這個過程。對于RDB來說，提供了三種機制：save、bgsave、自動化。
1.save觸發(fā)方式：該命令會阻塞當前Redis服務器，執(zhí)行save命令的時候，Redis不能處理其他的命令，直到RDB過程執(zhí)行完成為止。執(zhí)行完成的時候如果存在老的RDB文件，就會把新的替換掉舊的。
2.bgsave觸發(fā)方式：執(zhí)行該命令的時候，Redis會在后臺進行異步快照操作，快照的同時還可以響應客戶端的請求，具體的操作是Redis進程執(zhí)行fork操作創(chuàng)建了一個子進程，而RDB持久化過程由子進程負載，完成后自動結束。阻塞只發(fā)生在子進程。
3.自動化觸發(fā)：由配置文件來完成，配置觸發(fā)Redis的RDB持久化條件。
「RDB有何優(yōu)缺點?」
優(yōu)點：
(1)RDB文件緊湊，全量備份，比較適用于備份和災難恢復
(2)生成RDB文件的時候，Redis主進程會開啟讓一個子進程來完成所有的保存操作，主進程不需要任何的IO操作
(3)RDB在恢復大數(shù)據(jù)集的時候速度快。
缺點：
因為RDB快照是一次全量備份的，存儲的是內(nèi)存數(shù)據(jù)二進制形式，在存儲上會非常的緊湊。當進行快照持久化時，會開啟一個子進程負載快照的持久化，子進程會擁有父進程的內(nèi)存數(shù)據(jù)，父進程修改內(nèi)存子進程不會反應出來，所有當在快照持久化時修改的數(shù)據(jù)不會得以保存，還有可能導致丟失數(shù)據(jù)。
核心配置：(dbfilename 文件名，dir持久化文件的路徑)
- #任何ip可以訪問
- bind 0.0.0.0
- #守護進程
- daemonize yes
- #密碼
- requirepass 123456
- #⽇志⽂件
- logfile "/usr/local/redis/log/redis.log"
- #持久化⽂件名稱
- dbfilename xdclass.rdb
- #持久化⽂件存儲路徑
- dir /usr/local/redis/data
- #持久化策略, 10秒內(nèi)有個1個key改動，執(zhí)⾏快照
- save 10 1
- ######之前配置######
- #導出rdb數(shù)據(jù)庫⽂件壓縮字符串和對象,默認是yes，會浪費
- CPU但是節(jié)省空間
- rdbcompression yes
- # 導⼊時是否檢查
- rdbchecksum yes
RDB操作實戰(zhàn)
配置文件(根據(jù)自行需要配置)
- bind 0.0.0.0
- daemonize yes
- requirepass 123456Xdclass
- logfile "/usr/local/redis/log/redis.log"
- dbfilename xdclass.rdb
- dir /usr/local/redis/data
- #關閉rdb
- #save ""
- #10秒2個key變動則觸發(fā)rdb
- save 10 2
- #100秒5個key變動則觸發(fā)rdb
- save 100 5
- #壓縮
- rdbcompression yes
- #檢查
- rdbchecksum yes
備注：Linux內(nèi)存分配策略，0表示內(nèi)核將檢查是否有足夠的內(nèi)存供應用進程所使用;如果有足夠內(nèi)存則申請允許;否則申請失敗，并發(fā)錯誤返回給應用進程
1表示內(nèi)核允許分配所有的物理內(nèi)存，而不管當前的內(nèi)存狀態(tài)如何
2表示內(nèi)核允許分配超過所有物理內(nèi)存和交換總和內(nèi)存
- 解決⽅式
- echo 1 > /proc/sys/vm/overcommit_memory
- 持久化配置
- vim /etc/sysctl.conf
- 改為
- vm.overcommit_memory=1
- 修改sysctl.conf后，需要執(zhí)⾏ sysctl -p 以使⽣效。
AOF持久化
上面介紹了RDB持久化是全量備份的，但這種備份總是耗時的，有時候我們提供了一種更為高效的方式AOF，工作機制很簡單，Redis會將每一個收到的命令都通過write函數(shù)追加到文件中。通俗點理解就是像日志記錄一樣。
配置：
與RDB配置方式不一樣
- appendonly yes 默認為不開啟
- AOF文件名通過appendfilename配置設置，默認文件名為appendonly.aof
- 存儲路徑同RDB持久化方式一致，使用dir配置
- bind 0.0.0.0
- daemonize yes
- requirepass 123456Xdclass
- logfile "/usr/local/redis/log/redis.log"
- dbfilename xdclass.rdb
- dir /usr/local/redis/data
- #save 10 2
- #save 100 5
- save ""
- rdbcompression yes
- #對rdb數(shù)據(jù)進⾏校驗，耗費CPU資源，默認為yes
- rdbchecksum yes
- appendonly yes
- appendfilename "appendonly.aof"
- appendfsync everysec
AOF核心原理
(1)Redis每次寫入命令會追加到aof_buf緩沖區(qū)中
(2)AOF緩沖區(qū)根據(jù)對應的策略向硬盤做同步的操作
(3)高頻AOF會帶來影響，特別是每次刷盤
AOF三種觸發(fā)機制
(1)每修改同步always：同步持久化 每次發(fā)送數(shù)據(jù)更變會立即被記錄到磁盤中，性能較差但是數(shù)據(jù)保存的完整性比較好
(2)每秒同步everysec：異步操作，每秒記錄，如果一秒內(nèi)宕機的話，會造成數(shù)據(jù)丟失。
(3)不同no：從不同步
AOF有何優(yōu)缺點?
優(yōu)點：
(1)AOF可以更好的對數(shù)據(jù)保護，不讓數(shù)據(jù)丟失。一般AOF會每隔一秒，通過后臺線程執(zhí)行一次fsync操作，最多丟失一秒鐘的數(shù)據(jù)
(2)AOF日志文件沒有任何磁盤尋址的開銷，寫入性能非常高，文件也不容易損壞。
(3)AOF日志文件的命令擁有很好的可讀方式進行記錄，因為這個特征非常適合做災難性的誤刪除恢復。
缺點：
(1)對于同一份數(shù)據(jù)來說的話，AOF文件的日志通常要比RDB數(shù)據(jù)快照文件要更大。
(2)AOF開啟后，支持的寫QPS會比RDB支持的寫QPS低，因為AOF一般配置成每秒fsync一次日志文件。
AOF配置實戰(zhàn)
「文件重新原理」
AOF的方式也同時帶來了另一個問題。持久化文件會變得越來越大，為了壓縮aof持久化文件。Redis提供了一個barewriteaof命令。來講內(nèi)存中的數(shù)據(jù)以命令的形式保存到臨時文件中，同時會開啟一條新進程來重寫，重寫aof文件的操作，并沒有讀取舊的aof文件，而是把整個內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令的形式重寫了一個新的aof文件，這個和快照有點類似。
重寫觸發(fā)配置
手動觸發(fā)：直接調用bgrewriteaof命令
自動觸發(fā)：auto-aof-rewrite-min-size和auto-aof-rewrite-percentage參數(shù)(auto-aof-rewrite-min-size表示AOF重寫文件最小體積，默認為64MB;auto-aof-rewrite-percentage代表AOF文件空間和上一次重寫后AOF文件空間的比值)
常用配置
- # 是否開啟aof
- appendonly yes
- # ⽂件名稱
- appendfilename "appendonly.aof"
- # 同步⽅式
- appendfsync everysec
- # aof重寫期間是否同步
- no-appendfsync-on-rewrite no
- # 重寫觸發(fā)配置
- auto-aof-rewrite-percentage 100
- auto-aof-rewrite-min-size 64mb
- # 加載aof時如果有錯如何處理
- # yes表示如果aof尾部⽂件出問題，寫log記錄并繼續(xù)執(zhí)⾏。
- no表示提示寫⼊等待修復后寫⼊
- aof-load-truncated yes
在線上，我們到底該怎么做?
(1)RDB持久化與AOF持久化起使
(2)如果Redis中的數(shù)據(jù)并不是特別敏感或者可以通過其它?式重寫?成數(shù)據(jù)
(3)集群中可以關閉AOF持久化，靠集群的備份?式保證可?性
(4)??制定策略定期檢查Redis的情況，然后可以?動觸發(fā)備份、重寫數(shù)據(jù);
(5)采?集群和主從同步
在Redis4.0后支持混合模式
RDB和AOF可以一起用了，直接將RDB持久化的方式來操作二進制內(nèi)容覆蓋到AOF文件中，因為RDB是二進制，所以很小。有寫入的話還是繼續(xù)append追加到文件的原始命令，等下次文件過大的時候在次rewrite，所以在企業(yè)中這種混合模式是比較常見的。
