Redis遇到并發(fā)、雪崩問(wèn)題怎么解決

本篇內(nèi)容介紹了“Redis遇到并發(fā)、雪崩問(wèn)題怎么解決”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

一、Redis雪崩、穿透、并發(fā)等5大難題解決方案

緩存雪崩

數(shù)據(jù)未加載到緩存中，或者緩存同一時(shí)間大面積的失效，從而導(dǎo)致所有請(qǐng)求都去查數(shù)據(jù)庫(kù)，導(dǎo)致數(shù)據(jù)庫(kù)CPU和內(nèi)存負(fù)載過(guò)高，甚至宕機(jī)。

比如一個(gè)雪崩的簡(jiǎn)單過(guò)程：

1、redis集群大面積故障

2、緩存失效，但依然大量請(qǐng)求訪問(wèn)緩存服務(wù)redis

3、redis大量失效后，大量請(qǐng)求轉(zhuǎn)向到mysql數(shù)據(jù)庫(kù)

4、mysql的調(diào)用量暴增，很快就扛不住了，甚至直接宕機(jī)

5、由于大量的應(yīng)用服務(wù)依賴mysql和redis的服務(wù)，這個(gè)時(shí)候很快會(huì)演變成各服務(wù)器集群的雪崩，最后網(wǎng)站徹底崩潰。

如何預(yù)防緩存雪崩：

1.緩存的高可用性

緩存層設(shè)計(jì)成高可用，防止緩存大面積故障。即使個(gè)別節(jié)點(diǎn)、個(gè)別機(jī)器、甚至是機(jī)房宕掉，依然可以提供服務(wù)，例如 Redis Sentinel 和 Redis Cluster 都實(shí)現(xiàn)了高可用。

2.緩存降級(jí)

可以利用ehcache等本地緩存(暫時(shí)支持)，但主要還是對(duì)源服務(wù)訪問(wèn)進(jìn)行限流、資源隔離（熔斷）、降級(jí)等。

當(dāng)訪問(wèn)量劇增、服務(wù)出現(xiàn)問(wèn)題仍然需要保證服務(wù)還是可用的。系統(tǒng)可以根據(jù)一些關(guān)鍵數(shù)據(jù)進(jìn)行自動(dòng)降級(jí)，也可以配置開(kāi)關(guān)實(shí)現(xiàn)人工降級(jí)，這里會(huì)涉及到運(yùn)維的配合。

降級(jí)的最終目的是保證核心服務(wù)可用，即使是有損的。

比如推薦服務(wù)中，很多都是個(gè)性化的需求，假如個(gè)性化需求不能提供服務(wù)了，可以降級(jí)補(bǔ)充熱點(diǎn)數(shù)據(jù)，不至于造成前端頁(yè)面是個(gè)大空白。

在進(jìn)行降級(jí)之前要對(duì)系統(tǒng)進(jìn)行梳理，比如：哪些業(yè)務(wù)是核心(必須保證)，哪些業(yè)務(wù)可以容許暫時(shí)不提供服務(wù)(利用靜態(tài)頁(yè)面替換)等，以及配合服務(wù)器核心指標(biāo)，來(lái)后設(shè)置整體預(yù)案，比如：

（1）一般：比如有些服務(wù)偶爾因?yàn)榫W(wǎng)絡(luò)抖動(dòng)或者服務(wù)正在上線而超時(shí)，可以自動(dòng)降級(jí)；

（2）警告：有些服務(wù)在一段時(shí)間內(nèi)成功率有波動(dòng)（如在95~100%之間），可以自動(dòng)降級(jí)或人工降級(jí)，并發(fā)送告警；

（3）錯(cuò)誤：比如可用率低于90%，或者數(shù)據(jù)庫(kù)連接池被打爆了，或者訪問(wèn)量突然猛增到系統(tǒng)能承受的最大閥值，此時(shí)可以根據(jù)情況自動(dòng)降級(jí)或者人工降級(jí)；

（4）嚴(yán)重錯(cuò)誤：比如因?yàn)樘厥庠驍?shù)據(jù)錯(cuò)誤了，此時(shí)需要緊急人工降級(jí)。

3.Redis備份和快速預(yù)熱

1)Redis數(shù)據(jù)備份和恢復(fù)

2)快速緩存預(yù)熱

4.提前演練

最后，建議還是在項(xiàng)目上線前，演練緩存層宕掉后，應(yīng)用以及后端的負(fù)載情況以及可能出現(xiàn)的問(wèn)題，對(duì)高可用提前預(yù)演，提前發(fā)現(xiàn)問(wèn)題。

緩存穿透

緩存穿透是指查詢一個(gè)一不存在的數(shù)據(jù)。例如：從緩存redis沒(méi)有命中，需要從mysql數(shù)據(jù)庫(kù)查詢，查不到數(shù)據(jù)則不寫(xiě)入緩存，這將導(dǎo)致這個(gè)不存在的數(shù)據(jù)每次請(qǐng)求都要到數(shù)據(jù)庫(kù)去查詢，造成緩存穿透。

解決思路：

如果查詢數(shù)據(jù)庫(kù)也為空，直接設(shè)置一個(gè)默認(rèn)值存放到緩存，這樣第二次到緩沖中獲取就有值了，而不會(huì)繼續(xù)訪問(wèn)數(shù)據(jù)庫(kù)。設(shè)置一個(gè)過(guò)期時(shí)間或者當(dāng)有值的時(shí)候?qū)⒕彺嬷械闹堤鎿Q掉即可。

可以給key設(shè)置一些格式規(guī)則，然后查詢之前先過(guò)濾掉不符合規(guī)則的Key。

緩存并發(fā)

這里的并發(fā)指的是多個(gè)redis的client同時(shí)set   key引起的并發(fā)問(wèn)題。其實(shí)redis自身就是單線程操作，多個(gè)client并發(fā)操作，按照先到先執(zhí)行的原則，先到的先執(zhí)行，其余的阻塞。當(dāng)然，另外的解決方案是把redis.set操作放在隊(duì)列中使其串行化，必須的一個(gè)一個(gè)執(zhí)行。

緩存預(yù)熱

緩存預(yù)熱就是系統(tǒng)上線后，將相關(guān)的緩存數(shù)據(jù)直接加載到緩存系統(tǒng)。

這樣就可以避免在用戶請(qǐng)求的時(shí)候，先查詢數(shù)據(jù)庫(kù)，然后再將數(shù)據(jù)緩存的問(wèn)題！用戶直接查詢事先被預(yù)熱的緩存數(shù)據(jù)！

解決思路：

1、直接寫(xiě)個(gè)緩存刷新頁(yè)面，上線時(shí)手工操作下；

2、數(shù)據(jù)量不大，可以在項(xiàng)目啟動(dòng)的時(shí)候自動(dòng)進(jìn)行加載；

目的就是在系統(tǒng)上線前，將數(shù)據(jù)加載到緩存中。

二、Redis為什么是單線程，高并發(fā)快的3大原因詳解

Redis的高并發(fā)和快速原因

1.redis是基于內(nèi)存的，內(nèi)存的讀寫(xiě)速度非?？欤?/p>

2.redis是單線程的，省去了很多上下文切換線程的時(shí)間；

3.redis使用多路復(fù)用技術(shù)，可以處理并發(fā)的連接。非阻塞IO 內(nèi)部實(shí)現(xiàn)采用epoll，采用了epoll+自己實(shí)現(xiàn)的簡(jiǎn)單的事件框架。epoll中的讀、寫(xiě)、關(guān)閉、連接都轉(zhuǎn)化成了事件，然后利用epoll的多路復(fù)用特性，絕不在io上浪費(fèi)一點(diǎn)時(shí)間。

下面重點(diǎn)介紹單線程設(shè)計(jì)和IO多路復(fù)用核心設(shè)計(jì)快的原因。

為什么Redis是單線程的？

1.官方答案

因?yàn)镽edis是基于內(nèi)存的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機(jī)器內(nèi)存的大小或者網(wǎng)絡(luò)帶寬。既然單線程容易實(shí)現(xiàn)，而且CPU不會(huì)成為瓶頸，那就順理成章地采用單線程的方案了。

2.性能指標(biāo)

關(guān)于redis的性能，官方網(wǎng)站也有，普通筆記本輕松處理每秒幾十萬(wàn)的請(qǐng)求。

3.詳細(xì)原因

1）不需要各種鎖的性能消耗

Redis的數(shù)據(jù)結(jié)構(gòu)并不全是簡(jiǎn)單的Key-Value，還有l(wèi)ist，hash等復(fù)雜的結(jié)構(gòu)，這些結(jié)構(gòu)有可能會(huì)進(jìn)行很細(xì)粒度的操作，比如在很長(zhǎng)的列表后面添加一個(gè)元素，在hash當(dāng)中添加或者刪除

一個(gè)對(duì)象。這些操作可能就需要加非常多的鎖，導(dǎo)致的結(jié)果是同步開(kāi)銷(xiāo)大大增加。

總之，在單線程的情況下，就不用去考慮各種鎖的問(wèn)題，不存在加鎖釋放鎖操作，沒(méi)有因?yàn)榭赡艹霈F(xiàn)死鎖而導(dǎo)致的性能消耗。

2）單線程多進(jìn)程集群方案

單線程的威力實(shí)際上非常強(qiáng)大，每核心效率也非常高，多線程自然是可以比單線程有更高的性能上限，但是在今天的計(jì)算環(huán)境中，即使是單機(jī)多線程的上限也往往不能滿足需要了，需要進(jìn)一步摸索的是多服務(wù)器集群化的方案，這些方案中多線程的技術(shù)照樣是用不上的。

所以單線程、多進(jìn)程的集群不失為一個(gè)時(shí)髦的解決方案。

3）CPU消耗

采用單線程，避免了不必要的上下文切換和競(jìng)爭(zhēng)條件，也不存在多進(jìn)程或者多線程導(dǎo)致的切換而消耗 CPU。

但是如果CPU成為Redis瓶頸，或者不想讓服務(wù)器其他CUP核閑置，那怎么辦？

可以考慮多起幾個(gè)Redis進(jìn)程，Redis是key-value數(shù)據(jù)庫(kù)，不是關(guān)系數(shù)據(jù)庫(kù)，數(shù)據(jù)之間沒(méi)有約束。只要客戶端分清哪些key放在哪個(gè)Redis進(jìn)程上就可以了。

Redis單線程的優(yōu)劣勢(shì)

單進(jìn)程單線程優(yōu)勢(shì)

1. 代碼更清晰，處理邏輯更簡(jiǎn)單不用去考慮各種鎖的問(wèn)題，不存在加鎖釋放鎖操作，沒(méi)有因?yàn)榭赡艹霈F(xiàn)死鎖而導(dǎo)致的性能消耗不存在多進(jìn)程或者多線程導(dǎo)致的切換而消耗CPU

單進(jìn)程單線程弊端

1. 無(wú)法發(fā)揮多核CPU性能，不過(guò)可以通過(guò)在單機(jī)開(kāi)多個(gè)Redis實(shí)例來(lái)完善；

IO多路復(fù)用技術(shù)

redis 采用網(wǎng)絡(luò)IO多路復(fù)用技術(shù)來(lái)保證在多連接的時(shí)候， 系統(tǒng)的高吞吐量。

多路-指的是多個(gè)socket連接，復(fù)用-指的是復(fù)用一個(gè)線程。多路復(fù)用主要有三種技術(shù)：select，poll，epoll。epoll是最新的也是目前最好的多路復(fù)用技術(shù)。

這里“多路”指的是多個(gè)網(wǎng)絡(luò)連接，“復(fù)用”指的是復(fù)用同一個(gè)線程。采用多路  I/O  復(fù)用技術(shù)可以讓單個(gè)線程高效的處理多個(gè)連接請(qǐng)求（盡量減少網(wǎng)絡(luò)IO的時(shí)間消耗），且Redis在內(nèi)存中操作數(shù)據(jù)的速度非?？欤▋?nèi)存內(nèi)的操作不會(huì)成為這里的性能瓶頸），主要以上兩點(diǎn)造就了Redis具有很高的吞吐量。

Redis高并發(fā)快總結(jié)

1. Redis是純內(nèi)存數(shù)據(jù)庫(kù)，一般都是簡(jiǎn)單的存取操作，線程占用的時(shí)間很多，時(shí)間的花費(fèi)主要集中在IO上，所以讀取速度快。

2. 再說(shuō)一下IO，Redis使用的是非阻塞IO，IO多路復(fù)用，使用了單線程來(lái)輪詢描述符，將數(shù)據(jù)庫(kù)的開(kāi)、關(guān)、讀、寫(xiě)都轉(zhuǎn)換成了事件，減少了線程切換時(shí)上下文的切換和競(jìng)爭(zhēng)。

3. Redis采用了單線程的模型，保證了每個(gè)操作的原子性，也減少了線程的上下文切換和競(jìng)爭(zhēng)。

4. 另外，數(shù)據(jù)結(jié)構(gòu)也幫了不少忙，Redis全程使用hash結(jié)構(gòu)，讀取速度快，還有一些特殊的數(shù)據(jù)結(jié)構(gòu)，對(duì)數(shù)據(jù)存儲(chǔ)進(jìn)行了優(yōu)化，如壓縮表，對(duì)短數(shù)據(jù)進(jìn)行壓縮存儲(chǔ)，再如，跳表，使用有序的數(shù)據(jù)結(jié)構(gòu)加快讀取的速度。

5. 還有一點(diǎn)，Redis采用自己實(shí)現(xiàn)的事件分離器，效率比較高，內(nèi)部采用非阻塞的執(zhí)行方式，吞吐能力比較大。

三、Redis緩存和MySQL數(shù)據(jù)一致性方案詳解

需求起因

在高并發(fā)的業(yè)務(wù)場(chǎng)景下，數(shù)據(jù)庫(kù)大多數(shù)情況都是用戶并發(fā)訪問(wèn)最薄弱的環(huán)節(jié)。所以，就需要使用redis做一個(gè)緩沖操作，讓請(qǐng)求先訪問(wèn)到redis，而不是直接訪問(wèn)MySQL等數(shù)據(jù)庫(kù)。

這個(gè)業(yè)務(wù)場(chǎng)景，主要是解決讀數(shù)據(jù)從Redis緩存，一般都是按照下圖的流程來(lái)進(jìn)行業(yè)務(wù)操作。

讀取緩存步驟一般沒(méi)有什么問(wèn)題，但是一旦涉及到數(shù)據(jù)更新：數(shù)據(jù)庫(kù)和緩存更新，就容易出現(xiàn)緩存(Redis)和數(shù)據(jù)庫(kù)（MySQL）間的數(shù)據(jù)一致性問(wèn)題。

不管是先寫(xiě)MySQL數(shù)據(jù)庫(kù)，再刪除Redis緩存；還是先刪除緩存，再寫(xiě)庫(kù)，都有可能出現(xiàn)數(shù)據(jù)不一致的情況。舉一個(gè)例子：

1.如果刪除了緩存Redis，還沒(méi)有來(lái)得及寫(xiě)庫(kù)MySQL，另一個(gè)線程就來(lái)讀取，發(fā)現(xiàn)緩存為空，則去數(shù)據(jù)庫(kù)中讀取數(shù)據(jù)寫(xiě)入緩存，此時(shí)緩存中為臟數(shù)據(jù)。

2.如果先寫(xiě)了庫(kù)，在刪除緩存前，寫(xiě)庫(kù)的線程宕機(jī)了，沒(méi)有刪除掉緩存，則也會(huì)出現(xiàn)數(shù)據(jù)不一致情況。

因?yàn)閷?xiě)和讀是并發(fā)的，沒(méi)法保證順序,就會(huì)出現(xiàn)緩存和數(shù)據(jù)庫(kù)的數(shù)據(jù)不一致的問(wèn)題。

如來(lái)解決？這里給出兩個(gè)解決方案，先易后難，結(jié)合業(yè)務(wù)和技術(shù)代價(jià)選擇使用。

緩存和數(shù)據(jù)庫(kù)一致性解決方案

1.第一種方案：采用延時(shí)雙刪策略

在寫(xiě)庫(kù)前后都進(jìn)行redis.del(key)操作，并且設(shè)定合理的超時(shí)時(shí)間。

偽代碼如下：

public void write(String key,Object data){
 redis.delKey(key);
 db.updateData(data);
 Thread.sleep(500);
 redis.delKey(key);
 }

具體的步驟就是：

• 先刪除緩存；再寫(xiě)數(shù)據(jù)庫(kù)；休眠500毫秒；再次刪除緩存。

那么，這個(gè)500毫秒怎么確定的，具體該休眠多久呢？

需要評(píng)估自己的項(xiàng)目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)。這么做的目的，就是確保讀請(qǐng)求結(jié)束，寫(xiě)請(qǐng)求可以刪除讀請(qǐng)求造成的緩存臟數(shù)據(jù)。

當(dāng)然這種策略還要考慮redis和數(shù)據(jù)庫(kù)主從同步的耗時(shí)。最后的的寫(xiě)數(shù)據(jù)的休眠時(shí)間：則在讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)基礎(chǔ)上，加幾百ms即可。比如：休眠1秒。

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

從理論上來(lái)說(shuō)，給緩存設(shè)置過(guò)期時(shí)間，是保證最終一致性的解決方案。所有的寫(xiě)操作以數(shù)據(jù)庫(kù)為準(zhǔn)，只要到達(dá)緩存過(guò)期時(shí)間，則后面的讀請(qǐng)求自然會(huì)從數(shù)據(jù)庫(kù)中讀取新值然后回填緩存。

該方案的弊端

結(jié)合雙刪策略+緩存超時(shí)設(shè)置，這樣最差的情況就是在超時(shí)時(shí)間內(nèi)數(shù)據(jù)存在不一致，而且又增加了寫(xiě)請(qǐng)求的耗時(shí)。

2、第二種方案：異步更新緩存(基于訂閱binlog的同步機(jī)制)

技術(shù)整體思路：

MySQL binlog增量訂閱消費(fèi)+消息隊(duì)列+增量數(shù)據(jù)更新到redis

• 讀Redis：熱數(shù)據(jù)基本都在Redis寫(xiě)MySQL:增刪改都是操作MySQL更新Redis數(shù)據(jù)：MySQ的數(shù)據(jù)操作binlog，來(lái)更新到Redis

Redis更新

1）數(shù)據(jù)操作主要分為兩大塊：

• 一個(gè)是全量(將全部數(shù)據(jù)一次寫(xiě)入到redis)一個(gè)是增量（實(shí)時(shí)更新）

這里說(shuō)的是增量,指的是mysql的update、insert、delate變更數(shù)據(jù)。

2）讀取binlog后分析 ，利用消息隊(duì)列,推送更新各臺(tái)的redis緩存數(shù)據(jù)。

這樣一旦MySQL中產(chǎn)生了新的寫(xiě)入、更新、刪除等操作，就可以把binlog相關(guān)的消息推送至Redis，Redis再根據(jù)binlog中的記錄，對(duì)Redis進(jìn)行更新。

其實(shí)這種機(jī)制，很類似MySQL的主從備份機(jī)制，因?yàn)镸ySQL的主備也是通過(guò)binlog來(lái)實(shí)現(xiàn)的數(shù)據(jù)一致性。

這里可以結(jié)合使用canal(阿里的一款開(kāi)源框架)，通過(guò)該框架可以對(duì)MySQL的binlog進(jìn)行訂閱，而canal正是模仿了mysql的slave數(shù)據(jù)庫(kù)的備份請(qǐng)求，使得Redis的數(shù)據(jù)更新達(dá)到了相同的效果。

當(dāng)然，這里的消息推送工具你也可以采用別的第三方：kafka、rabbitMQ等來(lái)實(shí)現(xiàn)推送更新Redis。

“Redis遇到并發(fā)、雪崩問(wèn)題怎么解決”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！