redis持久化的幾種方式
Redis是一種key-value數(shù)據(jù)庫咳短。它跟memcached類似嗅战，不過數(shù)據(jù)可以持久化贯溅，而且支持的數(shù)據(jù)類型很豐富：string（字符串）糕篇，hash（哈希）阀蒂，list（列表）该窗，set（集合）及zset(sorted set：有序集合)。支持在服務(wù)器端計算集合的并蚤霞，交和補集(difference)等酗失，還支持多種排序功能。所以Redis也可以被看成是一個數(shù)據(jù)結(jié)構(gòu)服務(wù)器争便。
Redis的所有數(shù)據(jù)都是保存在內(nèi)存中级零，然后不定期的通過異步方式保存到磁盤上(這稱為“半持久化模式”)；也可以把每一次數(shù)據(jù)變化都寫入到一個append only file(aof)里面(這稱為“全持久化模式”)。
由于Redis的數(shù)據(jù)都存放在內(nèi)存中奏纪，如果沒有配置持久化鉴嗤，redis重啟后數(shù)據(jù)就全丟失了，于是需要開啟redis的持久化功能序调，將數(shù)據(jù)保存到磁盤上醉锅，當redis重啟后，可以從磁盤中恢復(fù)數(shù)據(jù)发绢。
redis提供兩種方式進行持久化硬耍，一種是RDB持久化（原理是將Reids在內(nèi)存中的數(shù)據(jù)庫記錄定時dump到磁盤上的RDB持久化），另外一種是AOF（append only file）持久化（原理是將Reids的操作日志以追加的方式寫入文件）边酒。
二者的區(qū)別
RDB持久化是指在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤经柴，實際操作過程是fork一個子進程，先將數(shù)據(jù)集寫入臨時文件墩朦，寫入成功后坯认，再替換之前的文件，用二進制壓縮存儲氓涣。
AOF持久化以日志的形式記錄服務(wù)器所處理的每一個寫牛哺、刪除操作，查詢操作不會記錄劳吠，以文本的方式記錄引润，可以打開文件看到詳細的操作記錄。
RDB存在哪些優(yōu)勢呢痒玩？
1). 一旦采用該方式淳附，那么你的整個Redis數(shù)據(jù)庫將只包含一個文件，這對于文件備份而言是非常完美的凰荚。比如燃观，你可能打算每個小時歸檔一次最近24小時的數(shù)據(jù)褒脯，同時還要每天歸檔一次最近30天的數(shù)據(jù)。通過這樣的備份策略番川，一旦系統(tǒng)出現(xiàn)災(zāi)難性故障到涂，我們可以非常容易的進行恢復(fù)。
2). 對于災(zāi)難恢復(fù)而言颁督，RDB是非常不錯的選擇践啄。因為我們可以非常輕松的將一個單獨的文件壓縮后再轉(zhuǎn)移到其它存儲介質(zhì)上。
3). 性能最大化沉御。對于Redis的服務(wù)進程而言屿讽，在開始持久化時，它唯一需要做的只是fork出子進程，之后再由子進程完成這些持久化的工作伐谈，這樣就可以極大的避免服務(wù)進程執(zhí)行IO操作了烂完。
4). 相比于AOF機制，如果數(shù)據(jù)集很大诵棵，RDB的啟動效率會更高抠蚣。
RDB又存在哪些劣勢呢番舆？
1). 如果你想保證數(shù)據(jù)的高可用性冬骚，即最大限度的避免數(shù)據(jù)丟失，那么RDB將不是一個很好的選擇脊僚。因為系統(tǒng)一旦在定時持久化之前出現(xiàn)宕機現(xiàn)象距贷，此前沒有來得及寫入磁盤的數(shù)據(jù)都將丟失柄冲。
2). 由于RDB是通過fork子進程來協(xié)助完成數(shù)據(jù)持久化工作的，因此忠蝗，如果當數(shù)據(jù)集較大時羊初，可能會導(dǎo)致整個服務(wù)器停止服務(wù)幾百毫秒，甚至是1秒鐘什湘。
AOF的優(yōu)勢有哪些呢长赞？
1). 該機制可以帶來更高的數(shù)據(jù)安全性，即數(shù)據(jù)持久性闽撤。Redis中提供了3中同步策略得哆，即每秒同步、每修改同步和不同步哟旗。事實上贩据，每秒同步也是異步完成的，其效率也是非常高的闸餐，所差的是一旦系統(tǒng)出現(xiàn)宕機現(xiàn)象饱亮，那么這一秒鐘之內(nèi)修改的數(shù)據(jù)將會丟失。而每修改同步舍沙，我們可以將其視為同步持久化近上，即每次發(fā)生的數(shù)據(jù)變化都會被立即記錄到磁盤中》髡。可以預(yù)見壹无，這種方式在效率上是最低的。至于無同步感帅，無需多言斗锭，我想大家都能正確的理解它。
2). 由于該機制對日志文件的寫入操作采用的是append模式失球，因此在寫入過程中即使出現(xiàn)宕機現(xiàn)象岖是，也不會破壞日志文件中已經(jīng)存在的內(nèi)容。然而如果我們本次操作只是寫入了一半數(shù)據(jù)就出現(xiàn)了系統(tǒng)崩潰問題，不用擔(dān)心豺撑，在Redis下一次啟動之前作箍，我們可以通過redis-check-aof工具來幫助我們解決數(shù)據(jù)一致性的問題。
3). 如果日志過大前硫，Redis可以自動啟用rewrite機制胞得。即Redis以append模式不斷的將修改數(shù)據(jù)寫入到老的磁盤文件中，同時Redis還會創(chuàng)建一個新的文件用于記錄此期間有哪些修改命令被執(zhí)行屹电。因此在進行rewrite切換時可以更好的保證數(shù)據(jù)安全性阶剑。
4). AOF包含一個格式清晰、易于理解的日志文件用于記錄所有的修改操作危号。事實上牧愁，我們也可以通過該文件完成數(shù)據(jù)的重建。
AOF的劣勢有哪些呢外莲？
1). 對于相同數(shù)量的數(shù)據(jù)集而言猪半，AOF文件通常要大于RDB文件。RDB 在恢復(fù)大數(shù)據(jù)集時的速度比 AOF 的恢復(fù)速度要快偷线。
2). 根據(jù)同步策略的不同磨确，AOF在運行效率上往往會慢于RDB∩睿總之乏奥，每秒同步策略的效率是比較高的，同步禁用策略的效率和RDB一樣高效亥曹。
二者選擇的標準邓了，就是看系統(tǒng)是愿意犧牲一些性能，換取更高的緩存一致性（aof）媳瞪，還是愿意寫操作頻繁的時候骗炉，不啟用備份來換取更高的性能，待手動運行save的時候蛇受，再做備份（rdb）句葵。rdb這個就更有些 eventually consistent的意思了。
常用配置
RDB持久化配置
Redis會將數(shù)據(jù)集的快照dump到dump.rdb文件中龙巨。此外笼呆，我們也可以通過配置文件來修改Redis服務(wù)器dump快照的頻率，在打開6379.conf文件之后旨别，我們搜索save，可以看到下面的配置信息：
save 900 1 #在900秒(15分鐘)之后汗茄，如果至少有1個key發(fā)生變化秸弛，則dump內(nèi)存快照。
save 300 10 #在300秒(5分鐘)之后，如果至少有10個key發(fā)生變化递览，則dump內(nèi)存快照叼屠。
save 60 10000 #在60秒(1分鐘)之后，如果至少有10000個key發(fā)生變化绞铃，則dump內(nèi)存快照镜雨。
AOF持久化配置
在Redis的配置文件中存在三種同步方式，它們分別是：
appendfsync always #每次有數(shù)據(jù)修改發(fā)生時都會寫入AOF文件儿捧。
appendfsync everysec #每秒鐘同步一次荚坞，該策略為AOF的缺省策略。
appendfsync no #從不同步菲盾。高效但是數(shù)據(jù)不會被持久化颓影。
