介紹一下幾種快取使用遇到的場景
快取雪崩我們可以簡單的理解為：由於原有快取失效，新快取未到期間所有原本應該訪問快取的請求都
去查詢資料庫了，而對資料庫 cpu 和記憶體造成巨大壓力，嚴重的會造成資料庫宕機。從而形成一系列
連鎖反應，造成整個系統崩潰。一般有三種處理辦法：
1. 一般併發量不是特別多的時候，使用最多的解決方案是加鎖排隊。
2. 給每乙個快取資料增加相應的快取標記，記錄快取的是否失效，如果快取標記失效，則更新資料緩
存。 3. 為 key 設定不同的快取失效時間。
快取穿透是指使用者查詢資料，在資料庫沒有，自然在快取中也不會有。這樣就導致使用者查詢的時候，在
快取中找不到，每次都要去資料庫再查詢一遍，然後返回空（相當於進行了兩次無用的查詢）。這樣請
求就繞過快取直接查資料庫，這也是經常提的快取命中率問題。
有很多種方法可以有效地解決快取穿透問題，最常見的則是採用
布隆過濾器
，將所有可能存在的資料哈
希到乙個足夠大的 bitmap 中，乙個一定不存在的資料會被這個 bitmap 攔截掉，從而避免了對底層存
儲系統的查詢壓力。另外也有乙個更為簡單粗暴的方法，
如果乙個查詢返回的資料為空（不管是資料不
存在，還是系統故障），我們仍然把這個空結果進行快取，但它的過期時間會很短，最長不超過五分鐘。
通過這個直接設定的預設值存放到快取，這樣第二次到緩衝中獲取就有值了
，而不會繼續訪問資料庫。
快取擊穿是指快取中的乙個 key 失效時，此時針對該 key 有大量請求併發而來，那麼會對下游 elasticsearch 造成較大壓力。應對的方法和前面的「快取雪崩」類似。
快取預熱就是系統上線後，將相關的快取資料直接載入到快取系統。這樣就可以避免在使用者請求的時候，
先查詢資料庫，然後再將資料快取的問題！使用者直接查詢事先被預熱的快取資料！
快取更新除了快取伺服器自帶的快取失效策略之外（redis 預設的有 6 中策略可供選擇），我們還可以
根據具體的業務需求進行自定義的快取淘汰，常見的策略有兩種：
（1）定時去清理過期的快取；
（2）當有使用者請求過來時，再判斷這個請求所用到的快取是否過期，過期的話就去底層系統得到新數
據並更新快取。
當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的效能時，仍然
需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵資料進行自動降級，也可以配置開
關實現人工降級。降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的
（如加入購物車、結算）。
配置Redis作為快取
將 redis 用作快取時,如果記憶體空間用滿,就會自動驅逐老的資料。預設情況下 memcached 就是這種方式,大部分開發者都比較熟悉。lru是redis唯一支援的 演算法.本文詳細介紹用於限制最大記憶體使用量的maxmemory指令,並深入講解 redis 所使用的近似lru演算法。maxme...
新增redis快取 作為使用者查詢的快取
ssm框架 windows系統 jdk13 1.首先匯入依賴 redis.clients jedis 2.7.3 com.dyuproject.protostuff protostuff core 1.0.8 com.dyuproject.protostuff protostuff runtime ...
使用Redis作為LRU快取
當 redis 作為快取使用時，當你新增新的資料時，有時候很方便使 redis 自動 老的資料。lru 實際上是被唯一支援的資料移除方法。redis 的 maxmemory 指令，用於限制記憶體使用到乙個固定的容量，也包含深入 redis 使用的 lru 演算法，乙個近似準確的 lru。maxmem...