在并發式的項目當中,一定要考慮一個緩存穿透的情況。那么什么是緩存穿透呢?簡單的說來,就是當大量請求的key根本不在緩存當中,所以導致了請求直接到了數據庫上,根本沒有經過緩存這一層。比如一個黑客故意制造我們緩存中不存在的key發送大量的請求,就會導致請求直接落到數據庫上。
也就是說,緩存穿透就是:1.緩存層不命中。2,存儲層不命中,不將空的結果寫回緩存。3,返回空結果給客戶端。
一般mysql的默認最大連接數是150左右,當然這個是可以用show variables like ‘%max_connections%'命令來查看。
當然這只是一個指標,cpu磁盤內存網絡等等原因都影響了他的并發能力,所以一般3000的并發請求就可以殺死大部分的數據庫。
那么出現緩存穿透的時候需要怎么應對呢?
1)最基本的方式就是做好參數校檢,比如不合法的請求就直接拋出異常信息給客戶端,就比如設置查詢條件id不能小于0或者傳入郵箱格式不正確時直接返回錯誤消息給客戶端。但是這樣還是會出現緩存穿透的現象。那么還可以通過下面幾個方案來解決:
2)緩存無效的key,如果數據庫和緩存都找不到某個key的數據,就直接寫一個到redis中并設置它的過期時間 set key value EX 10086。這種方式可以解決請求的key變化不頻繁的情況,如果遇到專門的黑客攻擊就不能解決這個情況。但是如果依然想用這個方法的話,那么在設置過期時間的時候,時間短一點,比如是一分鐘。多說一句設置key的格式一般是:表名:列名:主鍵名:主鍵。
3)利用布隆過濾器:布隆過濾器是一個非常神奇的數據結構,通過這個過濾器可以幫助我們非常方便的去判斷一個給定的數據是否存在于海量的數據當中。所以布隆過濾器在針對數據去重和驗證數據的合法性時是非常有用的,布隆過濾器的實質就是一個bit(位)數組。也就是說每一個存進的數據都僅僅只占一位,在數據結構上來說相當于List、Map、Set等數據結構,但是占用的空間更少而且效率更高,但是缺點是它返回的值是概率性的,并不是多么的準確。當一個元素加入到布隆過濾器的時候:1.使用布隆過濾器當中的哈希函數對元素值進行計算,得到哈希值。2.根據得到的哈希值,在位數組中把對應的下標改為1。那么設置完成之后,我們要怎么判斷一個元素是否存在于布隆過濾器當中呢?
首先我們要根據給定的元素再次進行hash計算;得到值之后判斷數組中的每個元素是否都為1,如果值都為1的話,那么說明這個值在過濾器當中,如果不為1的話,就說明不再過濾器當中。
舉個非常簡單的例子

如上圖所示,當字符串要加入到布隆過濾器當中時,該事務首先由多個哈希函數生成不同的哈希值,然后在對應的位數組的下標的元素設置位1,當二次存儲相同的字符串時,因為先前的對應位置已經存在,所以在去重的時候非常方便。如果我們需要判斷某個字符串是否在布隆過濾器當中時,只需要對給定的字符串再次進行相同的哈希計算,得到的值判斷是否為1,從而判斷數據是否存在于布隆過濾器當中,那么假如布隆過濾器說明一個數據存在時,很小的概率會誤判,但是如果說明一個數據不存在時,那么一定是不存在的。
那么通過這個原理,利用redis布隆過濾器來將所有可能存在請求的值放在布隆過濾器當中,當用戶請求時,直接判斷用戶發送來的請求是否存在于布隆過濾器中,不存在的話,直接返回請求參數錯誤信息給客戶,存在的話就繼續往下面走流程。

以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持腳本之家。
您可能感興趣的文章:- Redis分析慢查詢操作的實例教程
- 淺析JavaWeb項目架構之Redis分布式日志隊列
- java獲取redis日志信息與動態監控信息的方法
- 如何高效使用Redis作為LRU緩存
- Linux安裝Redis實現過程及報錯解決方案
- spring boot+redis 監聽過期Key的操作方法
- Redis面試必會的題目
- 在Docker中使用Redis的步驟詳解
- SpringBoot2.3整合redis緩存自定義序列化的實現
- Redis 執行性能測試
- Redis緩存常用4種策略原理詳解
- 詳解Redis的慢查詢日志