緩存穿透
去緩存層沒有命中數(shù)據(jù)，進(jìn)而去mysql中查詢數(shù)據(jù)启上。
低頻的緩存穿透是無(wú)法并避免的邢隧，我們需要盡量避免高頻的數(shù)據(jù)。
解決辦法
1） 存儲(chǔ)null值
將查詢的結(jié)果為null的鍵存入redis中冈在，這樣下次找個(gè)鍵再來的時(shí)候就不用走mysql了府框，直接從redis返回。
問題:
- 若后期該鍵結(jié)果被其他線程所修改讥邻，可能會(huì)造成數(shù)據(jù)不一致的問題
- 若黑客采用UUID等形式不斷地訪問，不斷無(wú)法抵抗緩存擊穿問題院峡，而且會(huì)在redis中生成大量null值的鍵兴使，當(dāng)內(nèi)存不足，Redis啟動(dòng)LRU照激，LFU等置換策略发魄，會(huì)替換掉原本正常的緩存，從而加劇問題俩垃。
2） 布隆過濾器
通過一定的錯(cuò)誤率換取空間励幼。通過bit數(shù)組來標(biāo)識(shí)數(shù)據(jù)。映射一個(gè)值到布隆過濾器中口柳，使用多個(gè)不同的哈希函數(shù)生成多個(gè)哈希值苹粟，并對(duì)每個(gè)生成的哈希值指向的 bit 位置 1。由于存在hash碰撞跃闹，所以導(dǎo)致可能誤判嵌削。
降低錯(cuò)誤率的途徑：
- 增加數(shù)組的長(zhǎng)度
但是會(huì)造成空間增大 - 增加Hash函數(shù)的個(gè)數(shù)
若太多，那么數(shù)組將會(huì)很快填滿望艺，所以個(gè)數(shù)不是越多越好苛秕，需要參考數(shù)組的長(zhǎng)度
Hash錯(cuò)誤率：
若數(shù)據(jù)存在，那么實(shí)際可能不存在（發(fā)生hash碰撞）
若數(shù)據(jù)不存在找默，那么一定不存在（沒標(biāo)記過）
但是當(dāng)刪除數(shù)據(jù)時(shí)艇劫，可能會(huì)有問題，不能輕易的刪除惩激，這時(shí)可以考慮采用二維數(shù)組店煞，沒標(biāo)1位進(jìn)行計(jì)數(shù)，當(dāng)計(jì)數(shù)位0是將該位置0咧欣。
緩存雪崩
緩存層中緩存的數(shù)據(jù)浅缸，再某一個(gè)時(shí)刻突然失效（無(wú)法訪問）導(dǎo)致大量的請(qǐng)求打向mysql數(shù)據(jù)庫(kù)。
產(chǎn)生原因:
- redis中緩存的數(shù)據(jù)有效性一直導(dǎo)致的
解決：給每條數(shù)據(jù)加上一個(gè)隨機(jī)有效期（不要突然同時(shí)失效） - redis數(shù)據(jù)庫(kù)掛掉了
解決：分布式緩存
緩存擊穿
一個(gè)存在的key魄咕，在緩存過期的一刻衩椒，同時(shí)有大量的請(qǐng)求，這些請(qǐng)求都會(huì)擊穿到DB，造成瞬時(shí)DB請(qǐng)求量大毛萌、壓力驟增苟弛。
解決：
使用分布式鎖來解決
- 基于mysql實(shí)現(xiàn)
容易出現(xiàn)死鎖，且效率不高 - 基于zookeeper實(shí)現(xiàn)
- 基于redis實(shí)現(xiàn)
Redis集群的Hash一致性算法
一致性Hash算法將整個(gè)Hash值控件組織成一個(gè)虛擬的圓環(huán)阁将，對(duì) 取模膏秫。
將各個(gè)服務(wù)器使用Hash進(jìn)行一個(gè)哈希，具體可以選擇服務(wù)器的IP或主機(jī)名作為關(guān)鍵字進(jìn)行哈希做盅，這樣每臺(tái)機(jī)器就能確定其在哈希環(huán)上的位置缤削，這里假設(shè)將上文中四臺(tái)服務(wù)器使用IP地址哈希后在環(huán)空間的位置如下：
將數(shù)據(jù)key使用相同的函數(shù)Hash計(jì)算出哈希值，并確定此數(shù)據(jù)在環(huán)上的位置吹榴，從此位置沿環(huán)順時(shí)針“行走”亭敢，第一臺(tái)遇到的服務(wù)器就是其應(yīng)該定位到的服務(wù)器！
現(xiàn)假設(shè)Node C不幸宕機(jī)图筹，可以看到此時(shí)對(duì)象A帅刀、B、D不會(huì)受到影響远剩，只有C對(duì)象被重定位到Node D扣溺。一般的，在一致性Hash算法中瓜晤，如果一臺(tái)服務(wù)器不可用锥余，則受影響的數(shù)據(jù)僅僅是此服務(wù)器到其環(huán)空間中前一臺(tái)服務(wù)器（即沿著逆時(shí)針方向行走遇到的第一臺(tái)服務(wù)器，如下圖中NodeC與NodeB之間的數(shù)據(jù)活鹰，圖中受影響的是ObjectC）之間數(shù)據(jù)哈恰，其它不會(huì)受到影響。
如果在系統(tǒng)中增加一臺(tái)服務(wù)器Node X志群，如下圖所示：
此時(shí)對(duì)象Object A着绷、B、D不受影響锌云，只有對(duì)象C需要重定位到新的Node X 荠医！一般的，在一致性Hash算法中桑涎，如果增加一臺(tái)服務(wù)器彬向，則受影響的數(shù)據(jù)僅僅是新服務(wù)器到其環(huán)空間中前一臺(tái)服務(wù)器（即沿著逆時(shí)針方向行走遇到的第一臺(tái)服務(wù)器）之間數(shù)據(jù)，其它數(shù)據(jù)也不會(huì)受到影響攻冷。
問題：
容易發(fā)生數(shù)據(jù)傾斜
解決：
一致性Hash算法引入了虛擬節(jié)點(diǎn)機(jī)制娃胆，即對(duì)每一個(gè)服務(wù)節(jié)點(diǎn)計(jì)算多個(gè)哈希，每個(gè)計(jì)算結(jié)果位置都放置一個(gè)此服務(wù)節(jié)點(diǎn)等曼，稱為虛擬節(jié)點(diǎn)里烦。具體做法可以在服務(wù)器IP或主機(jī)名的后面增加編號(hào)來實(shí)現(xiàn)凿蒜。
例如上面的情況，可以為每臺(tái)服務(wù)器計(jì)算三個(gè)虛擬節(jié)點(diǎn)胁黑，于是可以分別計(jì)算 “Node A#1”废封、“Node A#2”、“Node A#3”丧蘸、“Node B#1”漂洋、“Node B#2”、“Node B#3”的哈希值力喷，于是形成六個(gè)虛擬節(jié)點(diǎn)：
同時(shí)數(shù)據(jù)定位算法不變刽漂，只是多了一步虛擬節(jié)點(diǎn)到實(shí)際節(jié)點(diǎn)的映射，例如定位到“Node A#1”弟孟、“Node A#2”爽冕、“Node A#3”三個(gè)虛擬節(jié)點(diǎn)的數(shù)據(jù)均定位到Node A上。這樣就解決了服務(wù)節(jié)點(diǎn)少時(shí)數(shù)據(jù)傾斜的問題披蕉。在實(shí)際應(yīng)用中，通常將虛擬節(jié)點(diǎn)數(shù)設(shè)置為32甚至更大乌奇，因此即使很少的服務(wù)節(jié)點(diǎn)也能做到相對(duì)均勻的數(shù)據(jù)分布没讲，通俗點(diǎn)的原理如下圖所示：
由于虛擬節(jié)點(diǎn)V1、V2映射到了真實(shí)節(jié)點(diǎn)N1礁苗，當(dāng)數(shù)據(jù)object1確定到Hash環(huán)上的位置并找到虛擬節(jié)點(diǎn)V2的時(shí)候爬凑，其真實(shí)位置則是位于真實(shí)節(jié)點(diǎn)N1上。
參考文章：
https://blog.csdn.net/wlccomeon/article/details/86553831
