13原理3未雨綢繆持久化天下無(wú)魚(yú)

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