2.1 什麼是快取穿透
正常情況下，我們去查詢資料都是存在。
那麼請求去查詢一條壓根兒資料庫中根本就不存在的資料，也就是快取和資料庫都查詢不到這條資料，但是請求每次都會打到資料庫上面去。
這種查詢不存在資料的現象我們稱為快取穿透。
2.2 穿透帶來的問題
試想一下，如果有黑客會對你的系統進行攻擊，拿乙個不存在的id 去查詢資料，會產生大量的請求到資料庫去查詢。可能會導致你的資料庫由於壓力過大而宕掉。
2.3 解決辦法
2.3.1 快取空值
之所以會發生穿透，就是因為快取中沒有儲存這些空資料的key。從而導致每次查詢都到資料庫去了。
那麼我們就可以為這些key對應的值設定為null 丟到快取裡面去。後面再出現查詢這個key 的請求的時候，直接返回null 。
這樣，就不用在到資料庫中去走一圈了，但是別忘了設定過期時間。
2.3.2 bloomfilter
bloomfilter 類似於乙個hbase set 用來判斷某個元素（key）是否存在於某個集合中。
這種方式在大資料場景應用比較多，比如 hbase 中使用它去判斷資料是否在磁碟上。還有在爬蟲場景判斷url 是否已經被爬取過。
這種方案可以加在第一種方案中，在快取之前在加一層 bloomfilter ，在查詢的時候先去 bloomfilter 去查詢 key 是否存在，如果不存在就直接返回，存在再走查快取 -> 查 db。
流程圖如下：
2.4 如何選擇
針對於一些惡意攻擊，攻擊帶過來的大量key 是不存在的，那麼我們採用第一種方案就會快取大量不存在key的資料。
此時我們採用第一種方案就不合適了，我們完全可以先對使用第二種方案進行過濾掉這些key。
針對這種key異常多、請求重複率比較低的資料，我們就沒有必要進行快取，使用第二種方案直接過濾掉。
而對於空資料的key有限的，重複率比較高的，我們則可以採用第一種方式進行快取。
3.1 什麼是擊穿
快取擊穿是我們可能遇到的第二個使用快取方案可能遇到的問題。
在平常高併發的系統中，大量的請求同時查詢乙個 key 時，此時這個key正好失效了，就會導致大量的請求都打到資料庫上面去。這種現象我們稱為快取擊穿。
3.2 會帶來什麼問題
會造成某一時刻資料庫請求量過大，壓力劇增。
3.3 如何解決
上面的現象是多個執行緒同時去查詢資料庫的這條資料，那麼我們可以在第乙個查詢資料的請求上使用乙個 互斥鎖來鎖住它。
其他的執行緒走到這一步拿不到鎖就等著，等第乙個執行緒查詢到了資料，然後做快取。後面的執行緒進來發現已經有快取了，就直接走快取。
4.1 什麼是快取雪崩
快取雪崩的情況是說，當某一時刻發生大規模的快取失效的情況，比如你的快取服務宕機了，會有大量的請求進來直接打到db上面。結果就是db 稱不住，掛掉。
4.2 解決辦法
4.2.1 事前：
這種方案就是在發生雪崩前對快取集群實現高可用，如果是使用 redis，可以使用 主從+哨兵 ，redis cluster 來避免 redis 全盤崩潰的情況。
4.2.2 事中：
使用 ehcache 本地快取的目的也是考慮在 redis cluster 完全不可用的時候，ehcache 本地快取還能夠支撐一陣。
使用 hystrix進行限流 & 降級 ，比如一秒來了5000個請求，我們可以設定假設只能有一秒 2000個請求能通過這個元件，那麼其他剩餘的 3000 請求就會走限流邏輯。
然後去呼叫我們自己開發的降級元件（降級），比如設定的一些預設值呀之類的。以此來保護最後的 mysql 不會被大量的請求給打死。
4.2.3 事後：
一旦重啟，就能從磁碟上自動載入資料恢復記憶體中的資料。
防止雪崩方案如下圖所示：
我們在設定快取的時候，一般會給快取設定乙個失效時間，過了這個時間，快取就失效了。
對於一些熱點的資料來說，當快取失效以後會存在大量的請求過來，然後打到資料庫去，從而可能導致資料庫崩潰的情況。
5.1 解決辦法
5.1.1 設定不同的失效時間
為了避免這些熱點的資料集中失效，那麼我們在設定快取過期時間的時候，我們讓他們失效的時間錯開。
比如在乙個基礎的時間上加上或者減去乙個範圍內的隨機值。
5.1.2 互斥鎖
結合上面的擊穿的情況，在第乙個請求去查詢資料庫的時候對他加乙個互斥鎖，其餘的查詢請求都會被阻塞住，直到鎖被釋放，從而保護資料庫。
但是也是由於它會阻塞其他的執行緒，此時系統吞吐量會下降。需要結合實際的業務去考慮是否要這麼做。
運維常見問題及解決策略
運維工作是專案工作的延續，是公司專案管理系統中的最後一環。接手運維工作也有一段時間了，遇見過各種各樣的客戶，處理過各種各樣的問題。在解決問題的過程中，發現每類專案都會有相似的問題出現，比如安全漏洞問題 後續系統接入的協助問題 產品出現bug等等，每一類問題都有它對應的解決方式和注意事項。本文將對運維...
快取相關問題及解決方案
快取穿透 查詢必然不存在的資料，請求透過快取，直擊資料庫 快取雪崩 大量的key設定了相同的過期時間，導致在快取在同一時刻全部失效，造成瞬時db請求量大 壓力驟增，引起雪崩 快取擊穿 乙個存在的key,在快取過期的一刻，同時有大量的請求。直擊資料庫順便說兩個概念加深一下記憶 tps 資料庫美妙執行的...
redis基礎及快取策略
我們都知道redis是基於記憶體,單執行緒機制工作，查詢速度快，效率高，一般在專案種常用來做快取，但是具體的快取策略是什麼呢？讀且成功 使用者從redis中讀取資料，如果讀取到了，直接使用 讀且失敗 如果使用者沒有從redis中讀取到資料，則去資料庫 一般是mysql 中讀取資料，然後將資料儲存到r...