什么是緩存擊穿

在談?wù)摼彺鎿舸┲?，我們先來回憶下從緩存中加載數(shù)據(jù)的邏輯，如下圖所示：

因此，如果黑客每次故意查詢一個在緩存內(nèi)必然不存在的數(shù)據(jù)，導(dǎo)致每次請求都要去存儲層去查詢，這樣緩存就失去了意義。如果在大流量下數(shù)據(jù)庫可能掛掉。這就是緩存擊穿。

場景如下圖所示：

我們正常人在登錄首頁的時候，都是根據(jù)userID來***數(shù)據(jù)，然而黑客的目的是破壞你的系統(tǒng)，黑客可以隨機生成一堆userID,然后將這些請求懟到你的服務(wù)器上，這些請求在緩存中不存在，就會穿過緩存，直接懟到數(shù)據(jù)庫上,從而造成數(shù)據(jù)庫連接異常。

解決方案

在這里我們給出三套解決方案，大家根據(jù)項目中的實際情況，選擇使用。

講下述三種方案前，我們先回憶下redis的setnx方法。

SETNX key value

將 key 的值設(shè)為 value ，當(dāng)且僅當(dāng) key 不存在。

若給定的 key 已經(jīng)存在，則 SETNX 不做任何動作。

SETNX 是『SET if Not eXists』(如果不存在，則 SET)的簡寫。

• 可用版本：>= 1.0.0
• 時間復(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ù)據(jù)庫加載，加載完畢，釋放鎖。若其他線程發(fā)現(xiàn)獲取鎖失敗，則睡眠50ms后重試。

至于鎖的類型，單機環(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)點

• 思路簡單
• 保證一致性

缺點

• 代碼復(fù)雜度增大
• 存在死鎖的風(fēng)險

2. 異步構(gòu)建緩存

在這種方案下，構(gòu)建緩存采取異步策略，會從線程池中取線程來異步構(gòu)建緩存，從而不會讓所有的請求直接懟到數(shù)據(jù)庫上。該方案redis自己維護一個timeout，當(dāng)timeout小于System.currentTimeMillis()時，則進行緩存更新，否則直接返回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()) { 
// 異步更新后臺異常執(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)點

• 性價***，用戶無需等待

缺點

• 無法保證緩存一致性

3. 布隆過濾器

(1) 原理

布隆過濾器的巨大用處就是，能夠迅速判斷一個元素是否在一個集合中。因此他有如下三個使用場景：

• 網(wǎng)頁爬蟲對URL的去重，避免爬取相同的URL地址
• 反垃圾郵件，從數(shù)十億個垃圾郵件列表中判斷某郵箱是否垃圾郵箱(同理，垃圾短信)
• 緩存擊穿，將已存在的緩存放到布隆過濾器中，當(dāng)黑客訪問不存在的緩存時迅速返回避免緩存及DB掛掉。

OK，接下來我們來談?wù)劜悸∵^濾器的原理。

其內(nèi)部維護一個全為0的bit數(shù)組，需要說明的是，布隆過濾器有一個誤判率的概念，誤判率越低，則數(shù)組越長，所占空間越大。誤判率越高則數(shù)組越小，所占的空間越小。

假設(shè)，根據(jù)誤判率，我們生成一個10位的bit數(shù)組，以及2個hash函數(shù)((f_1,f_2))，如下圖所示(生成的數(shù)組的位數(shù)和hash函數(shù)的數(shù)量，我們不用去關(guān)心是如何生成的，有數(shù)學(xué)論文進行過專業(yè)的證明)。

假設(shè)輸入集合為((N_1,N_2)),經(jīng)過計算(f_1(N_1))得到的數(shù)值得為2，(f_2(N_1))得到的數(shù)值為5，則將數(shù)組下標(biāo)為2和下表為5的位置置為1，如下圖所示：

同理，經(jīng)過計算(f_1(N_2))得到的數(shù)值得為3，(f_2(N_2))得到的數(shù)值為6，則將數(shù)組下標(biāo)為3和下表為6的位置置為1，如下圖所示：

這個時候，我們有第三個數(shù)(N_3)，我們判斷(N_3)在不在集合((N_1,N_2))中，就進行(f_1(N_3)，f_2(N_3))的計算

• 若值恰巧都位于上圖的紅色位置中，我們則認(rèn)為，(N_3)在集合((N_1,N_2))中
• 若值有一個不位于上圖的紅色位置中，我們則認(rèn)為，(N_3)不在集合((N_1,N_2))中

以上就是布隆過濾器的計算原理，下面我們進行性能測試，

(2) 性能測試

代碼如下：

a. 新建一個maven工程，引入guava包

<dependencies> 
<dependency> 
<groupId>com.google.guava</groupId> 
<artifactId>guava</artifactId> 
<version>22.0</version> 
</dependency> 
</dependencies> 

b. 測試一個元素是否屬于一個百萬元素集合所需耗時

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<Integer> 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ù)中是否包含29999這個數(shù) 
if (bloomFilter.mightContain(29999)) { 
System.out.println("***了"); 
} 
long endTime = System.nanoTime(); // 獲取結(jié)束時間 
System.out.println("程序運行時間： " + (endTime - startTime) + "納秒"); 
} 
} 

輸出如下所示：

***了 
程序運行時間： 219386納秒 

也就是說，判斷一個數(shù)是否屬于一個***別的集合，只要0.219ms就可以完成，性能***。

c. 誤判率的一些概念

首先，我們先不對誤判率做顯示的設(shè)置，進行一個測試，代碼如下所示：

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<Integer> bloomFilter =BloomFilter.create(Funnels.integerFunnel(), size); 
public static void main(String[] args) { 
for (int i = 0; i < size; i++) { 
bloomFilter.put(i); 
} 
List<Integer> list = new ArrayList<Integer>(1000); 
//故意取10000個不在過濾器里的值，看看有多少個會被認(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é)果如下：

誤判對數(shù)量：330 

如果上述代碼所示，我們故意取10000個不在過濾器里的值，卻還有330個被認(rèn)為在過濾器里，這說明了誤判率為0.03.即，在不做任何設(shè)置的情況下，默認(rèn)的誤判率為0.03。

下面上源碼來證明：

接下來我們來看一下，誤判率為0.03時，底層維護的bit數(shù)組的長度如下圖所示：

將bloomfilter的構(gòu)造方法改為：

private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), size,0.01); 

即，此時誤判率為0.01。在這種情況下，底層維護的bit數(shù)組的長度如下圖所示

由此可見，誤判率越低，則底層維護的數(shù)組越長，占用空間越大。因此，誤判率實際取值，根據(jù)服務(wù)器所能夠承受的負載來決定，不是拍腦袋瞎想的。

(3) 實際使用

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)點

• 思路簡單
• 保證一致性
• 性能強

缺點

• 代碼復(fù)雜度增大
• 需要另外維護一個集合來存放緩存的Key
• 布隆過濾器不支持刪值操作