2021年最新Redis面試題匯總(2)

更新時間：2021年07月15日 17:31:08 作者：java李楊勇

在程序員面試過程中redis相關(guān)的知識是常被問到的話題。這篇文章主要介紹了幾道Redis面試題，整理一下分享給大家，感興趣的小伙伴們可以參考一下

1、漸進式 rehash 的優(yōu)點
2、rehash 流程在數(shù)據(jù)量大的時候會有什么問題嗎（Hash 對象的擴容流程在數(shù)據(jù)量大的時候會有什么問題嗎）
3、Redis 的網(wǎng)絡(luò)事件處理器（Reactor 模式）
4、Redis 刪除過期鍵的策略（緩存失效策略、數(shù)據(jù)過期策略）
5、Redis 的內(nèi)存淘汰（驅(qū)逐）策略
6、Redis 的 LRU 算法怎么實現(xiàn)的？
7、Redis 的持久化機制有哪幾種，各自的實現(xiàn)原理和優(yōu)缺點？

1）RDB
2）AOF

8、為什么需要 AOF 重寫

9、介紹下 AOF 重寫的過程、AOF 后臺重寫存在的問題、如何解決 AOF 后臺重寫存在的數(shù)據(jù)不一致問題

10、RDB、AOF、混合持久，我應(yīng)該用哪一個？

11、同時開啟RDB和AOF，服務(wù)重啟時如何加載

總結(jié)

1、漸進式 rehash 的優(yōu)點

漸進式 rehash 的好處在于它采取分而治之的方式，將 rehash 鍵值對所需的計算工作均攤到對字典的每個添加、刪除、查找和更新操作上，從而避免了集中式 rehash 而帶來的龐大計算量。

在進行漸進式 rehash 的過程中，字典會同時使用 ht[0] 和 ht[1] 兩個哈希表，所以在漸進式 rehash 進行期間，字典的刪除、査找、更新等操作會在兩個哈希表上進行。例如，要在字典里面査找一個鍵的話，程序會先在 ht[0] 里面進行査找，如果沒找到的話，就會繼續(xù)到 ht[1] 里面進行査找，諸如此類。

另外，在漸進式 rehash 執(zhí)行期間，新增的鍵值對會被直接保存到 ht[1], ht[0] 不再進行任何添加操作，這樣就保證了 ht[0] 包含的鍵值對數(shù)量會只減不增，并隨著 rehash 操作的執(zhí)行而最終變成空表。

2、rehash 流程在數(shù)據(jù)量大的時候會有什么問題嗎（Hash 對象的擴容流程在數(shù)據(jù)量大的時候會有什么問題嗎）

1）擴容期開始時，會先給 ht[1] 申請空間，所以在整個擴容期間，會同時存在 ht[0] 和 ht[1]，會占用額外的空間。

2）擴容期間同時存在 ht[0] 和 ht[1]，查找、刪除、更新等操作有概率需要操作兩張表，耗時會增加。

3）redis 在內(nèi)存使用接近 maxmemory 并且有設(shè)置驅(qū)逐策略的情況下，出現(xiàn) rehash 會使得內(nèi)存占用超過 maxmemory，觸發(fā)驅(qū)逐淘汰操作，導(dǎo)致 master/slave 均有有大量的 key 被驅(qū)逐淘汰，從而出現(xiàn) master/slave 主從不一致。

3、Redis 的網(wǎng)絡(luò)事件處理器（Reactor 模式）

redis 基于 reactor 模式開發(fā)了自己的網(wǎng)絡(luò)事件處理器，由4個部分組成：套接字、I/O 多路復(fù)用程序、文件事件分派器（dispatcher）、以及事件處理器。

套接字：socket 連接，也就是客戶端連接。當(dāng)一個套接字準(zhǔn)備好執(zhí)行連接、寫入、讀取、關(guān)閉等操作時，就會產(chǎn)生一個相應(yīng)的文件事件。因為一個服務(wù)器通常會連接多個套接字，所以多個文件事件有可能會并發(fā)地出現(xiàn)。

I/O 多路復(fù)用程序：提供 select、epoll、evport、kqueue 的實現(xiàn)，會根據(jù)當(dāng)前系統(tǒng)自動選擇最佳的方式。負責(zé)監(jiān)聽多個套接字，當(dāng)套接字產(chǎn)生事件時，會向文件事件分派器傳送那些產(chǎn)生了事件的套接字。當(dāng)多個文件事件并發(fā)出現(xiàn)時， I/O 多路復(fù)用程序會將所有產(chǎn)生事件的套接字都放到一個隊列里面，然后通過這個隊列，以有序、同步、每次一個套接字的方式向文件事件分派器傳送套接字：當(dāng)上一個套接字產(chǎn)生的事件被處理完畢之后，才會繼續(xù)傳送下一個套接字。

文件事件分派器：接收 I/O 多路復(fù)用程序傳來的套接字，并根據(jù)套接字產(chǎn)生的事件的類型，調(diào)用相應(yīng)的事件處理器。

事件處理器：事件處理器就是一個個函數(shù)，定義了某個事件發(fā)生時，服務(wù)器應(yīng)該執(zhí)行的動作。例如：建立連接、命令查詢、命令寫入、連接關(guān)閉等等。

4、Redis 刪除過期鍵的策略（緩存失效策略、數(shù)據(jù)過期策略）

定時刪除：在設(shè)置鍵的過期時間的同時，創(chuàng)建一個定時器，讓定時器在鍵的過期時間來臨時，立即執(zhí)行對鍵的刪除操作。對內(nèi)存最友好，對 CPU 時間最不友好。

惰性刪除：放任鍵過期不管，但是每次獲取鍵時，都檢査鍵是否過期，如果過期的話，就刪除該鍵；如果沒有過期，就返回該鍵。對 CPU 時間最優(yōu)化，對內(nèi)存最不友好。

定期刪除：每隔一段時間，默認100ms，程序就對數(shù)據(jù)庫進行一次檢査，刪除里面的過期鍵。至于要刪除多少過期鍵，以及要檢査多少個數(shù)據(jù)庫，則由算法決定。前兩種策略的折中，對 CPU 時間和內(nèi)存的友好程度較平衡。

Redis 使用惰性刪除和定期刪除。

5、Redis 的內(nèi)存淘汰（驅(qū)逐）策略

當(dāng) redis 的內(nèi)存空間（maxmemory 參數(shù)配置）已經(jīng)用滿時，redis 將根據(jù)配置的驅(qū)逐策略（maxmemory-policy 參數(shù)配置），進行相應(yīng)的動作。

網(wǎng)上很多資料都是寫 6 種，但是其實當(dāng)前 redis 的淘汰策略已經(jīng)有 8 種了，多余的兩種是 Redis 4.0 新增的，基于 LFU（Least Frequently Used）算法實現(xiàn)的。

noeviction：默認策略，不淘汰任何 key，直接返回錯誤
allkeys-lru：在所有的 key 中，使用 LRU 算法淘汰部分 key
allkeys-lfu：在所有的 key 中，使用 LFU 算法淘汰部分 key，該算法于 Redis 4.0 新增
allkeys-random：在所有的 key 中，隨機淘汰部分 key
volatile-lru：在設(shè)置了過期時間的 key 中，使用 LRU 算法淘汰部分 key
volatile-lfu：在設(shè)置了過期時間的 key 中，使用 LFU 算法淘汰部分 key，該算法于 Redis 4.0 新增
volatile-random：在設(shè)置了過期時間的 key 中，隨機淘汰部分 key
volatile-ttl：在設(shè)置了過期時間的 key 中，挑選 TTL（time to live，剩余時間）短的 key 淘汰

6、Redis 的 LRU 算法怎么實現(xiàn)的？

Redis 在 redisObject 結(jié)構(gòu)體中定義了一個長度 24 bit 的 unsigned 類型的字段（unsigned lru:LRU_BITS），在 LRU 算法中用來存儲對象最后一次被命令程序訪問的時間。

具體的 LRU 算法經(jīng)歷了兩個版本。

版本1：隨機選取 N 個淘汰法。

最初 Redis 是這樣實現(xiàn)的：隨機選 N（默認5）個 key，把空閑時間（idle time）最大的那個 key 移除。這邊的 N 可通過 maxmemory-samples 配置項修改。

就是這么簡單，簡單得讓人不敢相信了，而且十分有效。

但是這個算法有個明顯的缺點：每次都是隨機從 N 個里選擇 1 個，并沒有利用前一輪的歷史信息。其實在上一輪移除 key 的過程中，其實是知道了 N 個 key 的 idle time 的情況的，那在下一輪移除 key 時，其實可以利用上一輪的這些信息。這也是 Redis 3.0 的優(yōu)化思想。

版本2：Redis 3.0 對 LRU 算法進行改進，引入了緩沖池（pool，默認16）的概念。

當(dāng)每一輪移除 key 時，拿到了 N（默認5）個 key 的 idle time，遍歷處理這 N 個 key，如果 key 的 idle time 比 pool 里面的 key 的 idle time 還要大，就把它添加到 pool 里面去。

當(dāng) pool 放滿之后，每次如果有新的 key 需要放入，需要將 pool 中 idle time 最小的一個 key 移除。這樣相當(dāng)于 pool 里面始終維護著還未被淘汰的 idle time 最大的 16 個 key。

當(dāng)我們每輪要淘汰的時候，直接從 pool 里面取出 idle time 最大的 key（只取1個），將之淘汰掉。

整個流程相當(dāng)于隨機取 5 個 key 放入 pool，然后淘汰 pool 中空閑時間最大的 key，然后再隨機取 5 個 key放入 pool，繼續(xù)淘汰 pool 中空閑時間最大的 key，一直持續(xù)下去。

在進入淘汰前會計算出需要釋放的內(nèi)存大小，然后就一直循環(huán)上述流程，直至釋放足夠的內(nèi)存。

7、Redis 的持久化機制有哪幾種，各自的實現(xiàn)原理和優(yōu)缺點？

Redis 的持久化機制有：RDB、AOF、混合持久化（RDB+AOF，Redis 4.0引入）。

1）RDB

描述：類似于快照。在某個時間點，將 Redis 在內(nèi)存中的數(shù)據(jù)庫狀態(tài)（數(shù)據(jù)庫的鍵值對等信息）保存到磁盤里面。RDB 持久化功能生成的 RDB 文件是經(jīng)過壓縮的二進制文件。

命令：有兩個 Redis 命令可以用于生成 RDB 文件，一個是 SAVE，另一個是 BGSAVE。

開啟：使用 save point 配置，滿足 save point 條件后會觸發(fā) BGSAVE 來存儲一次快照，這邊的 save point 檢查就是在上文提到的 serverCron 中進行。

save point 格式：save <seconds> <changes>，含義是 Redis 如果在 seconds 秒內(nèi)數(shù)據(jù)發(fā)生了 changes 次改變，就保存快照文件。例如 Redis 默認就配置了以下3個：

save 900 1 #900秒內(nèi)有1個key發(fā)生了變化，則觸發(fā)保存RDB文件 save 300 10 #300秒內(nèi)有10個key發(fā)生了變化，則觸發(fā)保存RDB文件 save 60 10000 #60秒內(nèi)有10000個key發(fā)生了變化，則觸發(fā)保存RDB文件

關(guān)閉：1）注釋掉所有save point 配置可以關(guān)閉 RDB 持久化。2）在所有 save point 配置后增加：save ""，該配置可以刪除所有之前配置的 save point。

save ""

SAVE：生成 RDB 快照文件，但是會阻塞主進程，服務(wù)器將無法處理客戶端發(fā)來的命令請求，所以通常不會直接使用該命令。

BGSAVE：fork 子進程來生成 RDB 快照文件，阻塞只會發(fā)生在 fork 子進程的時候，之后主進程可以正常處理請求，詳細過程如下圖：

fork：在 Linux 系統(tǒng)中，調(diào)用 fork() 時，會創(chuàng)建出一個新進程，稱為子進程，子進程會拷貝父進程的 page table。如果進程占用的內(nèi)存越大，進程的 page table 也會越大，那么 fork 也會占用更多的時間。如果 Redis 占用的內(nèi)存很大，那么在 fork 子進程時，則會出現(xiàn)明顯的停頓現(xiàn)象。

RDB 的優(yōu)點

1）RDB 文件是是經(jīng)過壓縮的二進制文件，占用空間很小，它保存了 Redis 某個時間點的數(shù)據(jù)集，很適合用于做備份。比如說，你可以在最近的 24 小時內(nèi)，每小時備份一次 RDB 文件，并且在每個月的每一天，也備份一個 RDB 文件。這樣的話，即使遇上問題，也可以隨時將數(shù)據(jù)集還原到不同的版本。

2）RDB 非常適用于災(zāi)難恢復(fù)（disaster recovery）：它只有一個文件，并且內(nèi)容都非常緊湊，可以（在加密后）將它傳送到別的數(shù)據(jù)中心。

3）RDB 可以最大化 redis 的性能。父進程在保存 RDB 文件時唯一要做的就是 fork 出一個子進程，然后這個子進程就會處理接下來的所有保存工作，父進程無須執(zhí)行任何磁盤 I/O 操作。

4）RDB 在恢復(fù)大數(shù)據(jù)集時的速度比 AOF 的恢復(fù)速度要快。

RDB 的缺點

1）RDB 在服務(wù)器故障時容易造成數(shù)據(jù)的丟失。RDB 允許我們通過修改 save point 配置來控制持久化的頻率。但是，因為 RDB 文件需要保存整個數(shù)據(jù)集的狀態(tài)，所以它是一個比較重的操作，如果頻率太頻繁，可能會對 Redis 性能產(chǎn)生影響。所以通?？赡茉O(shè)置至少5分鐘才保存一次快照，這時如果 Redis 出現(xiàn)宕機等情況，則意味著最多可能丟失5分鐘數(shù)據(jù)。

2）RDB 保存時使用 fork 子進程進行數(shù)據(jù)的持久化，如果數(shù)據(jù)比較大的話，fork 可能會非常耗時，造成 Redis 停止處理服務(wù)N毫秒。如果數(shù)據(jù)集很大且 CPU 比較繁忙的時候，停止服務(wù)的時間甚至?xí)揭幻搿?/p>

3）Linux fork 子進程采用的是 copy-on-write 的方式。在 Redis 執(zhí)行 RDB 持久化期間，如果 client 寫入數(shù)據(jù)很頻繁，那么將增加 Redis 占用的內(nèi)存，最壞情況下，內(nèi)存的占用將達到原先的2倍。剛 fork 時，主進程和子進程共享內(nèi)存，但是隨著主進程需要處理寫操作，主進程需要將修改的頁面拷貝一份出來，然后進行修改。極端情況下，如果所有的頁面都被修改，則此時的內(nèi)存占用是原先的2倍。

2）AOF

描述：保存 Redis 服務(wù)器所執(zhí)行的所有寫操作命令來記錄數(shù)據(jù)庫狀態(tài)，并在服務(wù)器啟動時，通過重新執(zhí)行這些命令來還原數(shù)據(jù)集。

開啟：AOF 持久化默認是關(guān)閉的，可以通過配置：appendonly yes 開啟。

關(guān)閉：使用配置 appendonly no 可以關(guān)閉 AOF 持久化。

AOF 持久化功能的實現(xiàn)可以分為三個步驟：命令追加、文件寫入、文件同步。

命令追加：當(dāng) AOF 持久化功能打開時，服務(wù)器在執(zhí)行完一個寫命令之后，會將被執(zhí)行的寫命令追加到服務(wù)器狀態(tài)的 aof 緩沖區(qū)（aof_buf）的末尾。

文件寫入與文件同步：可能有人不明白為什么將 aof_buf 的內(nèi)容寫到磁盤上需要兩步操作，這邊簡單解釋一下。

Linux 操作系統(tǒng)中為了提升性能，使用了頁緩存（page cache）。當(dāng)我們將 aof_buf 的內(nèi)容寫到磁盤上時，此時數(shù)據(jù)并沒有真正的落盤，而是在 page cache 中，為了將 page cache 中的數(shù)據(jù)真正落盤，需要執(zhí)行 fsync / fdatasync 命令來強制刷盤。這邊的文件同步做的就是刷盤操作，或者叫文件刷盤可能更容易理解一些。

在文章開頭，我們提過 serverCron 時間事件中會觸發(fā) flushAppendOnlyFile 函數(shù)，該函數(shù)會根據(jù)服務(wù)器配置的 appendfsync 參數(shù)值，來決定是否將 aof_buf 緩沖區(qū)的內(nèi)容寫入和保存到 AOF 文件。

appendfsync 參數(shù)有三個選項：

always：每處理一個命令都將 aof_buf 緩沖區(qū)中的所有內(nèi)容寫入并同步到AOF 文件，即每個命令都刷盤。
everysec：將 aof_buf 緩沖區(qū)中的所有內(nèi)容寫入到 AOF 文件，如果上次同步 AOF 文件的時間距離現(xiàn)在超過一秒鐘，那么再次對 AOF 文件進行同步，并且這個同步操作是異步的，由一個后臺線程專門負責(zé)執(zhí)行，即每秒刷盤1次。
no：將 aof_buf 緩沖區(qū)中的所有內(nèi)容寫入到 AOF 文件，但并不對 AOF 文件進行同步，何時同步由操作系統(tǒng)來決定。即不執(zhí)行刷盤，讓操作系統(tǒng)自己執(zhí)行刷盤。

AOF 的優(yōu)點

AOF 比 RDB可靠。你可以設(shè)置不同的 fsync 策略：no、everysec 和 always。默認是 everysec，在這種配置下，redis 仍然可以保持良好的性能，并且就算發(fā)生故障停機，也最多只會丟失一秒鐘的數(shù)據(jù)。
AOF文件是一個純追加的日志文件。即使日志因為某些原因而包含了未寫入完整的命令（比如寫入時磁盤已滿，寫入中途停機等等），我們也可以使用 redis-check-aof 工具也可以輕易地修復(fù)這種問題。
當(dāng) AOF文件太大時，Redis 會自動在后臺進行重寫：重寫后的新 AOF 文件包含了恢復(fù)當(dāng)前數(shù)據(jù)集所需的最小命令集合。整個重寫是絕對安全，因為重寫是在一個新的文件上進行，同時 Redis 會繼續(xù)往舊的文件追加數(shù)據(jù)。當(dāng)新文件重寫完畢，Redis 會把新舊文件進行切換，然后開始把數(shù)據(jù)寫到新文件上。
AOF 文件有序地保存了對數(shù)據(jù)庫執(zhí)行的所有寫入操作以 Redis 協(xié)議的格式保存，因此 AOF 文件的內(nèi)容非常容易被人讀懂，對文件進行分析（parse）也很輕松。如果你不小心執(zhí)行了 FLUSHALL 命令把所有數(shù)據(jù)刷掉了，但只要 AOF 文件沒有被重寫，那么只要停止服務(wù)器，移除 AOF 文件末尾的 FLUSHALL 命令，并重啟 Redis ，就可以將數(shù)據(jù)集恢復(fù)到 FLUSHALL 執(zhí)行之前的狀態(tài)。

AOF 的缺點

對于相同的數(shù)據(jù)集，AOF 文件的大小一般會比 RDB 文件大。
根據(jù)所使用的 fsync 策略，AOF 的速度可能會比 RDB 慢。通常 fsync 設(shè)置為每秒一次就能獲得比較高的性能，而關(guān)閉 fsync 可以讓 AOF 的速度和 RDB 一樣快。
AOF 在過去曾經(jīng)發(fā)生過這樣的 bug ：因為個別命令的原因，導(dǎo)致 AOF 文件在重新載入時，無法將數(shù)據(jù)集恢復(fù)成保存時的原樣。（舉個例子，阻塞命令 BRPOPLPUSH 就曾經(jīng)引起過這樣的 bug ）。雖然這種 bug 在 AOF 文件中并不常見，但是相較而言， RDB 幾乎是不可能出現(xiàn)這種 bug 的。

3）混合持久化

描述：混合持久化并不是一種全新的持久化方式，而是對已有方式的優(yōu)化。混合持久化只發(fā)生于 AOF 重寫過程。使用了混合持久化，重寫后的新 AOF 文件前半段是 RDB 格式的全量數(shù)據(jù)，后半段是 AOF 格式的增量數(shù)據(jù)。

整體格式為：[RDB file][AOF tail]

開啟：混合持久化的配置參數(shù)為 aof-use-rdb-preamble，配置為 yes 時開啟混合持久化，在 redis 4 剛引入時，默認是關(guān)閉混合持久化的，但是在 redis 5 中默認已經(jīng)打開了。

關(guān)閉：使用 aof-use-rdb-preamble no 配置即可關(guān)閉混合持久化。

混合持久化本質(zhì)是通過 AOF 后臺重寫（bgrewriteaof 命令）完成的，不同的是當(dāng)開啟混合持久化時，fork 出的子進程先將當(dāng)前全量數(shù)據(jù)以 RDB 方式寫入新的 AOF 文件，然后再將 AOF 重寫緩沖區(qū)（aof_rewrite_buf_blocks）的增量命令以 AOF 方式寫入到文件，寫入完成后通知主進程將新的含有 RDB 格式和 AOF 格式的 AOF 文件替換舊的的 AOF 文件。

優(yōu)點：結(jié)合 RDB 和 AOF 的優(yōu)點, 更快的重寫和恢復(fù)。

缺點：AOF 文件里面的 RDB 部分不再是 AOF 格式，可讀性差。

8、為什么需要 AOF 重寫

AOF 持久化是通過保存被執(zhí)行的寫命令來記錄數(shù)據(jù)庫狀態(tài)的，隨著寫入命令的不斷增加，AOF 文件中的內(nèi)容會越來越多，文件的體積也會越來越大。

如果不加以控制，體積過大的 AOF 文件可能會對 Redis 服務(wù)器、甚至整個宿主機造成影響，并且 AOF 文件的體積越大，使用 AOF 文件來進行數(shù)據(jù)還原所需的時間就越多。

舉個例子，如果你對一個計數(shù)器調(diào)用了 100 次 INCR ，那么僅僅是為了保存這個計數(shù)器的當(dāng)前值， AOF 文件就需要使用 100 條記錄。

然而在實際上，只使用一條 SET 命令已經(jīng)足以保存計數(shù)器的當(dāng)前值了，其余 99 條記錄實際上都是多余的。

為了處理這種情況， Redis 引入了 AOF 重寫：可以在不打斷服務(wù)端處理請求的情況下，對 AOF 文件進行重建（rebuild）。

9、介紹下 AOF 重寫的過程、AOF 后臺重寫存在的問題、如何解決 AOF 后臺重寫存在的數(shù)據(jù)不一致問題

描述：Redis 生成新的 AOF 文件來代替舊 AOF 文件，這個新的 AOF 文件包含重建當(dāng)前數(shù)據(jù)集所需的最少命令。具體過程是遍歷所有數(shù)據(jù)庫的所有鍵，從數(shù)據(jù)庫讀取鍵現(xiàn)在的值，然后用一條命令去記錄鍵值對，代替之前記錄這個鍵值對的多條命令。

命令：有兩個 Redis 命令可以用于觸發(fā) AOF 重寫，一個是 BGREWRITEAOF 、另一個是 REWRITEAOF 命令；

開啟：AOF 重寫由兩個參數(shù)共同控制，auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size，同時滿足這兩個條件，則觸發(fā) AOF 后臺重寫 BGREWRITEAOF。

// 當(dāng)前AOF文件比上次重寫后的AOF文件大小的增長比例超過100 auto-aof-rewrite-percentage 100 // 當(dāng)前AOF文件的文件大小大于64MB auto-aof-rewrite-min-size 64mb

關(guān)閉：auto-aof-rewrite-percentage 0，指定0的百分比，以禁用自動AOF重寫功能。

auto-aof-rewrite-percentage 0

REWRITEAOF：進行 AOF 重寫，但是會阻塞主進程，服務(wù)器將無法處理客戶端發(fā)來的命令請求，通常不會直接使用該命令。

BGREWRITEAOF：fork 子進程來進行 AOF 重寫，阻塞只會發(fā)生在 fork 子進程的時候，之后主進程可以正常處理請求。

REWRITEAOF 和 BGREWRITEAOF 的關(guān)系與 SAVE 和 BGSAVE 的關(guān)系類似。

AOF 后臺重寫存在的問題

AOF 后臺重寫使用子進程進行從寫，解決了主進程阻塞的問題，但是仍然存在另一個問題：子進程在進行 AOF 重寫期間，服務(wù)器主進程還需要繼續(xù)處理命令請求，新的命令可能會對現(xiàn)有的數(shù)據(jù)庫狀態(tài)進行修改，從而使得當(dāng)前的數(shù)據(jù)庫狀態(tài)和重寫后的 AOF 文件保存的數(shù)據(jù)庫狀態(tài)不一致。

如何解決 AOF 后臺重寫存在的數(shù)據(jù)不一致問題

為了解決上述問題，Redis 引入了 AOF 重寫緩沖區(qū)（aof_rewrite_buf_blocks），這個緩沖區(qū)在服務(wù)器創(chuàng)建子進程之后開始使用，當(dāng) Redis 服務(wù)器執(zhí)行完一個寫命令之后，它會同時將這個寫命令追加到 AOF 緩沖區(qū)和 AOF 重寫緩沖區(qū)。

這樣一來可以保證：

1、現(xiàn)有 AOF 文件的處理工作會如常進行。這樣即使在重寫的中途發(fā)生停機，現(xiàn)有的 AOF 文件也還是安全的。

2、從創(chuàng)建子進程開始，也就是 AOF 重寫開始，服務(wù)器執(zhí)行的所有寫命令會被記錄到 AOF 重寫緩沖區(qū)里面。

這樣，當(dāng)子進程完成 AOF 重寫工作后，父進程會在 serverCron 中檢測到子進程已經(jīng)重寫結(jié)束，則會執(zhí)行以下工作：

1、將 AOF 重寫緩沖區(qū)中的所有內(nèi)容寫入到新 AOF 文件中，這時新 AOF 文件所保存的數(shù)據(jù)庫狀態(tài)將和服務(wù)器當(dāng)前的數(shù)據(jù)庫狀態(tài)一致。

2、對新的 AOF 文件進行改名，原子的覆蓋現(xiàn)有的 AOF 文件，完成新舊兩個 AOF 文件的替換。

之后，父進程就可以繼續(xù)像往常一樣接受命令請求了。

10、RDB、AOF、混合持久，我應(yīng)該用哪一個？

一般來說，如果想盡量保證數(shù)據(jù)安全性，你應(yīng)該同時使用 RDB 和 AOF 持久化功能，同時可以開啟混合持久化。

如果你非常關(guān)心你的數(shù)據(jù)，但仍然可以承受數(shù)分鐘以內(nèi)的數(shù)據(jù)丟失，那么你可以只使用 RDB 持久化。

如果你的數(shù)據(jù)是可以丟失的，則可以關(guān)閉持久化功能，在這種情況下，Redis 的性能是最高的。

使用 Redis 通常都是為了提升性能，而如果為了不丟失數(shù)據(jù)而將 appendfsync 設(shè)置為 always 級別時，對 Redis 的性能影響是很大的，在這種不能接受數(shù)據(jù)丟失的場景，其實可以考慮直接選擇 MySQL 等類似的數(shù)據(jù)庫。