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 攔截掉，從而避免了對底層存儲系統的查詢壓力。另外也有一個更爲簡單粗暴的方法（咱們採用的就是這種），若是一個查詢返回的數據爲空（不論是數 據不存在，仍是系統故障），咱們仍然把這個空結果進行緩存，但它的過時時間會很短，最長不超過五分鐘。