Redis 內存為什么不宜過大

xujin3 2018-08-24

展開全文

近兩年我們 HULK 云平臺承載的Redis日訪問量從800+億增加到了2100+億，Redis實例數也增長到了5000+。

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

主庫切換

先來看一下主庫宕機容災過程，如下圖：

在主庫宕機的時候，我們最常見的容災策略為“切主”。具體為從該集群剩余從庫中選出一個從庫并將其升級為主庫，該從庫升級為主庫后再將剩余從庫掛載至其下成為其從庫，最終恢復整個主從集群結構。以上是一個完整的容災過程，而代價最大的過程為從庫的重新掛載，而非主庫的切換。

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

從庫重做流程是這樣的：

1. 主庫bgsave自身數據到磁盤

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

3. 從庫開始加載

4. 加載完畢開始續(xù)傳，同時開始提供服務

很明顯，在這個過程中Redis的內存體積越大以上每一個步驟的時間都會被拉長，實際測試的數據如下（我們自認我們的機器性能比較好）：

可以看到，當數據達到20G的時候，一個從庫的恢復時間已經被拉長到了將近20分鐘，如果有10個從庫那么如果依次恢復則共需200分鐘，而如果此時該從庫承擔著大量的讀取請求你能夠忍受這么長的恢復時間嗎？

看到這里你肯定會問：為什么不能同時重做所有從庫？這是因為所有從庫如果同時向主庫請求rdb文件那么主庫的網卡則立即跑滿從而進入一個無法正常提供服務的狀態(tài)，此時主庫又死了，簡直是雪上加霜。

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

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

Redis主庫的寫入操作都會在該區(qū)域存放一份然后發(fā)送給從庫，而如果在上文中1，2，3步耗時太久那么很可能這個同步緩沖區(qū)就被重寫，此時從庫無法找到對應的續(xù)傳位置它會怎么辦？答案是重做1，2，3步！但因為我們無法解決1，2，3步的耗時因此該從庫會永遠的進入惡性循環(huán)：不停的向主庫請求完整數據，結果對主庫的網卡造成嚴重影響。

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

從庫擴容

很多時候會出現流量的突發(fā)性增長，通常在找到原因之前我們的應急做法就是擴容了。一個20G的Redis擴容一個從庫需要將近20分鐘，在這個緊急的時刻20分鐘業(yè)務能夠容忍嗎？可能還沒擴好就死翹翹了。

網絡緩慢導致從庫重做引發(fā)雪崩

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

內存越大，觸發(fā)持久化阻塞Redis主線程時間越長

Redis是單線程的內存數據庫，在Redis需要執(zhí)行耗時的操作時，會fork一個新進程來做，比如bgsave，bgrewriteaof。 Fork新進程時，雖然可共享的數據內容不需要復制，但會復制之前進程空間的內存頁表，這個復制是主線程來做的，會阻塞所有的讀寫操作，并且隨著內存使用量越大耗時越長。例如：內存20G的Redis，bgsave復制內存頁表耗時約為750ms，Redis主線程也會因為它阻塞750ms。

解決方法：

設置過期時間

對具有時效性的key設置過期時間，通過Redis自身的過期key清理策略來降低過期key對于內存的占用

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

盡量減少key名稱的復雜度，減少內存開銷；選擇合理的數據結構解決實際問題，既可以提高效率又可以節(jié)省內存

及時清理無用數據

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

對數據壓縮存儲

例如一些長文本形式的數據，壓縮能夠大幅度降低內存占用

關注內存增長和大容量key的內存分析

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

使用Pika

最后，有同學可能會說了，我數據量就那么大怎么辦。我們的終極大殺器Pika就不得不登臺了。

那Pika是什么？這里我們簡單的介紹一下。

Pika 是DBA和基礎架構組聯合開發(fā)的大容量、高性能、多線程、持久化的類Redis存儲系統。Pika中的數據使用磁盤而非內存，多線程的結構設計，保證了在使用磁盤的同時還擁有強勁的性能。它支持多數據結構，完全支持Redis協議。用戶無需換驅動，無需改代碼，支持從Redis實時同步數據的無縫遷移。如果把業(yè)務遷移到新開源的Pika上面，這樣就不用太關注內存了，Redis內存太大引發(fā)的問題，那也都不是問題了。感興趣的同學快來試試吧！