1.緩存雪崩和緩存穿透問題 1.1緩存雪崩 簡介：緩存同一時間大面積的失效，所以，後面的請求都會落到資料庫上，造成資料庫短時間內承受大量請求而崩掉。 解決辦法： 事前：儘量保證整個 redis 集群的高可用性，發現機器宕機儘快補上。選擇合適的記憶體淘汰策略。 事中：本地 ehcache 緩存 ...
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 攔截掉，從而避免了對底層存儲系統的查詢壓力。另外也有一個更為簡單粗暴的方法（我們採用的就是這種），如果一個查詢返回的數據為空（不管是數 據不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鐘。
