Redis 使用過程中遇到的具體問題

1.緩存雪崩和緩存穿透問題

　　1.1緩存雪崩

　　　　簡介：緩存同一時間大面積的失效，所以，后面的請求都會落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。

　　解決辦法：

　　　　 事前：盡量保證整個 redis 集群的高可用性，發現機器宕機盡快補上。選擇合適的內存淘汰策略。

　　　　 事中： 本地 ehcache 緩存 + hystrix 限流&降級，避免 MySQL 崩掉

　　　　 事后：利用 redis 持久化機制保存的數據盡快恢復緩存

---

encache：

　　Ehcache是純java的開源緩存框架，具有快速、精干等特點，是Hibernate中默認的CacheProvider。它主要面向通用緩存、Java EE和輕量級容器，具有內存和磁盤存儲、緩存加載器、緩存擴展、緩存異常處理程序。

　　

應用場景：

　　使用純java的ehcache作為本地緩存
　　Reids 作為遠程分布式緩存
　　解決redis緩存壓力過大，提高緩存速度，以及緩存性能。

redis和Ehcache緩存的區別
　　如果是單個應用或者對緩存訪問要求很高的應用，用ehcache。
　　如果是大型系統，存在緩存共享、分布式部署、緩存內容很大的，建議用redis。

實際工作中使用Ehcache
　　我們在項目中使用集中式緩存(Redis或者式Memcached等)，通常都是檢查緩存中是否存在
期望值的數據，如果存在直接返回，如果不存在就查詢數據庫然后在將數據庫緩存，這個時候如果緩存系統因為某些原因宕機，造成服務無法訪問，那么大的量請求直接穿透到數據庫，最數據庫壓力非常大。

這時候我們讓ehcache作為二級緩存，當redis服務器宕機后，可以查詢ehcache緩存。
這樣能夠有效的扛住服務器請求壓力。
因此, 一般 Redis作為一級緩存, ehcache作為二級緩存。

---

hystrix :

　　簡介：在分布式系統中，單個應用通常會有多個不同類型的外部依賴服務，內部通常依賴於各種RPC服務，外部則依賴於各種HTTP服務。這些依賴服務不可避免的會出現調用失敗，比如超時、異常等情況，如何在外部依賴出問題的情況，仍然保證自身應用的穩定。Hystrix的目標就是能夠在1個或多個依賴出現問題時，系統依然可以穩定的運行，其手段包括隔離、限流和降級等。

服務限流:

　　通過線程池+隊列的方式，通過信號量的方式。比如商品評論比較慢，最大能同時處理10個線程，隊列待處理5個，那么如果同時20個線程到達的話，其中就有5個線程被限流了，其中10個先被執行，另外5個在隊列中

服務熔斷:

　　當依賴的服務有大量超時時，在讓新的請求去訪問根本沒有意義，只會無畏的消耗現有資源，比如我們設置了超時時間為1s，如果短時間內有大量請求在1s內都得不到響應，就意味着這個服務出現了異常，此時就沒有必要再讓其他的請求去訪問這個服務了，這個時候就應該使用熔斷器避免資源浪費

服務降級:

　　所謂降級，就是當某個服務熔斷之后，服務將不再被調用，此時客戶端可以自己准備一個本地的fallback（回退）回調，返回一個缺省值。 例如：(備用接口/緩存/mock數據)，這樣做，雖然服務水平下降，但好歹可用，比直接掛掉要強，當然這也要看適合的業務場景

 

---

 

 

　　1.2緩存穿透

　　　　 簡介：一般是黑客故意去請求緩存中不存在的數據，導致所有的請求都落到數據庫上，造成數據庫短時間內承受大量請求而崩掉。

　　 解決辦法： 有很多種方法可以有效地解決緩存穿透問題，最常見的則是采用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的 bitmap 中，一個一定不存在的數據被 這個 bitmap 攔截掉，從而避免了對底層存儲系統的查詢壓力。另外也有一個更為簡單粗暴的方法（我們采用的就是這種），如果一個查詢返回的數據為空（不管是數 據不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鍾。