大家好，我是小林。

上周有位讀者字節(jié)一二面時，被問到：Redis 的大 Key 對持久化有什么影響？

Redis 的持久化方式有兩種：AOF 日志和 RDB 快照。

所以接下來，針對這兩種持久化方式具體分析分析。

大 Key 對 AOF 日志的影響

先說說 AOF 日志三種寫回磁盤的策略

Redis 提供了 3 種 AOF 日志寫回硬盤的策略，分別是：

• Always，這個單詞的意思是「總是」，所以它的意思是每次寫操作命令執(zhí)行完后，同步將 AOF 日志數(shù)據(jù)寫回硬盤；
• Everysec，這個單詞的意思是「每秒」，所以它的意思是每次寫操作命令執(zhí)行完后，先將命令寫入到 AOF 文件的內(nèi)核緩沖區(qū)，然后每隔一秒將緩沖區(qū)里的內(nèi)容寫回到硬盤；
• No，意味著不由 Redis 控制寫回硬盤的時機，轉(zhuǎn)交給操作系統(tǒng)控制寫回的時機，也就是每次寫操作命令執(zhí)行完后，先將命令寫入到 AOF 文件的內(nèi)核緩沖區(qū)，再由操作系統(tǒng)決定何時將緩沖區(qū)內(nèi)容寫回硬盤。

這三種策略只是在控制 fsync() 函數(shù)的調(diào)用時機。

當(dāng)應(yīng)用程序向文件寫入數(shù)據(jù)時，內(nèi)核通常先將數(shù)據(jù)復(fù)制到內(nèi)核緩沖區(qū)中，然后排入隊列，然后由內(nèi)核決定何時寫入硬盤。

如果想要應(yīng)用程序向文件寫入數(shù)據(jù)后，能立馬將數(shù)據(jù)同步到硬盤，就可以調(diào)用 fsync() 函數(shù)，這樣內(nèi)核就會將內(nèi)核緩沖區(qū)的數(shù)據(jù)直接寫入到硬盤，等到硬盤寫操作完成后，該函數(shù)才會返回。

• Always 策略就是每次寫入 AOF 文件數(shù)據(jù)后，就執(zhí)行 fsync() 函數(shù)；
• Everysec 策略就會創(chuàng)建一個異步任務(wù)來執(zhí)行 fsync() 函數(shù)；
• No 策略就是永不執(zhí)行 fsync() 函數(shù);

分別說說這三種策略，在持久化大 Key 的時候，會影響什么？

在使用 Always 策略的時候，主線程在執(zhí)行完命令后，會把數(shù)據(jù)寫入到 AOF 日志文件，然后會調(diào)用  fsync() 函數(shù)，將內(nèi)核緩沖區(qū)的數(shù)據(jù)直接寫入到硬盤，等到硬盤寫操作完成后，該函數(shù)才會返回。

當(dāng)使用 Always 策略的時候，如果寫入是一個大 Key，主線程在執(zhí)行 fsync() 函數(shù)的時候，阻塞的時間會比較久，因為當(dāng)寫入的數(shù)據(jù)量很大的時候，數(shù)據(jù)同步到硬盤這個過程是很耗時的。

當(dāng)使用 Everysec 策略的時候，由于是異步執(zhí)行 fsync() 函數(shù)，所以大 Key 持久化的過程（數(shù)據(jù)同步磁盤）不會影響主線程。

當(dāng)使用 No 策略的時候，由于永不執(zhí)行 fsync() 函數(shù)，所以大 Key 持久化的過程不會影響主線程。

大 Key 對 AOF 重寫和 RDB 的影響

當(dāng) AOF 日志寫入了很多的大 Key，AOF 日志文件的大小會很大，那么很快就會觸發(fā) AOF 重寫機制。

AOF 重寫機制和 RDB 快照（bgsave 命令）的過程，都會分別通過fork()函數(shù)創(chuàng)建一個子進程來處理任務(wù)。

在創(chuàng)建子進程的過程中，操作系統(tǒng)會把父進程的「頁表」復(fù)制一份給子進程，這個頁表記錄著虛擬地址和物理地址映射關(guān)系，而不會復(fù)制物理內(nèi)存，也就是說，兩者的虛擬空間不同，但其對應(yīng)的物理空間是同一個。

這樣一來，子進程就共享了父進程的物理內(nèi)存數(shù)據(jù)了，這樣能夠節(jié)約物理內(nèi)存資源，頁表對應(yīng)的頁表項的屬性會標(biāo)記該物理內(nèi)存的權(quán)限為只讀。

隨著 Redis 存在越來越多的大 Key，那么 Redis 就會占用很多內(nèi)存，對應(yīng)的頁表就會越大。

fork()函數(shù)創(chuàng)建子進程的時候，雖然不會復(fù)制父進程的物理內(nèi)存，但是內(nèi)核會把父進程的頁表復(fù)制一份給子進程，如果頁表很大，那么這個復(fù)制過程是會很耗時的，那么在執(zhí)行 fork 函數(shù)的時候就會發(fā)生阻塞現(xiàn)象。

而且，fork 函數(shù)是由 Redis 主線程調(diào)用的，如果 fork 函數(shù)發(fā)生阻塞，那么意味著就會阻塞 Redis 主線程。由于 Redis 執(zhí)行命令是在主線程處理的，所以當(dāng) Redis 主線程發(fā)生阻塞，就無法處理后續(xù)客戶端發(fā)來的命令。

我們可以執(zhí)行info命令獲取到 latest_fork_usec 指標(biāo)，表示 Redis 最近一次 fork 操作耗時。

# 最近一次 fork 操作耗時 latest_fork_usec:315

如果 fork 耗時很大，比如超過1秒，則需要做出優(yōu)化調(diào)整：

• 單個實例的內(nèi)存占用控制在 10 GB 以下，這樣 fork 函數(shù)就能很快返回。
• 如果 Redis 只是當(dāng)作純緩存使用，不關(guān)心 Redis 數(shù)據(jù)安全性問題，可以考慮關(guān)閉 AOF 和 AOF 重寫，這樣就不會調(diào)用 fork 函數(shù)了。
• 在主從架構(gòu)中，要適當(dāng)調(diào)大 repl-backlog-size，避免因為  repl_backlog_buffer 不夠大，導(dǎo)致主節(jié)點頻繁地使用全量同步的方式，全量同步的時候，是會創(chuàng)建 RDB 文件的，也就是會調(diào)用 fork 函數(shù)。

那什么時候會發(fā)生物理內(nèi)存的復(fù)制呢？

當(dāng)父進程或者子進程在向共享內(nèi)存發(fā)起寫操作時，CPU 就會觸發(fā)缺頁中斷，這個缺頁中斷是由于違反權(quán)限導(dǎo)致的，然后操作系統(tǒng)會在「缺頁異常處理函數(shù)」里進行物理內(nèi)存的復(fù)制，并重新設(shè)置其內(nèi)存映射關(guān)系，將父子進程的內(nèi)存讀寫權(quán)限設(shè)置為可讀寫，最后才會對內(nèi)存進行寫操作，這個過程被稱為「**寫時復(fù)制(Copy On Write)**」。

寫時復(fù)制顧名思義，在發(fā)生寫操作的時候，操作系統(tǒng)才會去復(fù)制物理內(nèi)存，這樣是為了防止 fork 創(chuàng)建子進程時，由于物理內(nèi)存數(shù)據(jù)的復(fù)制時間過長而導(dǎo)致父進程長時間阻塞的問題。

如果創(chuàng)建完子進程后，父進程對共享內(nèi)存中的大 Key 進行了修改，那么內(nèi)核就會發(fā)生寫時復(fù)制，會把物理內(nèi)存復(fù)制一份，由于大 Key 占用的物理內(nèi)存是比較大的，那么在復(fù)制物理內(nèi)存這一過程中，也是比較耗時的，于是父進程（主線程）就會發(fā)生阻塞。

所以，有兩個階段會導(dǎo)致阻塞父進程：

• 創(chuàng)建子進程的途中，由于要復(fù)制父進程的頁表等數(shù)據(jù)結(jié)構(gòu)，阻塞的時間跟頁表的大小有關(guān)，頁表越大，阻塞的時間也越長；
• 創(chuàng)建完子進程后，如果子進程或者父進程修改了共享數(shù)據(jù)，就會發(fā)生寫時復(fù)制，這期間會拷貝物理內(nèi)存，如果內(nèi)存越大，自然阻塞的時間也越長；

這里額外提一下， 如果 Linux 開啟了內(nèi)存大頁，會影響 Redis 的性能的。

Linux 內(nèi)核從 2.6.38 開始支持內(nèi)存大頁機制，該機制支持 2MB 大小的內(nèi)存頁分配，而常規(guī)的內(nèi)存頁分配是按 4KB 的粒度來執(zhí)行的。

如果采用了內(nèi)存大頁，那么即使客戶端請求只修改 100B 的數(shù)據(jù)，在發(fā)生寫時復(fù)制后，Redis 也需要拷貝 2MB 的大頁。相反，如果是常規(guī)內(nèi)存頁機制，只用拷貝 4KB。

兩者相比，你可以看到，每次寫命令引起的復(fù)制內(nèi)存頁單位放大了 512 倍，會拖慢寫操作的執(zhí)行時間，最終導(dǎo)致 Redis 性能變慢。

那該怎么辦呢？很簡單，關(guān)閉內(nèi)存大頁（默認(rèn)是關(guān)閉的）。

禁用方法如下：

echo never >  /sys/kernel/mm/transparent_hugepage/enabled

總結(jié)

當(dāng) AOF 寫回策略配置了 Always 策略，如果寫入是一個大 Key，主線程在執(zhí)行 fsync() 函數(shù)的時候，阻塞的時間會比較久，因為當(dāng)寫入的數(shù)據(jù)量很大的時候，數(shù)據(jù)同步到硬盤這個過程是很耗時的。

AOF 重寫機制和 RDB 快照（bgsave 命令）的過程，都會分別通過fork()函數(shù)創(chuàng)建一個子進程來處理任務(wù)。會有兩個階段會導(dǎo)致阻塞父進程（主線程）：

• 創(chuàng)建子進程的途中，由于要復(fù)制父進程的頁表等數(shù)據(jù)結(jié)構(gòu)，阻塞的時間跟頁表的大小有關(guān)，頁表越大，阻塞的時間也越長；
• 創(chuàng)建完子進程后，如果父進程修改了共享數(shù)據(jù)中的大 Key，就會發(fā)生寫時復(fù)制，這期間會拷貝物理內(nèi)存，由于大 Key 占用的物理內(nèi)存會很大，那么在復(fù)制物理內(nèi)存這一過程，就會比較耗時，所以有可能會阻塞父進程。

大 key 除了會影響持久化之外，還會有以下的影響。

• 客戶端超時阻塞。由于 Redis 執(zhí)行命令是單線程處理，然后在操作大 key 時會比較耗時，那么就會阻塞 Redis，從客戶端這一視角看，就是很久很久都沒有響應(yīng)。

• 引發(fā)網(wǎng)絡(luò)阻塞。每次獲取大 key 產(chǎn)生的網(wǎng)絡(luò)流量較大，如果一個 key 的大小是 1 MB，每秒訪問量為 1000，那么每秒會產(chǎn)生 1000MB 的流量，這對于普通千兆網(wǎng)卡的服務(wù)器來說是災(zāi)難性的。

• 阻塞工作線程。如果使用 del 刪除大 key 時，會阻塞工作線程，這樣就沒辦法處理后續(xù)的命令。

• 內(nèi)存分布不均。集群模型在 slot 分片均勻情況下，會出現(xiàn)數(shù)據(jù)和查詢傾斜情況，部分有大 key 的 Redis 節(jié)點占用內(nèi)存多，QPS 也會比較大。

如何避免大 Key 呢？

最好在設(shè)計階段，就把大 key 拆分成一個一個小 key?；蛘?，定時檢查 Redis 是否存在大 key ，如果該大 key 是可以刪除的，不要使用 DEL 命令刪除，因為該命令刪除過程會阻塞主線程，而是用 unlink 命令（Redis 4.0+）刪除大 key，因為該命令的刪除過程是異步的，不會阻塞主線程。