- 持久化的思路
無論mysql還是redis持久化思路大致兩個(gè)方案:
1.快照
2.日志
Linux 系統(tǒng)默認(rèn)進(jìn)程間數(shù)據(jù)隔離,但是父進(jìn)程可以讓子進(jìn)程看見父進(jìn)程的變量
創(chuàng)建子進(jìn)程:
1.創(chuàng)建子進(jìn)程的速度
2.創(chuàng)建子進(jìn)程需要復(fù)制父進(jìn)程的變量,內(nèi)存是否夠
- fork()
1.速度相對快
2.占用空間相對下
3.copyonwrite
- redis 非阻塞對外提供服務(wù)的情況下如何做數(shù)據(jù)RDB?
image.png
image.png
image.png
- RDB
優(yōu)點(diǎn):
節(jié)省空間
恢復(fù)數(shù)據(jù)速度快
缺點(diǎn):
數(shù)據(jù)丟失
- AOF
redis寫操作記錄追加到文件中
- 優(yōu)點(diǎn)
丟失數(shù)據(jù)少
可與RDB同時(shí)開啟,AOF開啟時(shí)只會以AOF進(jìn)行恢復(fù)數(shù)據(jù)
4.0版本后將AOF中包RDB全量+AOF增量
- 缺點(diǎn)
占用空間大
恢復(fù)數(shù)據(jù)速度慢
- AOF做了那些優(yōu)化
4.0前合并/抵消寫日志
4.0后重寫后RDB+AOF增量
開啟AOF后,redis增刪改等寫操作將觸發(fā)IO,當(dāng)寫操作過多時(shí)影響redis相應(yīng)時(shí)間
appendfsync always：總是寫入aof文件萝嘁，并完成磁盤同步
appendfsync everysec：每一秒寫入aof文件撩扒，并完成磁盤同步
appendfsync no：寫入aof文件链瓦，不等待磁盤同步。
可見气筋，從持久化角度講，always是最安全的旋圆。從效率上講宠默，no是最快的。而redis默認(rèn)設(shè)置進(jìn)行了折中灵巧，選擇了everysec搀矫。合情合理。
bgrewriteaof機(jī)制刻肄，在一個(gè)子進(jìn)程中進(jìn)行aof的重寫瓤球，從而不阻塞主進(jìn)程對其余命令的處理，同時(shí)解決了aof文件過大問題敏弃。
現(xiàn)在問題出現(xiàn)了卦羡，同時(shí)在執(zhí)行bgrewriteaof操作和主進(jìn)程寫aof文件的操作，兩者都會操作磁盤麦到，而bgrewriteaof往往會涉及大量磁盤操作绿饵，這樣就會造成主進(jìn)程在寫aof文件的時(shí)候出現(xiàn)阻塞的情形，現(xiàn)在no-appendfsync-on-rewrite參數(shù)出場了瓶颠。如果該參數(shù)設(shè)置為no拟赊，是最安全的方式，不會丟失數(shù)據(jù)粹淋，但是要忍受阻塞的問題要门。如果設(shè)置為yes呢虏肾？這就相當(dāng)于將appendfsync設(shè)置為no，這說明并沒有執(zhí)行磁盤操作欢搜，只是寫入了緩沖區(qū)封豪，因此這樣并不會造成阻塞（因?yàn)闆]有競爭磁盤），但是如果這個(gè)時(shí)候redis掛掉炒瘟，就會丟失數(shù)據(jù)吹埠。丟失多少數(shù)據(jù)呢？在linux的操作系統(tǒng)的默認(rèn)設(shè)置下疮装，最多會丟失30s的數(shù)據(jù)缘琅。
因此，如果應(yīng)用系統(tǒng)無法忍受延遲廓推，而可以容忍少量的數(shù)據(jù)丟失刷袍，則設(shè)置為yes。如果應(yīng)用系統(tǒng)無法忍受數(shù)據(jù)丟失樊展，則設(shè)置為no呻纹。
