深度掌握Redis：5大難題解決方案、單線程優劣勢、高併發快緣由等

1、Redis雪崩、穿透、併發等5大難題解決方案

緩存雪崩

數據未加載到緩存中，或者緩存同一時間大面積的失效，從而致使全部請求都去查數據庫，致使數據庫CPU和內存負載太高，甚至宕機。

好比一個雪崩的簡單過程：

一、redis集羣大面積故障

二、緩存失效，但依然大量請求訪問緩存服務redis

三、redis大量失效後，大量請求轉向到mysql數據庫

四、mysql的調用量暴增，很快就扛不住了，甚至直接宕機

五、因爲大量的應用服務依賴mysql和redis的服務，這個時候很快會演變成各服務器集羣的雪崩，最後網站完全崩潰。

如何預防緩存雪崩：

1.緩存的高可用性

緩存層設計成高可用，防止緩存大面積故障。即便個別節點、個別機器、甚至是機房宕掉，依然能夠提供服務，例如 Redis Sentinel 和 Redis Cluster 都實現了高可用。

2.緩存降級

能夠利用ehcache等本地緩存(暫時支持)，但主要仍是對源服務訪問進行限流、資源隔離（熔斷）、降級等。

當訪問量劇增、服務出現問題仍然須要保證服務仍是可用的。系統能夠根據一些關鍵數據進行自動降級，也能夠配置開關實現人工降級，這裏會涉及到運維的配合。

降級的最終目的是保證核心服務可用，即便是有損的。

好比推薦服務中，不少都是個性化的需求，假如個性化需求不能提供服務了，能夠降級補充熱點數據，不至於形成前端頁面是個大空白。

在進行降級以前要對系統進行梳理，好比：哪些業務是核心(必須保證)，哪些業務能夠允許暫時不提供服務(利用靜態頁面替換)等，以及配合服務器核心指標，來後設置總體預案，好比：

（1）通常：好比有些服務偶爾由於網絡抖動或者服務正在上線而超時，能夠自動降級；

（2）警告：有些服務在一段時間內成功率有波動（如在95~100%之間），能夠自動降級或人工降級，併發送告警；

（3）錯誤：好比可用率低於90%，或者數據庫鏈接池被打爆了，或者訪問量忽然猛增到系統能承受的最大閥值，此時能夠根據狀況自動降級或者人工降級；

（4）嚴重錯誤：好比由於特殊緣由數據錯誤了，此時須要緊急人工降級。

3.Redis備份和快速預熱

1)Redis數據備份和恢復

2)快速緩存預熱

4.提早演練

最後，建議仍是在項目上線前，演練緩存層宕掉後，應用以及後端的負載狀況以及可能出現的問題，對高可用提早預演，提早發現問題。

緩存穿透

緩存穿透是指查詢一個一不存在的數據。例如：從緩存redis沒有命中，須要從mysql數據庫查詢，查不到數據則不寫入緩存，這將致使這個不存在的數據每次請求都要到數據庫去查詢，形成緩存穿透。

解決思路：

若是查詢數據庫也爲空，直接設置一個默認值存放到緩存，這樣第二次到緩衝中獲取就有值了，而不會繼續訪問數據庫。設置一個過時時間或者當有值的時候將緩存中的值替換掉便可。

能夠給key設置一些格式規則，而後查詢以前先過濾掉不符合規則的Key。

緩存併發

這裏的併發指的是多個redis的client同時set key引發的併發問題。其實redis自身就是單線程操做，多個client併發操做，按照先到先執行的原則，先到的先執行，其他的阻塞。固然，另外的解決方案是把redis.set操做放在隊列中使其串行化，必須的一個一個執行。

緩存預熱

緩存預熱就是系統上線後，將相關的緩存數據直接加載到緩存系統。

這樣就能夠避免在用戶請求的時候，先查詢數據庫，而後再將數據緩存的問題！用戶直接查詢事先被預熱的緩存數據！

解決思路：

一、直接寫個緩存刷新頁面，上線時手工操做下；

二、數據量不大，能夠在項目啓動的時候自動進行加載；

目的就是在系統上線前，將數據加載到緩存中。

2、Redis爲何是單線程，高併發快的3大緣由詳解

Redis的高併發和快速緣由

1.redis是基於內存的，內存的讀寫速度很是快；

2.redis是單線程的，省去了不少上下文切換線程的時間；

3.redis使用多路複用技術，能夠處理併發的鏈接。非阻塞IO 內部實現採用epoll，採用了epoll+本身實現的簡單的事件框架。epoll中的讀、寫、關閉、鏈接都轉化成了事件，而後利用epoll的多路複用特性，毫不在io上浪費一點時間。

下面重點介紹單線程設計和IO多路複用核心設計快的緣由。

爲何Redis是單線程的？

1.官方答案

由於Redis是基於內存的操做，CPU不是Redis的瓶頸，Redis的瓶頸最有多是機器內存的大小或者網絡帶寬。既然單線程容易實現，並且CPU不會成爲瓶頸，那就瓜熟蒂落地採用單線程的方案了。

2.性能指標

關於redis的性能，官方網站也有，普通筆記本輕鬆處理每秒幾十萬的請求。

3.詳細緣由

1）不須要各類鎖的性能消耗

Redis的數據結構並不全是簡單的Key-Value，還有list，hash等複雜的結構，這些結構有可能會進行很細粒度的操做，好比在很長的列表後面添加一個元素，在hash當中添加或者刪除

一個對象。這些操做可能就須要加很是多的鎖，致使的結果是同步開銷大大增長。

總之，在單線程的狀況下，就不用去考慮各類鎖的問題，不存在加鎖釋放鎖操做，沒有由於可能出現死鎖而致使的性能消耗。

2）單線程多進程集羣方案

單線程的威力實際上很是強大，每核心效率也很是高，多線程天然是能夠比單線程有更高的性能上限，可是在今天的計算環境中，即便是單機多線程的上限也每每不能知足須要了，須要進一步摸索的是多服務器集羣化的方案，這些方案中多線程的技術照樣是用不上的。

因此單線程、多進程的集羣不失爲一個時髦的解決方案。

3）CPU消耗

採用單線程，避免了沒必要要的上下文切換和競爭條件，也不存在多進程或者多線程致使的切換而消耗 CPU。

可是若是CPU成爲Redis瓶頸，或者不想讓服務器其餘CUP核閒置，那怎麼辦？

能夠考慮多起幾個Redis進程，Redis是key-value數據庫，不是關係數據庫，數據之間沒有約束。只要客戶端分清哪些key放在哪一個Redis進程上就能夠了。

Redis單線程的優劣勢

單進程單線程優點

代碼更清晰，處理邏輯更簡單不用去考慮各類鎖的問題，不存在加鎖釋放鎖操做，沒有由於可能出現死鎖而致使的性能消耗不存在多進程或者多線程致使的切換而消耗CPU

單進程單線程弊端

沒法發揮多核CPU性能，不過能夠經過在單機開多個Redis實例來完善；

IO多路複用技術

redis 採用網絡IO多路複用技術來保證在多鏈接的時候， 系統的高吞吐量。

多路-指的是多個socket鏈接，複用-指的是複用一個線程。多路複用主要有三種技術：select，poll，epoll。epoll是最新的也是目前最好的多路複用技術。

這裏「多路」指的是多個網絡鏈接，「複用」指的是複用同一個線程。採用多路 I/O 複用技術可讓單個線程高效的處理多個鏈接請求（儘可能減小網絡IO的時間消耗），且Redis在內存中操做數據的速度很是快（內存內的操做不會成爲這裏的性能瓶頸），主要以上兩點造就了Redis具備很高的吞吐量。

Redis高併發快總結

1. Redis是純內存數據庫，通常都是簡單的存取操做，線程佔用的時間不少，時間的花費主要集中在IO上，因此讀取速度快。

2. 再說一下IO，Redis使用的是非阻塞IO，IO多路複用，使用了單線程來輪詢描述符，將數據庫的開、關、讀、寫都轉換成了事件，減小了線程切換時上下文的切換和競爭。

3. Redis採用了單線程的模型，保證了每一個操做的原子性，也減小了線程的上下文切換和競爭。

4. 另外，數據結構也幫了很多忙，Redis全程使用hash結構，讀取速度快，還有一些特殊的數據結構，對數據存儲進行了優化，如壓縮表，對短數據進行壓縮存儲，再如，跳錶，使用有序的數據結構加快讀取的速度。

5. 還有一點，Redis採用本身實現的事件分離器，效率比較高，內部採用非阻塞的執行方式，吞吐能力比較大。

3、Redis緩存和MySQL數據一致性方案詳解

需求原由

在高併發的業務場景下，數據庫大多數狀況都是用戶併發訪問最薄弱的環節。因此，就須要使用redis作一個緩衝操做，讓請求先訪問到redis，而不是直接訪問MySQL等數據庫。

這個業務場景，主要是解決讀數據從Redis緩存，通常都是按照下圖的流程來進行業務操做。

讀取緩存步驟通常沒有什麼問題，可是一旦涉及到數據更新：數據庫和緩存更新，就容易出現緩存(Redis)和數據庫（MySQL）間的數據一致性問題。

無論是先寫MySQL數據庫，再刪除Redis緩存；仍是先刪除緩存，再寫庫，都有可能出現數據不一致的狀況。舉一個例子：

1.若是刪除了緩存Redis，尚未來得及寫庫MySQL，另外一個線程就來讀取，發現緩存爲空，則去數據庫中讀取數據寫入緩存，此時緩存中爲髒數據。

2.若是先寫了庫，在刪除緩存前，寫庫的線程宕機了，沒有刪除掉緩存，則也會出現數據不一致狀況。

由於寫和讀是併發的，無法保證順序,就會出現緩存和數據庫的數據不一致的問題。

如來解決？這裏給出兩個解決方案，先易後難，結合業務和技術代價選擇使用。

緩存和數據庫一致性解決方案

1.第一種方案：採用延時雙刪策略

在寫庫先後都進行redis.del(key)操做，而且設定合理的超時時間。

僞代碼以下：

public void write(String key,Object data){

redis.delKey(key);

db.updateData(data);

Thread.sleep(500);

redis.delKey(key);

}

具體的步驟就是：

先刪除緩存；再寫數據庫；休眠500毫秒；再次刪除緩存。

那麼，這個500毫秒怎麼肯定的，具體該休眠多久呢？

須要評估本身的項目的讀數據業務邏輯的耗時。這麼作的目的，就是確保讀請求結束，寫請求能夠刪除讀請求形成的緩存髒數據。

固然這種策略還要考慮redis和數據庫主從同步的耗時。最後的的寫數據的休眠時間：則在讀數據業務邏輯的耗時基礎上，加幾百ms便可。好比：休眠1秒。

設置緩存過時時間

從理論上來講，給緩存設置過時時間，是保證最終一致性的解決方案。全部的寫操做以數據庫爲準，只要到達緩存過時時間，則後面的讀請求天然會從數據庫中讀取新值而後回填緩存。

該方案的弊端

結合雙刪策略+緩存超時設置，這樣最差的狀況就是在超時時間內數據存在不一致，並且又增長了寫請求的耗時。

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

技術總體思路：

MySQL binlog增量訂閱消費+消息隊列+增量數據更新到redis

讀Redis：熱數據基本都在Redis寫MySQL:增刪改都是操做MySQL更新Redis數據：MySQ的數據操做binlog，來更新到Redis

Redis更新

1）數據操做主要分爲兩大塊：

一個是全量(將所有數據一次寫入到redis)一個是增量（實時更新）

這裏說的是增量,指的是mysql的update、insert、delate變動數據。

2）讀取binlog後分析 ，利用消息隊列,推送更新各臺的redis緩存數據。

這樣一旦MySQL中產生了新的寫入、更新、刪除等操做，就能夠把binlog相關的消息推送至Redis，Redis再根據binlog中的記錄，對Redis進行更新。

其實這種機制，很相似MySQL的主從備份機制，由於MySQL的主備也是經過binlog來實現的數據一致性。

這裏能夠結合使用canal(阿里的一款開源框架)，經過該框架能夠對MySQL的binlog進行訂閱，而canal正是模仿了mysql的slave數據庫的備份請求，使得Redis的數據更新達到了相同的效果。

固然，這裏的消息推送工具你也能夠採用別的第三方：kafka、rabbitMQ等來實現推送更新Redis。

以上是Redis詳解，以爲不錯請點贊支持下。