97国内精品久久久久久久影视,国产毛片毛片精品天天看,久久国产精品二国产精品

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

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

主庫切換

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

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

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

從庫重做流程是這樣的：

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

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

3. 從庫開始加載

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

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

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

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

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

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

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

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

從庫擴容

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

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

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

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

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

解決方法：

設(shè)置過期時間

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

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

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

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

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

對數(shù)據(jù)壓縮存儲

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

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

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

使用Pika

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

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

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

本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請點擊舉報。

免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版