13原理3未雨綢繆持久化天下無魚

原理3：未?綢繆——Redis的數(shù)據(jù)全部在內(nèi)存?，如果突然宕機(jī)，數(shù)據(jù)就會全部丟失，因此必須有?種機(jī)制來保證Redis的數(shù)據(jù)不會因?yàn)楣收?丟失，這種機(jī)制就是Redis的持久化機(jī)制。Redis的持久化機(jī)制有兩種，第?種是快照，第?種是AOF?志?？煺帐?次全量備份，AOF?志是連續(xù)的增量備份?？煺帐莾?nèi)存數(shù)據(jù)的?進(jìn)制序列化形式，在上?常緊湊，?AOF?志記錄的是內(nèi)存數(shù)據(jù)修改的指令記錄?本。AOF?志在?期的運(yùn)?過程中會變的??龐?，數(shù)據(jù)庫重啟時需要加載AOF?志進(jìn)?指令重放，這個時間就會??漫?。所以需要定期進(jìn)?AOF重寫，給AOF?志進(jìn)Redis是單線程程序，這個線程要同時負(fù)責(zé)多個客戶端套在服務(wù)線上請求的同時，Redis還需要進(jìn)?內(nèi)存快照，內(nèi)存快照要求Redis必須進(jìn)??件IO操作，可?件IO操作是不能使?多路復(fù)?這意味著單線程同時在服務(wù)線上的請求還要進(jìn)??件IO操作，?件IO操作會嚴(yán)重拖垮服務(wù)器請求的性能。還有個重要的問題是為了不時，內(nèi)存數(shù)據(jù)結(jié)構(gòu)還在改變，?如?個?型的hash字典正在持久Redis使?操作系統(tǒng)的多進(jìn)程COW(CopyOnWrite)機(jī)制來實(shí)現(xiàn)快照持久化，這個機(jī)制很有意思，也很少?知道。多進(jìn)程COW也是鑒Redis在持久化時會調(diào)?glibc的函數(shù)fork產(chǎn)??個?進(jìn)程，快照以將??進(jìn)程想像成?個連體嬰?，共享身體。這是Linux操作系?Python語?描述進(jìn)程分離的邏輯如下。fork函數(shù)會在??進(jìn)程pid，在?進(jìn)程?返回零。如果操作系統(tǒng)內(nèi)存資源不?，pid就會是負(fù)數(shù)，表示fork失敗。pidpid=os.fork()ifpid>0:ifpid==_requests()handle_snapshot_write()ifpid<#fork 這個時候就會使?操作系統(tǒng)的COW機(jī)制來進(jìn)?數(shù)據(jù)段??的分離。的數(shù)據(jù)進(jìn)?修改時，會將被共享的???份分離出來，然后對這個的??進(jìn)?修改。這時?進(jìn)程相應(yīng)的??是沒有變化的，還是內(nèi)存就會持續(xù)增?。但是也不會超過原有數(shù)據(jù)內(nèi)存的2倍??。另外?個Redis實(shí)例?冷數(shù)據(jù)占的?例往往是?較?的，所以很少會個??的??只有4K，?個Redis瞬間就凝固了，再也不會改變，這也是為什么Redis的持久化叫 AOFAOF?志的是Redis服務(wù)器的順序指令序列，AOF?志只記錄假設(shè)AOF?志記錄了?Redis實(shí)例創(chuàng)建以來所有的修改性指令序列，那么就可以通過對?個空的Redis實(shí)例順序執(zhí)?所有的指令，也就是「重放」，來恢復(fù)Redis當(dāng)前實(shí)例的內(nèi)存數(shù)據(jù)結(jié)構(gòu)的狀態(tài)。Redis會在收到客戶端修改指令后，進(jìn)?參數(shù)校驗(yàn)進(jìn)?邏輯處理后， 到AOF?志中，也就是先執(zhí) Redis在?期運(yùn)?的過程中，AOF的?志會越變越?。如果實(shí)例宕機(jī)重啟，重放整個AOF?志會?常耗時，導(dǎo)致?時間Redis?法對外提供服務(wù)。所以需要對AOF?志瘦身。AOFRedis提供了bgrewriteaof指令?于對AOF? 理就是開辟?個?進(jìn)程對內(nèi)存進(jìn)?遍歷轉(zhuǎn)換成?系列Redis的操作指令，序列化到?個新的AOF?志?件中。序列化完畢后再將操作期間發(fā)?的增量AOF?志追加到這個新的AOF?志?件中，追加完畢后就?即替代舊的AOF?志?件了，瘦身?作就完成了。AOF?志是以?件的形式存在的，當(dāng)程序?qū)OF?志?件進(jìn)?寫操這就意味著如果機(jī)器突然宕機(jī)，AOF?志內(nèi)容可能還沒有來得及完Linux的glibc提供了fsync(intfd)函數(shù)可以將指定?件的內(nèi)容強(qiáng)制從內(nèi)核緩存刷到磁盤。只要Redis進(jìn)程實(shí)時調(diào)?fsync函數(shù)就可以保證aof?志不丟失。但是fsync是?個磁盤IO操作，它很慢！如果Redis執(zhí)??條指令就要fsync?次，那么Redis?性能所以在?產(chǎn)環(huán)境的服務(wù)器中，Redis通常是每隔1s左右執(zhí)??次fsync1s是可以配置的。這是在數(shù)據(jù)安全性和性能之間Redis同樣也提供了另外兩種策略，?個是永不fsync——讓操作系統(tǒng)來決定何時同步磁盤，很不安全，另?個是來?個指令就fsync?次——AOF的fsync是?個耗時的IO操作，它會降低Redis性能，同時也會增加系統(tǒng)IO負(fù)擔(dān)所以通常Redis的主節(jié)點(diǎn)是不會進(jìn)?持久化操作，持久化操作主要Redis4.0重啟Redis時，很少使?rdb來恢復(fù)內(nèi)存狀態(tài)，因?yàn)闀G失?量數(shù)據(jù)。通常使?AOF?志重放，但是重放AOF?志性能相對rdb來說要慢很多，這樣在Redis實(shí)例很?的情況下，啟動需要Redis4.0為了解決這個問題，帶來了?個新的持久化選項(xiàng)——混合持久化。將rdb?件的內(nèi)容和增量的AOF?志?件存在?起。這?的AOF?志不再是全量的?志，?是?持久化開始到持久化結(jié)束的這段時間發(fā)?的增量AOF?志，通常這部分AOF?志很?。于是在Redis重啟