1為什麼需要緩存
- 如果沒有緩存，那麼所有業務請求會直接指向數據庫，以MySQL為例的數據庫基本都是基於磁盤的，而磁盤I/O開銷大，面對大規模請求時，會降低系統性能。
- 對一些熱點數據，將其從數據庫中抽離出來放進緩存，每次查詢時先走緩存，緩存命中則直接返回結果，能提高效率。
2緩存帶來的問題
有三個經典問題：
- 緩存雪崩：指緩存大面積失效，導致大量查詢落到了數據庫上，使數據庫掛掉。
- 緩存擊穿：緩存中熱點key突然失效，原本走緩存的大量請求直接打向了數據庫，就好像在緩存中擊穿了一個洞。
- 緩存穿透：用戶一直請求緩存和數據庫都不存在的數據，每次請求緩存不命中，數據庫也不命中，就像緩存不存在一樣，同時不斷地請求也給數據庫帶來壓力。
3應對方案
這裡主要介紹 緩存穿透 的解決方案，先看兩幅原理圖。
用戶請求大致原理圖：
用戶發出請求後先查緩存，緩存命中則直接返回；
緩存不命中就查數據庫，查到後將數據寫入緩存並返回給用戶。
用戶請求緩存和數據庫都沒有的數據（即緩存穿透，如請求id=-1的數據）：
此時緩存基本失去了作用。
常見的解決思路：
將用戶請求的不存在的數據也放進緩存，並將值置為null，這樣請求走緩存的時候發現結果為null，直接返回即可。
但是需要給緩存中的key設置一個合適的過期時間，否則數據庫中有了這樣的數據，就會出現 數據不一致 問題。
更好的解決思路：
使用 布隆過濾器（Bloom Filter） 。 它可用於快速判斷數據是否存在於某個集合中，藉助這個功能，我們可用它來應對緩存穿透。
回顧一下布隆過濾器的兩條重要特性：
1. 布隆過濾器判定數據存在，那麼它可能存在也可能不存在。
2. 布隆過濾器判定數據不存在，那麼它一定不存在。
加上布隆過濾器之後：
用戶請求數據，若Bloom Filter返回false，則直接過濾該請求或返回null；若 Bloom Filter 返回true，則查緩存，緩存命中則返回，不命中則查數據庫。
Bloom Filter 就好像是加在緩存前的一道 屏障 ，過濾了幾乎所有不符合要求的請求。雖然有一定的誤判率，即可能有少數通過了 Blo om Filter 的請求在數據庫和緩存中也還是不命中，但相比之下，整個系統性能已經大大提升，且 Blo om Filter 的默認誤判率只有0.03.
順帶提一下緩存擊穿和緩存雪崩的解決方案。
緩存擊穿：
在被查詢的數據上加互斥鎖，一條請求線程拿到鎖後其它線程只能等待。
緩存雪崩：
事前：儘量保證整個 redis 集群的高可用性，發現機器宕機儘快補上。選擇合適的內存淘汰策略。
事中：本地ehcache緩存 + hystrix限流&降級，避免MySQL崩掉。
事後：利用 redis 持久化機制保存的數據儘快恢復緩存。
閱讀更多 sandag 的文章
