RDB：
有save和bgsave兩種方式
- save:會(huì)使redis處于阻塞狀態(tài),直到RDB完成,才會(huì)繼續(xù)響應(yīng)其它的命令.對(duì)redis性能影響非常大.
- bgsave:在時(shí)間間隔內(nèi)fork?個(gè)?進(jìn)程將內(nèi)存中的數(shù)據(jù)集快照寫?磁盤朽缴，先將數(shù)據(jù)集寫?臨時(shí)?件钳恕，寫?成功后卸察，再替換之前的?件，用二進(jìn)制壓縮存儲(chǔ)。redis只會(huì)在fork一個(gè)子進(jìn)程的時(shí)候占用一點(diǎn)點(diǎn)時(shí)間.
RDB優(yōu)點(diǎn):
- 整個(gè)Redis數(shù)據(jù)庫(kù)將只包含?個(gè)文件 dump.rdb,還是經(jīng)過壓縮的二進(jìn)制文件，占用空間很小，方便持久化讼积。
- 保存了 Redis 某個(gè)時(shí)間點(diǎn)的數(shù)據(jù)集，很適合用于做備份脚仔。
- 性能最大化勤众，子進(jìn)程來(lái)進(jìn)行持久化，主進(jìn)程不會(huì)進(jìn)?任何 IO 操作鲤脏，保證了 redis 的高性能 .
- 相對(duì)于數(shù)據(jù)集?時(shí)们颜，比AOF 的啟動(dòng)效率更高。
RDB缺點(diǎn)：
數(shù)據(jù)安全性低猎醇。如果持久化的時(shí)候redis 發(fā)生故障窥突，會(huì)丟失最后一次持久化的數(shù)據(jù),所以這種方式更適合數(shù)據(jù)要求不高的時(shí)候.
fock子進(jìn)程過程中redis也是不能執(zhí)行操作的,所以進(jìn)行RDB操作的時(shí)間間隔一定不能太短.而且,如果當(dāng)數(shù)據(jù)集較大時(shí)，也可能會(huì)導(dǎo)致整個(gè)服務(wù)器停止服務(wù)?百毫秒硫嘶，甚至是秒級(jí)阻问。
AOF：
以日志的形式記錄服務(wù)器所處理的每?個(gè)寫、刪除操作沦疾，查詢操作不會(huì)記錄称近，以文本的方式記錄，不斷追加,可以打開?件看到詳細(xì)的操作記錄 .
三種追加方式(fsync):
- everysec :每秒同步:異步完成,先將操作寫入一個(gè)緩存,每秒從緩存同步到磁盤一次,效率高,但是可能丟失數(shù)據(jù).
- always:每修改同步:每一次發(fā)生增刪改都記錄操作.數(shù)據(jù)安全性高,最多丟失一個(gè)操作.
- no:不同步,把操作寫入緩存,由操作系統(tǒng)來(lái)決定什么時(shí)候?qū)懭氪疟P.
AOF優(yōu)點(diǎn)：
- AOF 比 RDB可靠哮塞。你可以設(shè)置不同的 fsync 策略：no刨秆、everysec 和 always。默認(rèn)是 everysec彻桃，在這種配置下坛善，redis 仍然可以保持良好的性能晾蜘，并且就算發(fā)生故障停機(jī)邻眷，也最多只會(huì)丟失一秒鐘的數(shù)據(jù)眠屎。
- 通過 append 模式寫件，即使日志因?yàn)槟承┰蚨宋磳懭胪暾拿睿ū热鐚懭霑r(shí)磁盤已滿肆饶，寫入中途停機(jī)等等）改衩，可以通過 redis-check-aof 工具修復(fù)這個(gè)問題。
- AOF 機(jī)制的 rewrite 模式驯镊。定期對(duì)AOF文件進(jìn)行重寫葫督，以達(dá)到壓縮的目的(比如有先有一個(gè)set age 21,后面又有一個(gè)set age 22,則前面哪個(gè)set重寫后會(huì)被清楚).
AOF缺點(diǎn)：
- 相同的數(shù)據(jù)集，AOF 文件的大小一般會(huì)比 RDB 文件大板惑，且恢復(fù)速度慢橄镜。
- 數(shù)據(jù)集?的時(shí)候，比rdb 啟動(dòng)效率低冯乘。
- 運(yùn)行效率沒有RDB高,AOF文件比RDB更新頻率高洽胶，
總結(jié)：優(yōu)先使用AOF還原數(shù)據(jù)，AOF比RDB更安全也更大裆馒，RDB性能比AOF好姊氓， 如果兩個(gè)都配了優(yōu)先加載AOF。
