字節(jié)二面:Redis 的大 Key 對(duì)持久化有什么影響?
大家好,我是小林。
上周有位讀者字節(jié)一二面時(shí),被問(wèn)到:Redis 的大 Key 對(duì)持久化有什么影響?
Redis 的持久化方式有兩種:AOF 日志和 RDB 快照。
所以接下來(lái),針對(duì)這兩種持久化方式具體分析分析。
大 Key 對(duì) AOF 日志的影響
先說(shuō)說(shuō) AOF 日志三種寫(xiě)回磁盤(pán)的策略
Redis 提供了 3 種 AOF 日志寫(xiě)回硬盤(pán)的策略,分別是:
- Always,這個(gè)單詞的意思是「總是」,所以它的意思是每次寫(xiě)操作命令執(zhí)行完后,同步將 AOF 日志數(shù)據(jù)寫(xiě)回硬盤(pán);
- Everysec,這個(gè)單詞的意思是「每秒」,所以它的意思是每次寫(xiě)操作命令執(zhí)行完后,先將命令寫(xiě)入到 AOF 文件的內(nèi)核緩沖區(qū),然后每隔一秒將緩沖區(qū)里的內(nèi)容寫(xiě)回到硬盤(pán);
- No,意味著不由 Redis 控制寫(xiě)回硬盤(pán)的時(shí)機(jī),轉(zhuǎn)交給操作系統(tǒng)控制寫(xiě)回的時(shí)機(jī),也就是每次寫(xiě)操作命令執(zhí)行完后,先將命令寫(xiě)入到 AOF 文件的內(nèi)核緩沖區(qū),再由操作系統(tǒng)決定何時(shí)將緩沖區(qū)內(nèi)容寫(xiě)回硬盤(pán)。
這三種策略只是在控制 fsync() 函數(shù)的調(diào)用時(shí)機(jī)。
當(dāng)應(yīng)用程序向文件寫(xiě)入數(shù)據(jù)時(shí),內(nèi)核通常先將數(shù)據(jù)復(fù)制到內(nèi)核緩沖區(qū)中,然后排入隊(duì)列,然后由內(nèi)核決定何時(shí)寫(xiě)入硬盤(pán)。
如果想要應(yīng)用程序向文件寫(xiě)入數(shù)據(jù)后,能立馬將數(shù)據(jù)同步到硬盤(pán),就可以調(diào)用 fsync() 函數(shù),這樣內(nèi)核就會(huì)將內(nèi)核緩沖區(qū)的數(shù)據(jù)直接寫(xiě)入到硬盤(pán),等到硬盤(pán)寫(xiě)操作完成后,該函數(shù)才會(huì)返回。
- Always 策略就是每次寫(xiě)入 AOF 文件數(shù)據(jù)后,就執(zhí)行 fsync() 函數(shù);
- Everysec 策略就會(huì)創(chuàng)建一個(gè)異步任務(wù)來(lái)執(zhí)行 fsync() 函數(shù);
- No 策略就是永不執(zhí)行 fsync() 函數(shù);
分別說(shuō)說(shuō)這三種策略,在持久化大 Key 的時(shí)候,會(huì)影響什么?
在使用 Always 策略的時(shí)候,主線程在執(zhí)行完命令后,會(huì)把數(shù)據(jù)寫(xiě)入到 AOF 日志文件,然后會(huì)調(diào)用 fsync() 函數(shù),將內(nèi)核緩沖區(qū)的數(shù)據(jù)直接寫(xiě)入到硬盤(pán),等到硬盤(pán)寫(xiě)操作完成后,該函數(shù)才會(huì)返回。
當(dāng)使用 Always 策略的時(shí)候,如果寫(xiě)入是一個(gè)大 Key,主線程在執(zhí)行 fsync() 函數(shù)的時(shí)候,阻塞的時(shí)間會(huì)比較久,因?yàn)楫?dāng)寫(xiě)入的數(shù)據(jù)量很大的時(shí)候,數(shù)據(jù)同步到硬盤(pán)這個(gè)過(guò)程是很耗時(shí)的。
當(dāng)使用 Everysec 策略的時(shí)候,由于是異步執(zhí)行 fsync() 函數(shù),所以大 Key 持久化的過(guò)程(數(shù)據(jù)同步磁盤(pán))不會(huì)影響主線程。
當(dāng)使用 No 策略的時(shí)候,由于永不執(zhí)行 fsync() 函數(shù),所以大 Key 持久化的過(guò)程不會(huì)影響主線程。
大 Key 對(duì) AOF 重寫(xiě)和 RDB 的影響
當(dāng) AOF 日志寫(xiě)入了很多的大 Key,AOF 日志文件的大小會(huì)很大,那么很快就會(huì)觸發(fā) AOF 重寫(xiě)機(jī)制。
AOF 重寫(xiě)機(jī)制和 RDB 快照(bgsave 命令)的過(guò)程,都會(huì)分別通過(guò)fork()函數(shù)創(chuàng)建一個(gè)子進(jìn)程來(lái)處理任務(wù)。
在創(chuàng)建子進(jìn)程的過(guò)程中,操作系統(tǒng)會(huì)把父進(jìn)程的「頁(yè)表」復(fù)制一份給子進(jìn)程,這個(gè)頁(yè)表記錄著虛擬地址和物理地址映射關(guān)系,而不會(huì)復(fù)制物理內(nèi)存,也就是說(shuō),兩者的虛擬空間不同,但其對(duì)應(yīng)的物理空間是同一個(gè)。
這樣一來(lái),子進(jìn)程就共享了父進(jìn)程的物理內(nèi)存數(shù)據(jù)了,這樣能夠節(jié)約物理內(nèi)存資源,頁(yè)表對(duì)應(yīng)的頁(yè)表項(xiàng)的屬性會(huì)標(biāo)記該物理內(nèi)存的權(quán)限為只讀。
隨著 Redis 存在越來(lái)越多的大 Key,那么 Redis 就會(huì)占用很多內(nèi)存,對(duì)應(yīng)的頁(yè)表就會(huì)越大。
fork()函數(shù)創(chuàng)建子進(jìn)程的時(shí)候,雖然不會(huì)復(fù)制父進(jìn)程的物理內(nèi)存,但是內(nèi)核會(huì)把父進(jìn)程的頁(yè)表復(fù)制一份給子進(jìn)程,如果頁(yè)表很大,那么這個(gè)復(fù)制過(guò)程是會(huì)很耗時(shí)的,那么在執(zhí)行 fork 函數(shù)的時(shí)候就會(huì)發(fā)生阻塞現(xiàn)象。
而且,fork 函數(shù)是由 Redis 主線程調(diào)用的,如果 fork 函數(shù)發(fā)生阻塞,那么意味著就會(huì)阻塞 Redis 主線程。由于 Redis 執(zhí)行命令是在主線程處理的,所以當(dāng) Redis 主線程發(fā)生阻塞,就無(wú)法處理后續(xù)客戶端發(fā)來(lái)的命令。
我們可以執(zhí)行info命令獲取到 latest_fork_usec 指標(biāo),表示 Redis 最近一次 fork 操作耗時(shí)。
# 最近一次 fork 操作耗時(shí) latest_fork_usec:315
如果 fork 耗時(shí)很大,比如超過(guò)1秒,則需要做出優(yōu)化調(diào)整:
- 單個(gè)實(shí)例的內(nèi)存占用控制在 10 GB 以下,這樣 fork 函數(shù)就能很快返回。
- 如果 Redis 只是當(dāng)作純緩存使用,不關(guān)心 Redis 數(shù)據(jù)安全性問(wèn)題,可以考慮關(guān)閉 AOF 和 AOF 重寫(xiě),這樣就不會(huì)調(diào)用 fork 函數(shù)了。
- 在主從架構(gòu)中,要適當(dāng)調(diào)大 repl-backlog-size,避免因?yàn)? repl_backlog_buffer 不夠大,導(dǎo)致主節(jié)點(diǎn)頻繁地使用全量同步的方式,全量同步的時(shí)候,是會(huì)創(chuàng)建 RDB 文件的,也就是會(huì)調(diào)用 fork 函數(shù)。
那什么時(shí)候會(huì)發(fā)生物理內(nèi)存的復(fù)制呢?
當(dāng)父進(jìn)程或者子進(jìn)程在向共享內(nèi)存發(fā)起寫(xiě)操作時(shí),CPU 就會(huì)觸發(fā)缺頁(yè)中斷,這個(gè)缺頁(yè)中斷是由于違反權(quán)限導(dǎo)致的,然后操作系統(tǒng)會(huì)在「缺頁(yè)異常處理函數(shù)」里進(jìn)行物理內(nèi)存的復(fù)制,并重新設(shè)置其內(nèi)存映射關(guān)系,將父子進(jìn)程的內(nèi)存讀寫(xiě)權(quán)限設(shè)置為可讀寫(xiě),最后才會(huì)對(duì)內(nèi)存進(jìn)行寫(xiě)操作,這個(gè)過(guò)程被稱為「**寫(xiě)時(shí)復(fù)制(Copy On Write)**」。
寫(xiě)時(shí)復(fù)制顧名思義,在發(fā)生寫(xiě)操作的時(shí)候,操作系統(tǒng)才會(huì)去復(fù)制物理內(nèi)存,這樣是為了防止 fork 創(chuàng)建子進(jìn)程時(shí),由于物理內(nèi)存數(shù)據(jù)的復(fù)制時(shí)間過(guò)長(zhǎng)而導(dǎo)致父進(jìn)程長(zhǎng)時(shí)間阻塞的問(wèn)題。
如果創(chuàng)建完子進(jìn)程后,父進(jìn)程對(duì)共享內(nèi)存中的大 Key 進(jìn)行了修改,那么內(nèi)核就會(huì)發(fā)生寫(xiě)時(shí)復(fù)制,會(huì)把物理內(nèi)存復(fù)制一份,由于大 Key 占用的物理內(nèi)存是比較大的,那么在復(fù)制物理內(nèi)存這一過(guò)程中,也是比較耗時(shí)的,于是父進(jìn)程(主線程)就會(huì)發(fā)生阻塞。
所以,有兩個(gè)階段會(huì)導(dǎo)致阻塞父進(jìn)程:
- 創(chuàng)建子進(jìn)程的途中,由于要復(fù)制父進(jìn)程的頁(yè)表等數(shù)據(jù)結(jié)構(gòu),阻塞的時(shí)間跟頁(yè)表的大小有關(guān),頁(yè)表越大,阻塞的時(shí)間也越長(zhǎng);
- 創(chuàng)建完子進(jìn)程后,如果子進(jìn)程或者父進(jìn)程修改了共享數(shù)據(jù),就會(huì)發(fā)生寫(xiě)時(shí)復(fù)制,這期間會(huì)拷貝物理內(nèi)存,如果內(nèi)存越大,自然阻塞的時(shí)間也越長(zhǎng);
這里額外提一下, 如果 Linux 開(kāi)啟了內(nèi)存大頁(yè),會(huì)影響 Redis 的性能的。
Linux 內(nèi)核從 2.6.38 開(kāi)始支持內(nèi)存大頁(yè)機(jī)制,該機(jī)制支持 2MB 大小的內(nèi)存頁(yè)分配,而常規(guī)的內(nèi)存頁(yè)分配是按 4KB 的粒度來(lái)執(zhí)行的。
如果采用了內(nèi)存大頁(yè),那么即使客戶端請(qǐng)求只修改 100B 的數(shù)據(jù),在發(fā)生寫(xiě)時(shí)復(fù)制后,Redis 也需要拷貝 2MB 的大頁(yè)。相反,如果是常規(guī)內(nèi)存頁(yè)機(jī)制,只用拷貝 4KB。
兩者相比,你可以看到,每次寫(xiě)命令引起的復(fù)制內(nèi)存頁(yè)單位放大了 512 倍,會(huì)拖慢寫(xiě)操作的執(zhí)行時(shí)間,最終導(dǎo)致 Redis 性能變慢。
那該怎么辦呢?很簡(jiǎn)單,關(guān)閉內(nèi)存大頁(yè)(默認(rèn)是關(guān)閉的)。
禁用方法如下:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
總結(jié)
當(dāng) AOF 寫(xiě)回策略配置了 Always 策略,如果寫(xiě)入是一個(gè)大 Key,主線程在執(zhí)行 fsync() 函數(shù)的時(shí)候,阻塞的時(shí)間會(huì)比較久,因?yàn)楫?dāng)寫(xiě)入的數(shù)據(jù)量很大的時(shí)候,數(shù)據(jù)同步到硬盤(pán)這個(gè)過(guò)程是很耗時(shí)的。
AOF 重寫(xiě)機(jī)制和 RDB 快照(bgsave 命令)的過(guò)程,都會(huì)分別通過(guò)fork()函數(shù)創(chuàng)建一個(gè)子進(jìn)程來(lái)處理任務(wù)。會(huì)有兩個(gè)階段會(huì)導(dǎo)致阻塞父進(jìn)程(主線程):
- 創(chuàng)建子進(jìn)程的途中,由于要復(fù)制父進(jìn)程的頁(yè)表等數(shù)據(jù)結(jié)構(gòu),阻塞的時(shí)間跟頁(yè)表的大小有關(guān),頁(yè)表越大,阻塞的時(shí)間也越長(zhǎng);
- 創(chuàng)建完子進(jìn)程后,如果父進(jìn)程修改了共享數(shù)據(jù)中的大 Key,就會(huì)發(fā)生寫(xiě)時(shí)復(fù)制,這期間會(huì)拷貝物理內(nèi)存,由于大 Key 占用的物理內(nèi)存會(huì)很大,那么在復(fù)制物理內(nèi)存這一過(guò)程,就會(huì)比較耗時(shí),所以有可能會(huì)阻塞父進(jìn)程。
大 key 除了會(huì)影響持久化之外,還會(huì)有以下的影響。
-
客戶端超時(shí)阻塞。由于 Redis 執(zhí)行命令是單線程處理,然后在操作大 key 時(shí)會(huì)比較耗時(shí),那么就會(huì)阻塞 Redis,從客戶端這一視角看,就是很久很久都沒(méi)有響應(yīng)。
-
引發(fā)網(wǎng)絡(luò)阻塞。每次獲取大 key 產(chǎn)生的網(wǎng)絡(luò)流量較大,如果一個(gè) key 的大小是 1 MB,每秒訪問(wèn)量為 1000,那么每秒會(huì)產(chǎn)生 1000MB 的流量,這對(duì)于普通千兆網(wǎng)卡的服務(wù)器來(lái)說(shuō)是災(zāi)難性的。
-
阻塞工作線程。如果使用 del 刪除大 key 時(shí),會(huì)阻塞工作線程,這樣就沒(méi)辦法處理后續(xù)的命令。
-
內(nèi)存分布不均。集群模型在 slot 分片均勻情況下,會(huì)出現(xiàn)數(shù)據(jù)和查詢傾斜情況,部分有大 key 的 Redis 節(jié)點(diǎn)占用內(nèi)存多,QPS 也會(huì)比較大。
如何避免大 Key 呢?
最好在設(shè)計(jì)階段,就把大 key 拆分成一個(gè)一個(gè)小 key。或者,定時(shí)檢查 Redis 是否存在大 key ,如果該大 key 是可以刪除的,不要使用 DEL 命令刪除,因?yàn)樵撁顒h除過(guò)程會(huì)阻塞主線程,而是用 unlink 命令(Redis 4.0+)刪除大 key,因?yàn)樵撁畹膭h除過(guò)程是異步的,不會(huì)阻塞主線程。