這幾年的線上業(yè)務(wù)表明，redis這個(gè)內(nèi)存數(shù)據(jù)庫(kù)，它的高性能、穩(wěn)定性都是不用懷疑的，但我們?nèi)M(jìn)redis的數(shù)據(jù)過多，內(nèi)存過大，那如果出問題，那它可能會(huì)帶給我們的就是災(zāi)難性(我想很多公司都遇到過) 這里列舉一下，我們遇到的一些問題：

1 主庫(kù)宕機(jī)

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

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

以上是一個(gè)完整的容災(zāi)過程，而代價(jià)***的過程為從庫(kù)的重新掛載，而非主庫(kù)的切換。

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

整個(gè)從庫(kù)重做流程是這樣的：

1. 主庫(kù)bgsave自身數(shù)據(jù)到磁盤
2. 主庫(kù)發(fā)送rdb文件到從庫(kù)
3. 從庫(kù)開始加載
4. 加載完畢開始續(xù)傳，同時(shí)開始提供服務(wù)

很明顯，在這個(gè)過程中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ì)問：為什么不能同時(shí)重做所有從庫(kù)?這是因?yàn)樗袕膸?kù)如果同時(shí)向主庫(kù)請(qǐng)求rdb文件那么主庫(kù)的網(wǎng)卡則立即跑滿從而進(jìn)入一個(gè)無法正常提供服務(wù)的狀態(tài)，此時(shí)主庫(kù)又死了，簡(jiǎn)直是雪上加霜。

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

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

redis主庫(kù)的寫入操作都會(huì)在該區(qū)域存放一份然后發(fā)送給從庫(kù)，而如果在上文中1，2，3步耗時(shí)太久那么很可能這個(gè)同步緩沖區(qū)就被重寫，此時(shí)從庫(kù)無法找到對(duì)應(yīng)的續(xù)傳位置它會(huì)怎么辦?答案是重做1，2，3步!

但因?yàn)槲覀儫o法解決1，2，3步的耗時(shí)因此該從庫(kù)會(huì)永遠(yuǎn)的進(jìn)入惡性循環(huán)：不停的向主庫(kù)請(qǐng)求完整數(shù)據(jù)，結(jié)果對(duì)主庫(kù)的網(wǎng)卡造成嚴(yán)重影響。

2 擴(kuò)容問題

很多時(shí)候會(huì)出現(xiàn)流量的突發(fā)性增長(zhǎng)，通常在找到原因之前我們的應(yīng)急做法就是擴(kuò)容了。

而根據(jù)場(chǎng)景一中的表格，一個(gè)20G的redis擴(kuò)容一個(gè)從庫(kù)需要將近20分鐘，在這個(gè)緊急的時(shí)刻20分鐘業(yè)務(wù)能夠容忍嗎?可能還沒擴(kuò)好就死翹翹了。

3 網(wǎng)絡(luò)不好導(dǎo)致從庫(kù)重做最終引發(fā)雪崩

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

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

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

解決辦法

解決辦法當(dāng)然就是極力減少內(nèi)存的使用了，一般情況下，我們都是這么做的：

1 設(shè)置過期時(shí)間

對(duì)具有時(shí)效性的key設(shè)置過期時(shí)間，通過redis自身的過期key清理策略來降低過期key對(duì)于內(nèi)存的占用，同時(shí)也能夠減少業(yè)務(wù)的麻煩，不需要定期清理了

2 不存放垃圾到redis中

這簡(jiǎn)直就是廢話，但是，有跟我們同病相憐的人么?

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

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

4 盡量對(duì)數(shù)據(jù)進(jìn)行壓縮

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

5 關(guān)注內(nèi)存增長(zhǎng)并定位大容量key

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

6 pika

如果實(shí)在不想搞的那么累，那就把業(yè)務(wù)遷移到新開源的pika上面，這樣就不用太關(guān)注內(nèi)存了，redis內(nèi)存太大引發(fā)的問題，那也都不是問題了。

***祈禱線上5000個(gè)redis實(shí)例都不要異常~~~