使用場景和優缺點：
2 Redis用來做什么？
通常局限點來說，Redis也以消息隊列的形式存在，作為內嵌的List存在，滿足實時的高並發需求。而通常在一個電商類型的數據處理過程之中，有關商品，熱銷，推薦排序的隊列，通常存放在Redis之中，期間也包擴Storm對於Redis列表的讀取和更新。
Redis的優點
性能極高 – Redis能支持超過 100K+ 每秒的讀寫頻率。
豐富的數據類型 – Redis支持二進制案例的 Strings, Lists, Hash, Sets 及 Ordered Sets 數據類型操作。
原子 – Redis的所有操作都是原子性的，同時Redis還支持對幾個操作全並后的原子性執行。
豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過期等等特性。
redis的缺點
是數據庫容量受到物理內存的限制,不能用作海量數據的高性能讀寫,因此Redis適合的場景主要局限在較小數據量的高性能操作和運算上。
總結： Redis受限於特定的場景，專注於特定的領域之下，速度相當之快，目前還未找到能替代使用產品
一、前言
在我們日常的開發中，無不都是使用數據庫來進行數據的存儲，由於一般的系統任務中通常不會存在高並發的情況，所以這樣看起來並沒有什么問題，可是一旦涉及大數據量的需求，比如一些商品搶購的情景，或者是主頁訪問量瞬間較大的時候，單一使用數據庫來保存數據的系統會因為面向磁盤，磁盤讀/寫速度比較慢的問題而存在嚴重的性能弊端，一瞬間成千上萬的請求到來，需要系統在極短的時間內完成成千上萬次的讀/寫操作，這個時候往往不是數據庫能夠承受的，極其容易造成數據庫系統癱瘓，最終導致服務宕機的嚴重生產問題。
為了克服上述的問題，項目通常會引入NoSQL技術，這是一種基於內存的數據庫，並且提供一定的持久化功能。
redis技術就是NoSQL技術中的一種，但是引入redis又有可能出現緩存穿透，緩存擊穿，緩存雪崩等問題。本文就對這三種問題進行較深入剖析。
二、初認識
緩存穿透：key對應的數據在數據源並不存在，每次針對此key的請求從緩存獲取不到，請求都會到數據源，從而可能壓垮數據源，比如對一個不存在的用戶id獲取用戶信息，不論緩存還是數據庫都沒有，若黑客利用此漏洞進行攻擊可能壓垮數據庫
緩存擊穿：key對應的數據存在，但是redis中過期，此時若大量並發請求過來，這些請求緩存過期一般都會從后端DB加載數據並回設到緩存，這個時候大並發的請求可能會瞬間把后端DB壓垮
緩存雪崩：當緩存服務器重啟或者大量緩存集中在某一個時間段失效，這樣在失效的時候，也會對后端系統帶來很大壓力
三、緩存穿透解決方案
有很多種方法可以有效地解決緩存穿透問題，最常見的則是采用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的bitmap中，一個一定不存在的數據會被 這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。另外也有一個更為簡單粗暴的方法（我們采用的就是這種），如果一個查詢返回的數據為空（不管是數據不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鍾。
//偽代碼 public object GetProductListNew() { int cacheTime = 30; String cacheKey = "product_list"; String cacheValue = CacheHelper.Get(cacheKey); if (cacheValue != null) { return cacheValue; } cacheValue = CacheHelper.Get(cacheKey); if (cacheValue != null) { return cacheValue; } else { //數據庫查詢不到，為空 cacheValue = GetProductListFromDB(); if (cacheValue == null) { //如果發現為空，設置個默認值，也緩存起來 cacheValue = string.Empty; } CacheHelper.Add(cacheKey, cacheValue, cacheTime); return cacheValue; } }
四、緩存擊穿解決方案
key可能會在某些時間點被超高並發地訪問，是一種非常“熱點”的數據。這個時候，需要考慮一個問題：緩存被“擊穿”的問題。
使用互斥鎖(mutex key)
業界比較常用的做法，是使用mutex。簡單地來說，就是在緩存失效的時候（判斷拿出來的值為空），不是立即去load db，而是先使用緩存工具的某些帶成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一個mutex key，當操作返回成功時，再進行load db的操作並回設緩存；否則，就重試整個get緩存的方法。
public String get(key) { String value = redis.get(key); if (value == null) { //代表緩存值過期 //設置3min的超時，防止del操作失敗的時候，下次緩存過期一直不能load db if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { //代表設置成功 value = db.get(key); redis.set(key, value, expire_secs); redis.del(key_mutex); } else { //這個時候代表同時候的其他線程已經load db並回設到緩存了，這時候重試獲取緩存值即可 sleep(50); get(key); //重試 } } else { return value; } }
五、緩存雪崩解決方案
與緩存擊穿的區別在於這里針對很多key緩存，前者則是某一個key。
緩存正常從Redis中獲取，示意圖如下：
緩存失效瞬間示意圖如下：
緩存失效時的雪崩效應對底層系統的沖擊非常可怕！大多數系統設計者考慮用加鎖或者隊列的方式保證來保證不會有大量的線程對數據庫一次性進行讀寫，從而避免失效時大量的並發請求落到底層存儲系統上。還有一個簡單方案就時講緩存失效時間分散開，比如我們可以在原有的失效時間基礎上增加一個隨機值，比如1-5分鍾隨機，這樣每一個緩存的過期時間的重復率就會降低，就很難引發集體失效的事件。
關於緩存崩潰的解決方法，這里提出了三種方案：使用鎖或隊列、設置過期標志更新緩存、為key設置不同的緩存失效時間，還有一種被稱為“二級緩存”的解決方法。