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

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