1适室、配置RDB持久化機制
redis.conf文件嫡意，也就是/etc/redis/6379.conf举瑰，去配置持久化
save 60 1000
每隔60s捣辆，如果有超過1000個key發(fā)生了變更，那么就生成一個新的dump.rdb文件此迅，就是當前redis內(nèi)存中完整的數(shù)據(jù)快照汽畴，這個操作也被稱之為snapshotting旧巾，快照
也可以手動調(diào)用save或者bgsave命令，同步或異步執(zhí)行rdb快照生成
save可以設置多個忍些，就是多個snapshotting檢查點鲁猩，每到一個檢查點，就會去check一下罢坝，是否有指定的key數(shù)量發(fā)生了變更廓握，如果有，就生成一個新的dump.rdb文件
2嘁酿、RDB持久化機制的工作流程
（1）redis根據(jù)配置自己嘗試去生成rdb快照文件
（2）fork一個子進程出來
（3）子進程嘗試將數(shù)據(jù)dump到臨時的rdb快照文件中
（4）完成rdb快照文件的生成之后隙券，就替換之前的舊的快照文件
dump.rdb，每次生成一個新的快照闹司，都會覆蓋之前的老快照
3娱仔、AOF持久化的配置
AOF持久化，默認是關(guān)閉的游桩，默認是打開RDB持久化
appendonly yes牲迫，可以打開AOF持久化機制，在生產(chǎn)環(huán)境里面借卧，一般來說AOF都是要打開的盹憎，除非你說隨便丟個幾分鐘的數(shù)據(jù)也無所謂
打開AOF持久化機制之后，redis每次接收到一條寫命令铐刘，就會寫入日志文件中脚乡，當然是先寫入os cache的，然后每隔一定時間再fsync一下
而且即使AOF和RDB都開啟了滨达，redis重啟的時候奶稠，也是優(yōu)先通過AOF進行數(shù)據(jù)恢復的，因為aof數(shù)據(jù)比較完整
可以配置AOF的fsync策略捡遍，有三種策略可以選擇锌订，一種是每次寫入一條數(shù)據(jù)就執(zhí)行一次fsync; 一種是每隔一秒執(zhí)行一次fsync; 一種是不主動執(zhí)行fsync
always: 每次寫入一條數(shù)據(jù)，立即將這個數(shù)據(jù)對應的寫日志fsync到磁盤上去画株，性能非常非常差辆飘，吞吐量很低; 確保說redis里的數(shù)據(jù)一條都不丟，那就只能這樣了
mysql -> 內(nèi)存策略谓传，大量磁盤蜈项，QPS到多少，一兩k续挟。QPS紧卒，每秒鐘的請求數(shù)量
redis -> 內(nèi)存，磁盤持久化诗祸，QPS到多少跑芳，單機轴总，一般來說，上萬QPS沒問題
everysec: 每秒將os cache中的數(shù)據(jù)fsync到磁盤博个，這個最常用的怀樟，生產(chǎn)環(huán)境一般都這么配置，性能很高盆佣，QPS還是可以上萬的
no: 僅僅redis負責將數(shù)據(jù)寫入os cache就撒手不管了往堡，然后后面os自己會時不時有自己的策略將數(shù)據(jù)刷入磁盤，不可控了
4共耍、AOF rewrite
redis中的數(shù)據(jù)其實有限的投蝉，很多數(shù)據(jù)可能會自動過期，可能會被用戶刪除征堪，可能會被redis用緩存清除的算法清理掉
redis中的數(shù)據(jù)會不斷淘汰掉舊的瘩缆，就一部分常用的數(shù)據(jù)會被自動保留在redis內(nèi)存中
所以可能很多之前的已經(jīng)被清理掉的數(shù)據(jù)，對應的寫日志還停留在AOF中佃蚜，AOF日志文件就一個庸娱，會不斷的膨脹，到很大很大
所以AOF會自動在后臺每隔一定時間做rewrite操作谐算，比如日志里已經(jīng)存放了針對100w數(shù)據(jù)的寫日志了; redis內(nèi)存只剩下10萬; 基于內(nèi)存中當前的10萬數(shù)據(jù)構(gòu)建一套最新的日志熟尉，到AOF中; 覆蓋之前的老日志; 確保AOF日志文件不會過大，保持跟redis內(nèi)存數(shù)據(jù)量一致
redis 2.4之前洲脂，還需要手動斤儿，開發(fā)一些腳本，crontab恐锦，通過BGREWRITEAOF命令去執(zhí)行AOF rewrite往果，但是redis 2.4之后，會自動進行rewrite操作
在redis.conf中一铅，可以配置rewrite策略
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
比如說上一次AOF rewrite之后陕贮，是128mb
然后就會接著128mb繼續(xù)寫AOF的日志，如果發(fā)現(xiàn)增長的比例潘飘，超過了之前的100%肮之，256mb，就可能會去觸發(fā)一次rewrite
但是此時還要去跟min-size卜录，64mb去比較戈擒，256mb > 64mb，才會去觸發(fā)rewrite
（1）redis fork一個子進程
（2）子進程基于當前內(nèi)存中的數(shù)據(jù)艰毒，構(gòu)建日志筐高，開始往一個新的臨時的AOF文件中寫入日志
（3）redis主進程，接收到client新的寫操作之后，在內(nèi)存中寫入日志凯傲，同時新的日志也繼續(xù)寫入舊的AOF文件
（4）子進程寫完新的日志文件之后犬辰，redis主進程將內(nèi)存中的新日志再次追加到新的AOF文件中
（5）用新的日志文件替換掉舊的日志文件
5嗦篱、AOF破損文件的修復
如果redis在append數(shù)據(jù)到AOF文件時冰单，機器宕機了，可能會導致AOF文件破損
用redis-check-aof --fix命令來修復破損的AOF文件
6灸促、AOF和RDB同時工作
（1）如果RDB在執(zhí)行snapshotting操作诫欠，那么redis不會執(zhí)行AOF rewrite; 如果redis再執(zhí)行AOF rewrite，那么就不會執(zhí)行RDB snapshotting
（2）如果RDB在執(zhí)行snapshotting浴栽，此時用戶執(zhí)行BGREWRITEAOF命令荒叼，那么等RDB快照生成之后，才會去執(zhí)行AOF rewrite
（3）同時有RDB snapshot文件和AOF日志文件典鸡，那么redis重啟的時候被廓，會優(yōu)先使用AOF進行數(shù)據(jù)恢復，因為其中的日志更完整
