Redis 內(nèi)存為什么不宜過(guò)大

xujin3 2018-08-24

展開(kāi)全文

近兩年我們 HULK 云平臺(tái)承載的Redis日訪問(wèn)量從800+億增加到了2100+億，Redis實(shí)例數(shù)也增長(zhǎng)到了5000+。

在這幾年的線上業(yè)務(wù)的使用中表明，Redis這個(gè)內(nèi)存數(shù)據(jù)庫(kù)，它的高性能、穩(wěn)定性都是不用懷疑的。但在運(yùn)維過(guò)程中，我們走過(guò)的路，踩過(guò)的坑也不少。今天來(lái)討論一下，如果單實(shí)例內(nèi)存過(guò)大，如果一旦出問(wèn)題，那它可能會(huì)帶給我們的就是災(zāi)難性（我想很多公司都遇到過(guò)），這里列舉一下單實(shí)例內(nèi)存過(guò)大可能會(huì)遇到的一些問(wèn)題：

主庫(kù)切換

先來(lái)看一下主庫(kù)宕機(jī)容災(zāi)過(guò)程，如下圖：

在主庫(kù)宕機(jī)的時(shí)候，我們最常見(jiàn)的容災(zāi)策略為“切主”。具體為從該集群剩余從庫(kù)中選出一個(gè)從庫(kù)并將其升級(jí)為主庫(kù)，該從庫(kù)升級(jí)為主庫(kù)后再將剩余從庫(kù)掛載至其下成為其從庫(kù)，最終恢復(fù)整個(gè)主從集群結(jié)構(gòu)。以上是一個(gè)完整的容災(zāi)過(guò)程，而代價(jià)最大的過(guò)程為從庫(kù)的重新掛載，而非主庫(kù)的切換。

這是因?yàn)镽edis無(wú)法像MySQL、MongoDB那樣基于同步的點(diǎn)位在主庫(kù)發(fā)生變化后從新的主庫(kù)繼續(xù)同步數(shù)據(jù)。在Redis集群中一旦從庫(kù)換主，Redis的做法是將更換主庫(kù)的從庫(kù)清空然后從新主庫(kù)完整同步一份數(shù)據(jù)再進(jìn)行續(xù)傳。

從庫(kù)重做流程是這樣的：

1. 主庫(kù)bgsave自身數(shù)據(jù)到磁盤(pán)

2. 主庫(kù)發(fā)送rdb文件到從庫(kù)

3. 從庫(kù)開(kāi)始加載

4. 加載完畢開(kāi)始續(xù)傳，同時(shí)開(kāi)始提供服務(wù)

很明顯，在這個(gè)過(guò)程中Redis的內(nèi)存體積越大以上每一個(gè)步驟的時(shí)間都會(huì)被拉長(zhǎng)，實(shí)際測(cè)試的數(shù)據(jù)如下（我們自認(rèn)我們的機(jī)器性能比較好）：

可以看到，當(dāng)數(shù)據(jù)達(dá)到20G的時(shí)候，一個(gè)從庫(kù)的恢復(fù)時(shí)間已經(jīng)被拉長(zhǎng)到了將近20分鐘，如果有10個(gè)從庫(kù)那么如果依次恢復(fù)則共需200分鐘，而如果此時(shí)該從庫(kù)承擔(dān)著大量的讀取請(qǐng)求你能夠忍受這么長(zhǎng)的恢復(fù)時(shí)間嗎？

看到這里你肯定會(huì)問(wèn)：為什么不能同時(shí)重做所有從庫(kù)？這是因?yàn)樗袕膸?kù)如果同時(shí)向主庫(kù)請(qǐng)求rdb文件那么主庫(kù)的網(wǎng)卡則立即跑滿從而進(jìn)入一個(gè)無(wú)法正常提供服務(wù)的狀態(tài)，此時(shí)主庫(kù)又死了，簡(jiǎn)直是雪上加霜。

當(dāng)然，我們可以批量恢復(fù)從庫(kù)，例如兩兩一組，那么全部從庫(kù)的恢復(fù)時(shí)間也僅僅從200分鐘降低到了100分鐘，這不是五十步笑百步嗎？

另一個(gè)重要問(wèn)題在于第四點(diǎn)中的標(biāo)紅位置，續(xù)傳可以理解為一個(gè)簡(jiǎn)化的MongoDB的oplog，它是一個(gè)體積固定的內(nèi)存空間，我們稱(chēng)之為“同步緩沖區(qū)”。

Redis主庫(kù)的寫(xiě)入操作都會(huì)在該區(qū)域存放一份然后發(fā)送給從庫(kù)，而如果在上文中1，2，3步耗時(shí)太久那么很可能這個(gè)同步緩沖區(qū)就被重寫(xiě)，此時(shí)從庫(kù)無(wú)法找到對(duì)應(yīng)的續(xù)傳位置它會(huì)怎么辦？答案是重做1，2，3步！但因?yàn)槲覀儫o(wú)法解決1，2，3步的耗時(shí)因此該從庫(kù)會(huì)永遠(yuǎn)的進(jìn)入惡性循環(huán)：不停的向主庫(kù)請(qǐng)求完整數(shù)據(jù)，結(jié)果對(duì)主庫(kù)的網(wǎng)卡造成嚴(yán)重影響。

當(dāng)然，曾經(jīng)也看到有公司放棄了Redis原生的主從同步機(jī)制，采用實(shí)時(shí)讀取aof持久化文件來(lái)實(shí)現(xiàn)主從同步。這樣做的好處就是主從關(guān)系的變動(dòng)，Redis不需要重新從新主全量同步數(shù)據(jù)，而是增量的讀取aof文件。但是，伴隨而來(lái)的問(wèn)題是，主庫(kù)aof刷盤(pán)的頻率為always時(shí)對(duì)性能有一定影響，而刷盤(pán)頻率太慢，會(huì)造成主從同步延遲在秒級(jí)別。對(duì)于做了讀寫(xiě)分離的業(yè)務(wù)，這種延遲也許是不能忍受的。

從庫(kù)擴(kuò)容

很多時(shí)候會(huì)出現(xiàn)流量的突發(fā)性增長(zhǎng)，通常在找到原因之前我們的應(yīng)急做法就是擴(kuò)容了。一個(gè)20G的Redis擴(kuò)容一個(gè)從庫(kù)需要將近20分鐘，在這個(gè)緊急的時(shí)刻20分鐘業(yè)務(wù)能夠容忍嗎？可能還沒(méi)擴(kuò)好就死翹翹了。

網(wǎng)絡(luò)緩慢導(dǎo)致從庫(kù)重做引發(fā)雪崩

該場(chǎng)景的最大問(wèn)題是主庫(kù)與從庫(kù)的同步中斷，而此時(shí)很可能從庫(kù)仍然在接受寫(xiě)入請(qǐng)求，那么一旦中斷時(shí)間過(guò)長(zhǎng)同步緩沖區(qū)就很可能被復(fù)寫(xiě)。此時(shí)從庫(kù)上一次的同步位置已丟失，在網(wǎng)絡(luò)恢復(fù)后雖然主庫(kù)沒(méi)有發(fā)生變化但由于從庫(kù)的同步位置丟失了從庫(kù)必須進(jìn)行重做，也就是問(wèn)題一中的1，2，3，4步。如果此時(shí)主庫(kù)內(nèi)存體積過(guò)大那么從庫(kù)重做速度就會(huì)很慢，而發(fā)送到從庫(kù)的讀請(qǐng)求就會(huì)受到嚴(yán)重影響，同時(shí)由于傳輸?shù)膔db文件的體積過(guò)大，主庫(kù)的網(wǎng)卡在相當(dāng)長(zhǎng)的一段時(shí)間內(nèi)都會(huì)受到嚴(yán)重影響。

內(nèi)存越大，觸發(fā)持久化阻塞Redis主線程時(shí)間越長(zhǎng)

Redis是單線程的內(nèi)存數(shù)據(jù)庫(kù)，在Redis需要執(zhí)行耗時(shí)的操作時(shí)，會(huì)fork一個(gè)新進(jìn)程來(lái)做，比如bgsave，bgrewriteaof。 Fork新進(jìn)程時(shí)，雖然可共享的數(shù)據(jù)內(nèi)容不需要復(fù)制，但會(huì)復(fù)制之前進(jìn)程空間的內(nèi)存頁(yè)表，這個(gè)復(fù)制是主線程來(lái)做的，會(huì)阻塞所有的讀寫(xiě)操作，并且隨著內(nèi)存使用量越大耗時(shí)越長(zhǎng)。例如：內(nèi)存20G的Redis，bgsave復(fù)制內(nèi)存頁(yè)表耗時(shí)約為750ms，Redis主線程也會(huì)因?yàn)樗枞?50ms。

解決方法：

設(shè)置過(guò)期時(shí)間

對(duì)具有時(shí)效性的key設(shè)置過(guò)期時(shí)間，通過(guò)Redis自身的過(guò)期key清理策略來(lái)降低過(guò)期key對(duì)于內(nèi)存的占用

有規(guī)劃的合理使用

盡量減少key名稱(chēng)的復(fù)雜度，減少內(nèi)存開(kāi)銷(xiāo)；選擇合理的數(shù)據(jù)結(jié)構(gòu)解決實(shí)際問(wèn)題，既可以提高效率又可以節(jié)省內(nèi)存

及時(shí)清理無(wú)用數(shù)據(jù)

例如一個(gè)Redis承載了3個(gè)業(yè)務(wù)的數(shù)據(jù)，一段時(shí)間后有2個(gè)業(yè)務(wù)下線了，那就把這兩個(gè)業(yè)務(wù)的相關(guān)數(shù)據(jù)清理了唄

對(duì)數(shù)據(jù)壓縮存儲(chǔ)

例如一些長(zhǎng)文本形式的數(shù)據(jù)，壓縮能夠大幅度降低內(nèi)存占用

關(guān)注內(nèi)存增長(zhǎng)和大容量key的內(nèi)存分析

不管是DBA還是開(kāi)發(fā)人員，你用Redis，你就必須關(guān)注內(nèi)存，否則，你其實(shí)就是不稱(chēng)職的，這里可以分析Redis實(shí)例中哪些key比較大從而幫助業(yè)務(wù)快速定位異常key（非預(yù)期增長(zhǎng)的key，往往是問(wèn)題之源）

使用Pika

最后，有同學(xué)可能會(huì)說(shuō)了，我數(shù)據(jù)量就那么大怎么辦。我們的終極大殺器Pika就不得不登臺(tái)了。

那Pika是什么？這里我們簡(jiǎn)單的介紹一下。

Pika 是DBA和基礎(chǔ)架構(gòu)組聯(lián)合開(kāi)發(fā)的大容量、高性能、多線程、持久化的類(lèi)Redis存儲(chǔ)系統(tǒng)。Pika中的數(shù)據(jù)使用磁盤(pán)而非內(nèi)存，多線程的結(jié)構(gòu)設(shè)計(jì)，保證了在使用磁盤(pán)的同時(shí)還擁有強(qiáng)勁的性能。它支持多數(shù)據(jù)結(jié)構(gòu)，完全支持Redis協(xié)議。用戶(hù)無(wú)需換驅(qū)動(dòng)，無(wú)需改代碼，支持從Redis實(shí)時(shí)同步數(shù)據(jù)的無(wú)縫遷移。如果把業(yè)務(wù)遷移到新開(kāi)源的Pika上面，這樣就不用太關(guān)注內(nèi)存了，Redis內(nèi)存太大引發(fā)的問(wèn)題，那也都不是問(wèn)題了。感興趣的同學(xué)快來(lái)試試吧！

本站是提供個(gè)人知識(shí)管理的網(wǎng)絡(luò)存儲(chǔ)空間，所有內(nèi)容均由用戶(hù)發(fā)布，不代表本站觀點(diǎn)。請(qǐng)注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購(gòu)買(mǎi)等信息，謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)點(diǎn)擊一鍵舉報(bào)。

轉(zhuǎn)藏 分享

QQ空間 QQ好友新浪微博微信

獻(xiàn)花（0） +1

來(lái)自： xujin3 > 《redis》

舉報(bào)/認(rèn)領(lǐng)