【分布式框架】深入理解分布式之緩存擊穿

前言

在談?wù)摼彺鎿舸┲埃覀兿葋砘貞浵聫木彺嬷屑虞d數(shù)據(jù)的邏輯，如下圖所示：

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

場景如下圖所示:

我們正常人在登錄首頁的時(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)的簡寫。

可用版本：>= 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

2

3

4

5

6

7

8

9

10

11

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); } } }

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

優(yōu)點(diǎn)：

1.思路簡單

2.保證一致性

缺點(diǎn)

1.代碼復(fù)雜度增大

2.存在死鎖的風(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 value = 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 dbValue = db.get(key); redis.set(key, dbValue); redis.delete(keyMutex); } } }); } return value; }

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

優(yōu)點(diǎn)：

1.性價(jià)最佳，用戶無需等待

缺點(diǎn)

1.無法保證緩存一致性

3、布隆過濾器

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

1.網(wǎng)頁爬蟲對(duì)URL的去重，避免爬取相同的URL地址

2.反垃圾郵件，從數(shù)十億個(gè)垃圾郵件列表中判斷某郵箱是否垃圾郵箱（同理，垃圾短信）

3.緩存擊穿，將已存在的緩存放到布隆過濾器中，當(dāng)黑客訪問不存在的緩存時(shí)迅速返回避免緩存及DB掛掉。

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

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

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

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

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

這個(gè)時(shí)候，我們有第三個(gè)數(shù)N3，我們判斷N3在不在集合(N1,N2)中，就進(jìn)行f1(N3)，f2(N3)的計(jì)算

1.若值恰巧都位于上圖的紅色位置中，我們則認(rèn)為，N3在集合(N1,N2)中

2.若值有一個(gè)不位于上圖的紅色位置中，我們則認(rèn)為，N3不在集合(N1,N2)中

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

代碼如下：

com.google.guava guava 22.0

1

2

3

4

5

6

7

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) + "納秒"); } }

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

輸出如下所示

命中了 程序運(yùn)行時(shí)間： 219386納秒

也就是說，判斷一個(gè)數(shù)是否屬于一個(gè)百萬級(jí)別的集合，只要0.219ms就可以完成，性能極佳。

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

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()); } }

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

輸出結(jié)果如下

誤判對(duì)數(shù)量：330

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

下面上源碼來證明：

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

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

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

1

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

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

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； }

1

2

3

4

5

6

7

8

9

10

11

12

優(yōu)點(diǎn)：

1.思路簡單

2.保證一致性

3.性能強(qiáng)

缺點(diǎn)

1.代碼復(fù)雜度增大

2.需要另外維護(hù)一個(gè)集合來存放緩存的Key

3.布隆過濾器不支持刪值操作

最后

我這邊整理了一份分布式相關(guān)資料文檔、Spring系列全家桶、Java的系統(tǒng)化資料：（包括Java核心知識(shí)點(diǎn)、面試專題和21年最新的互聯(lián)網(wǎng)真題、電子書等）有需要的朋友可以關(guān)注公眾號(hào)【程序媛小琬】即可獲取。

分布式

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。