建站
咨詢
售后
建站咨詢
新聞中心
什么是緩存擊穿
創(chuàng)新互聯(lián)公司于2013年成立，先為古雷港等服務(wù)建站，古雷港等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為古雷港企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
在談?wù)摼彺鎿舸┲?，我們先來回憶下從緩存中加載數(shù)據(jù)的邏輯，如下圖所示：
因此，如果黑客每次故意查詢一個(gè)在緩存內(nèi)必然不存在的數(shù)據(jù)，導(dǎo)致每次請(qǐng)求都要去存儲(chǔ)層去查詢，這樣緩存就失去了意義。如果在大流量下數(shù)據(jù)庫可能掛掉。這就是緩存擊穿。
場(chǎng)景如下圖所示：
我們正常人在登錄首頁的時(shí)候，都是根據(jù)userID來***數(shù)據(jù)，然而黑客的目的是破壞你的系統(tǒng)，黑客可以隨機(jī)生成一堆userID,然后將這些請(qǐng)求懟到你的服務(wù)器上，這些請(qǐng)求在緩存中不存在，就會(huì)穿過緩存，直接懟到數(shù)據(jù)庫上,從而造成數(shù)據(jù)庫連接異常。
解決方案
在這里我們給出三套解決方案，大家根據(jù)項(xiàng)目中的實(shí)際情況，選擇使用。
講下述三種方案前，我們先回憶下redis的setnx方法。
SETNX key value
將 key 的值設(shè)為 value ，當(dāng)且僅當(dāng) key 不存在。
若給定的 key 已經(jīng)存在，則 SETNX 不做任何動(dòng)作。
SETNX 是『SET if Not eXists』(如果不存在，則 SET)的簡(jiǎn)寫。
- 可用版本：>= 1.0.0
- 時(shí)間復(fù)雜度： O(1)
- 返回值： 設(shè)置成功，返回 1。設(shè)置失敗，返回 0 。
效果如下：
- redis> EXISTS job # job 不存在
- (integer) 0
- redis> SETNX job "programmer" # job 設(shè)置成功
- (integer) 1
- redis> SETNX job "code-farmer" # 嘗試覆蓋 job ，失敗
- (integer) 0
- redis> GET job # 沒有被覆蓋
- "programmer"
1. 使用互斥鎖
該方法是比較普遍的做法，即，在根據(jù)key獲得的value值為空時(shí)，先鎖上，再從數(shù)據(jù)庫加載，加載完畢，釋放鎖。若其他線程發(fā)現(xiàn)獲取鎖失敗，則睡眠50ms后重試。
至于鎖的類型，單機(jī)環(huán)境用并發(fā)包的Lock類型就行，集群環(huán)境則使用分布式鎖( redis的setnx)。
集群環(huán)境的redis的代碼如下所示：
- String get(String key) {
- String value = redis.get(key);
- if (value == null) {
- if (redis.setnx(key_mutex, "1")) {
- // 3 min timeout to avoid mutex holder crash
- redis.expire(key_mutex, 3 * 60)
- value = db.get(key);
- redis.set(key, value);
- redis.delete(key_mutex);
- } else {
- //其他線程休息50毫秒后重試
- Thread.sleep(50);
- get(key);
- }
- }
- }
優(yōu)點(diǎn)
- 思路簡(jiǎn)單
- 保證一致性
缺點(diǎn)
- 代碼復(fù)雜度增大
- 存在死鎖的風(fēng)險(xiǎn)
2. 異步構(gòu)建緩存
在這種方案下，構(gòu)建緩存采取異步策略，會(huì)從線程池中取線程來異步構(gòu)建緩存，從而不會(huì)讓所有的請(qǐng)求直接懟到數(shù)據(jù)庫上。該方案redis自己維護(hù)一個(gè)timeout，當(dāng)timeout小于System.currentTimeMillis()時(shí)，則進(jìn)行緩存更新，否則直接返回value值。
集群環(huán)境的redis代碼如下所示：
- String get(final String key) {
- V v = redis.get(key);
- String vvalue = v.getValue();
- long timeout = v.getTimeout();
- if (v.timeout <= System.currentTimeMillis()) {
- // 異步更新后臺(tái)異常執(zhí)行
- threadPool.execute(new Runnable() {
- public void run() {
- String keyMutex = "mutex:" + key;
- if (redis.setnx(keyMutex, "1")) {
- // 3 min timeout to avoid mutex holder crash
- redis.expire(keyMutex, 3 * 60);
- String dbdbValue = db.get(key);
- redis.set(key, dbValue);
- redis.delete(keyMutex);
- }
- }
- });
- }
- return value;
- }
優(yōu)點(diǎn)
- 性價(jià)***，用戶無需等待
缺點(diǎn)
- 無法保證緩存一致性
3. 布隆過濾器
(1) 原理
布隆過濾器的巨大用處就是，能夠迅速判斷一個(gè)元素是否在一個(gè)集合中。因此他有如下三個(gè)使用場(chǎng)景：
- 網(wǎng)頁爬蟲對(duì)URL的去重，避免爬取相同的URL地址
- 反垃圾郵件，從數(shù)十億個(gè)垃圾郵件列表中判斷某郵箱是否垃圾郵箱(同理，垃圾短信)
- 緩存擊穿，將已存在的緩存放到布隆過濾器中，當(dāng)黑客訪問不存在的緩存時(shí)迅速返回避免緩存及DB掛掉。
OK，接下來我們來談?wù)劜悸∵^濾器的原理。
其內(nèi)部維護(hù)一個(gè)全為0的bit數(shù)組，需要說明的是，布隆過濾器有一個(gè)誤判率的概念，誤判率越低，則數(shù)組越長(zhǎng)，所占空間越大。誤判率越高則數(shù)組越小，所占的空間越小。
假設(shè)，根據(jù)誤判率，我們生成一個(gè)10位的bit數(shù)組，以及2個(gè)hash函數(shù)((f_1,f_2))，如下圖所示(生成的數(shù)組的位數(shù)和hash函數(shù)的數(shù)量，我們不用去關(guān)心是如何生成的，有數(shù)學(xué)論文進(jìn)行過專業(yè)的證明)。
假設(shè)輸入集合為((N_1,N_2)),經(jīng)過計(jì)算(f_1(N_1))得到的數(shù)值得為2，(f_2(N_1))得到的數(shù)值為5，則將數(shù)組下標(biāo)為2和下表為5的位置置為1，如下圖所示：
同理，經(jīng)過計(jì)算(f_1(N_2))得到的數(shù)值得為3，(f_2(N_2))得到的數(shù)值為6，則將數(shù)組下標(biāo)為3和下表為6的位置置為1，如下圖所示：
這個(gè)時(shí)候，我們有第三個(gè)數(shù)(N_3)，我們判斷(N_3)在不在集合((N_1,N_2))中，就進(jìn)行(f_1(N_3)，f_2(N_3))的計(jì)算
- 若值恰巧都位于上圖的紅色位置中，我們則認(rèn)為，(N_3)在集合((N_1,N_2))中
- 若值有一個(gè)不位于上圖的紅色位置中，我們則認(rèn)為，(N_3)不在集合((N_1,N_2))中
以上就是布隆過濾器的計(jì)算原理，下面我們進(jìn)行性能測(cè)試，
(2) 性能測(cè)試
代碼如下：
a. 新建一個(gè)maven工程，引入guava包
com.google.guava guava 22.0
b. 測(cè)試一個(gè)元素是否屬于一個(gè)百萬元素集合所需耗時(shí)
- package bloomfilter;
- import com.google.common.hash.BloomFilter;
- import com.google.common.hash.Funnels;
- import java.nio.charset.Charset;
- public class Test {
- private static int size = 1000000;
- private static BloomFilter
bloomFilter =BloomFilter.create(Funnels.integerFunnel(), size); - public static void main(String[] args) {
- for (int i = 0; i < size; i++) {
- bloomFilter.put(i);
- }
- long startTime = System.nanoTime(); // 獲取開始時(shí)間
- //判斷這一百萬個(gè)數(shù)中是否包含29999這個(gè)數(shù)
- if (bloomFilter.mightContain(29999)) {
- System.out.println("***了");
- }
- long endTime = System.nanoTime(); // 獲取結(jié)束時(shí)間
- System.out.println("程序運(yùn)行時(shí)間： " + (endTime - startTime) + "納秒");
- }
- }
輸出如下所示：
- ***了
- 程序運(yùn)行時(shí)間： 219386納秒
也就是說，判斷一個(gè)數(shù)是否屬于一個(gè)***別的集合，只要0.219ms就可以完成，性能***。
c. 誤判率的一些概念
首先，我們先不對(duì)誤判率做顯示的設(shè)置，進(jìn)行一個(gè)測(cè)試，代碼如下所示：
- package bloomfilter;
- import java.util.ArrayList;
- import java.util.List;
- import com.google.common.hash.BloomFilter;
- import com.google.common.hash.Funnels;
- public class Test {
- private static int size = 1000000;
- private static BloomFilter
bloomFilter =BloomFilter.create(Funnels.integerFunnel(), size); - public static void main(String[] args) {
- for (int i = 0; i < size; i++) {
- bloomFilter.put(i);
- }
- List
list = new ArrayList (1000); - //故意取10000個(gè)不在過濾器里的值，看看有多少個(gè)會(huì)被認(rèn)為在過濾器里
- for (int i = size + 10000; i < size + 20000; i++) {
- if (bloomFilter.mightContain(i)) {
- list.add(i);
- }
- }
- System.out.println("誤判的數(shù)量：" + list.size());
- }
- }
輸出結(jié)果如下：
- 誤判對(duì)數(shù)量：330
如果上述代碼所示，我們故意取10000個(gè)不在過濾器里的值，卻還有330個(gè)被認(rèn)為在過濾器里，這說明了誤判率為0.03.即，在不做任何設(shè)置的情況下，默認(rèn)的誤判率為0.03。
下面上源碼來證明：
接下來我們來看一下，誤判率為0.03時(shí)，底層維護(hù)的bit數(shù)組的長(zhǎng)度如下圖所示：
將bloomfilter的構(gòu)造方法改為：
- private static BloomFilter
bloomFilter = BloomFilter.create(Funnels.integerFunnel(), size,0.01);
即，此時(shí)誤判率為0.01。在這種情況下，底層維護(hù)的bit數(shù)組的長(zhǎng)度如下圖所示
由此可見，誤判率越低，則底層維護(hù)的數(shù)組越長(zhǎng)，占用空間越大。因此，誤判率實(shí)際取值，根據(jù)服務(wù)器所能夠承受的負(fù)載來決定，不是拍腦袋瞎想的。
(3) 實(shí)際使用
redis偽代碼如下所示：
- String get(String key) {
- String value = redis.get(key);
- if (value == null) {
- if(!bloomfilter.mightContain(key)){
- return null;
- }else{
- value = db.get(key);
- redis.set(key, value);
- }
- }
- return value；
- }
優(yōu)點(diǎn)
- 思路簡(jiǎn)單
- 保證一致性
- 性能強(qiáng)
缺點(diǎn)
- 代碼復(fù)雜度增大
- 需要另外維護(hù)一個(gè)集合來存放緩存的Key
- 布隆過濾器不支持刪值操作
分享題目：詳解Redis緩存擊穿以及解決方案
鏈接地址：http://www.5511xx.com/article/dhiggde.html
