快問快答！
之前圖解了兩篇 Redis 持久化技術，分別是：
有些讀者在評論區(qū)里提了一些問題，然后這些問題是他們自己延伸想出來的，我覺得問題具有代表性，就在這篇回答下這些問題。
AOF 日志篇的問題
問題一
這位讀者的意思是，他認為 Redis 是單線程的，但是他在文章里看到 Redis 在 AOF 重寫日志的時候，會創(chuàng)建子進程來重寫日志，他就覺得不對勁。
Redis 確實是以單線程架構被大家所知，但是這個單線程指的是「從網(wǎng)絡 IO 處理到實際的讀寫命令處理」都是由單個線程完成的，并不是說整個 Redis 里只有一個主線程。
有些命令操作可以用后臺子進程執(zhí)行（比如快照生成、AOF 重寫）。
嚴格意義上說的話，Redis 4.0 之后并不是單線程架構了，除了主線程外，它也有后臺線程在處理一些耗時比較長的操作，例如清理臟數(shù)據(jù)、無用連接的釋放、大 Key 的刪除等等。
你可能聽到 Redis 6.0 版本支持了多線程技術，不過這個并不是指多個線程同時在處理讀寫命令，而是使用多線程來處理 Socket 的讀寫，最終執(zhí)行讀寫命令的過程還是只在主線程里。
之所以采用多線程 IO 是因為Redis 處理請求時，網(wǎng)絡處理經(jīng)常是瓶頸，通過多個 IO 線程并行處理網(wǎng)絡操作，可以提升整體處理性能。
那為什么處理操作命令的過程只在單線程里呢？
因為 Redis 不存在 CPU 成為瓶頸的情況，主要受限于內存和網(wǎng)絡。
而且使用單線程的好處在于，可維護性高、實現(xiàn)簡單。
如果采用多線程模型來處理讀寫命令，雖然能提升并發(fā)性能，但是它卻引入了程序執(zhí)行順序的不確定性，帶來了并發(fā)讀寫的一系列問題，增加了系統(tǒng)復雜度、同時可能存在線程切換、甚至加鎖解鎖、死鎖造成的性能損耗。
關于 Redis 單線程的問題就介紹這么多，后續(xù)在寫一篇詳細點的文章。
問題二
這個讀者的意思是，AOF 重寫緩沖區(qū)占滿了會發(fā)生什么？
其實重寫緩沖區(qū)并不是一個很大塊的內存空間，而是一些內存塊的鏈表，每個內存塊的大小為 10MB，這樣就組成了一個重寫緩沖區(qū)。
AOF 重寫緩沖區(qū)塊的數(shù)據(jù)結構如下：
細心的同學可能發(fā)現(xiàn)，aofrwblock 結構里沒有 prev 和 next 指針呀，那怎么組成鏈表的呢？
Redis 是這樣做的，用 listNode 結構包裹著 aofrwblock 結構，會將 listNode 結構里的 value 指針指向 aofrwblock。
接下來，我們看看 Redis 是如何使用申請和使用 aofrwblock 結構的。
下面這個函數(shù)，就是將操作命令追加到 AOF 重寫緩沖區(qū)的實現(xiàn)：
可以看到，當一個內存塊 10MB 大小用完后，就會通過 zmalloc() 在申請一個內存塊，并將其追加到鏈表的末尾。
如果遇到系統(tǒng)內存緊張，導致申請內存失敗時會發(fā)生什么呢？
我們直接看下 zmalloc() 的實現(xiàn)：
可以看到，當 zmalloc() 申請內存失敗的時候，就會打印一條日志，并調用 abort() 終止 Redis 進程。
現(xiàn)在就可以回答讀者的問題了，重寫緩沖區(qū)占滿了會發(fā)生什么？
重寫緩沖區(qū)是邊用邊申請的，也就是說是動態(tài)申請的，并不是一次性就分配好的。
如果一直分配內存，當耗盡系統(tǒng)的內存資源的時候，zmalloc() 就無法申請成功，就會打印一條日志，隨后就 Redis 進程就退出了。
RDB 日志篇的問題
問題一
這位讀者的意思是，為什么執(zhí)行 bgsave 命令來生成快照文件的時候，是創(chuàng)建子進程而不是線程。
AOF 重寫日志和 bgsave 快照生成都是通過創(chuàng)建子進程來負責的，這里使用子進程而不是線程，是因為如果是使用線程，多線程之間會共享內存，那么在修改共享內存數(shù)據(jù)的時候，需要通過加鎖來保證數(shù)據(jù)的安全，而這樣就會降低性能。
而使用子進程，創(chuàng)建子進程時，父子進程是共享內存數(shù)據(jù)的，不過這個共享的內存只能以只讀的方式，而當父子進程任意一方修改了該共享內存，就會發(fā)生「寫時復制」，于是父子進程就有了各自獨立的數(shù)據(jù)副本，就不用加鎖來保證數(shù)據(jù)安全，減少了鎖的開銷和避免死鎖的發(fā)生。
問二
bgsave 和 save 的區(qū)別就在于：
bgsave 會使用 fork() 系統(tǒng)調用創(chuàng)建子進程，創(chuàng)建快照的工作在子進程里；
save 不會創(chuàng)建子進程，創(chuàng)建快照的工作在主線程里。
創(chuàng)建子進程時，有兩個階段會導致阻塞父進程：
創(chuàng)建子進程的途中，由于要復制父進程的頁表等數(shù)據(jù)結構，阻塞的時間跟頁表的大小有關，頁表越大，阻塞的時間也越長；
創(chuàng)建完子進程后，如果子進程或者父進程修改了共享數(shù)據(jù)，就會發(fā)生寫時復制，這期間會拷貝物理內存，如果內存越大，自然阻塞的時間也越長；
那么當 Redis 內存數(shù)據(jù)高達幾十 G，甚至上百 G 的時候，如果用 bgsave 進行 RDB 快照的話，在創(chuàng)建子進程的時候，會因為復制太大的頁表而導致 Redis 阻塞在 fork() 函數(shù)，主線程無法繼續(xù)執(zhí)行，相當于停頓了。
所以針對這種情況建議用 sava。
雖然 save 會一直阻塞 Redis 直到快照生成完畢，但是它這個阻塞并不是意味著停頓了，而是在執(zhí)行生成快照的程序，只是期間主線程無法處理接下來的讀寫命令。
并且因為不需要創(chuàng)建子進程，所以不會像 bgsave 一樣因為創(chuàng)建子進程而導致 Redis 停頓，并且因為沒有子進程在爭搶資源，所以 sava 創(chuàng)建快照的速度比 bgsave 創(chuàng)建快照的速度要快一些。
問題三
這兩個看一下源碼就知道了呀。
先看回答第一個問題，我們直接看 Redis 加載 AOF 文件函數(shù)實現(xiàn)：
打開 AOF 文件之后，首先讀取 5 個字符如果是「REDIS」，那么就說明這是一個混合持久化的 AOF 文件，因為 RDB 格式一定是以「REDIS」開頭，而純 AOF 格式則一定以「*」開頭。
所以如果開頭的 5 個字符是 「REDIS」 會先進入 rdbLoadRio() 函數(shù)來加載 RDB 內容。
rdbLoadRio() 函數(shù)就不詳細展開了，就是按約定好的格式解析文件內容直到遇到 RDB_OPCODE_EOF 結束標記后返回。
接著 loadAppendOnlyFile() 函數(shù)繼續(xù)以 AOF 格式解析文件直到結束整個加載過程完成。
再來看第二個問題，是通過什么方法將內存寫入文件的？
很簡單的，就是通過大家都知道的 write() 系統(tǒng)調用將內存數(shù)據(jù)寫入到文件呀。
好了，這次就暫時回答這么多問題了。
你們覺得小林答的夠詳細嗎？
覺得不錯的，給小林個三連呀！
我們下次見啦～