本文是按照自己的理解進行筆記總結，如有不正確的地方，還望大佬多多指點糾正，勿噴。
課程內容：
1、中小公司Redis緩存架構以及線上問題分析
2、大廠線上大規(guī)模商品緩存數(shù)據(jù)冷熱分離實戰(zhàn)
3、實戰(zhàn)解決大規(guī)模緩存擊穿導致線上數(shù)據(jù)庫壓力暴增
4、黑客攻擊導致緩存穿透線上數(shù)據(jù)庫宕機Bug
5、一行代碼解決線上緩存穿透問題
6、一次大V直播帶貨導致線上商品系統(tǒng)崩潰原因分析
7、突發(fā)性熱點緩存重建導致系統(tǒng)壓力暴增問題分析
8、基于DCL機制解決熱點緩存并發(fā)重建問題實戰(zhàn)
9、Redis分布式鎖解決緩存與數(shù)據(jù)庫雙寫不一致問題實戰(zhàn)
10、大促壓力暴增導致分布式鎖串行爭用問題優(yōu)化實戰(zhàn)
11、一次微博明星熱點事件導致系統(tǒng)崩潰原因分析
12、利用多級緩存架構解決Redis線上集群緩存雪崩問題
1. 冷熱數(shù)據(jù)分離
我們建議放緩存的地方都加一個超時時間，只需要對熱點數(shù)據(jù)進行緩存，一些其他的冷門的數(shù)據(jù)就不用放到緩存里面占用時間了。
如果對于每天都有訪問的數(shù)據(jù)就一直放在緩存里面，對于那些數(shù)據(jù)每查詢一次可以加一點緩存超時延期。也就是讀延期。這樣以來那些有人訪問的數(shù)據(jù)會一直在緩存里面，而那些沒人訪問的數(shù)據(jù)達到緩存的設定時間，就會從緩存里面移除。這樣以來就做到了數(shù)據(jù)的冷熱分離
2. 緩存設計
2.1 緩存擊穿（失效）
由于大批量緩存在同一時間失效可能導致大量請求同時穿透緩存直達數(shù)據(jù)庫，可能會造成數(shù)據(jù)庫瞬間壓力過大甚至掛掉，對于這種情況我們在批量增加緩存時最好將這一批數(shù)據(jù)的緩存過期時間設置為一個時間段內的不同時間。
如果商品上架或者更新商品，有那這批量更新、批量導入的。對商品進行批量操作，那商品的失效時間是一樣的，同時過期。結果都沒有緩存了，結果又有大量的請求。就是緩存里面沒有了，但是數(shù)據(jù)庫里面還有。
示例偽代碼:
這個問題怎么解決呢？
那么我們可以把設置的超時時間設置成隨機時間，在原來超時時間的基礎上加一個隨機數(shù)。
2.2 緩存穿透
緩存穿透是指查詢一個根本不存在的數(shù)據(jù)，緩存層和存儲層都不會命中，通常出于容錯的考慮，如果從存儲層查不到數(shù)據(jù)則不寫入緩存層。
第一種情況：就是比如商品上架之后，一不小心把他徹底刪除了，這樣刪除之后導致數(shù)據(jù)庫以及緩存里面都沒有了這個數(shù)據(jù)。結果后端數(shù)據(jù)全部沒有了，而前端還一直有高并發(fā)的數(shù)據(jù)一直過來，導致大量的請求過來查數(shù)據(jù)庫沒有，查緩存也沒有，這樣一來緩存以及數(shù)據(jù)庫的壓力都比較大，特別是數(shù)據(jù)庫。這個就叫做緩存穿透，有一個“透”字，就是把整個后端全部穿透了。
還有一種情況，就是如果是大型互聯(lián)網(wǎng)，每天都有黑客來攻擊你，假如他知道了你這個玩也鏈接中的數(shù)字就是你商品的id，那這個時候別人就可以攻擊了，就是造一堆商品不存在的id，然后就用壓測的軟件去大量請求這個不存在商品，DDoS攻擊，這樣就會把數(shù)據(jù)層全部打穿、穿透。
緩存穿透將導致不存在的數(shù)據(jù)每次請求都要到存儲層去查詢，失去了緩存保護后端存儲的意義。
造成緩存穿透的基本原因有兩個:
第一，自身業(yè)務代碼或者數(shù)據(jù)出現(xiàn)問題。
第二，一些惡意攻擊、爬蟲等造成大量空命中。緩存穿透問題解決方案:
那么這樣的緩存穿透怎么解決呢？
可以設置一個空緩存?；蛘呶覀兘o一個特殊的標志，為了加以區(qū)分其他的情況，可以設置一個“{}”這樣的空緩存。
這樣看來是解決了黑客的攻擊問題，但是如果有些黑客比較聰明，他不是拿一個商品攻擊你，他每次都換著id去請求，一個數(shù)據(jù)庫中有成千上萬個空數(shù)據(jù)，那這樣就會導致生成成千上萬個空“{}”的緩存，又達到了攻擊，那怎么解決呢？
過期，設置過期時間。空緩存可以設置幾分鐘過期之類的。如果他一直使用同一個商品，我們也可以設置一個商品的讀延期時間。延期緩存就延期一兩分鐘的樣子可以。
2.3 緩存雪崩
緩存雪崩指的是緩存層支撐不住或宕掉后，流量會像奔逃的野牛一樣，打向后端存儲層。
由于緩存層承載著大量請求，有效地保護了存儲層，但是如果緩存層由于某些原因不能提供服務(比如超大并發(fā)過來，緩存層支撐不住，或者由于緩存設計不好，類似大量請求訪問bigkey，導致緩存能支撐的并發(fā)急劇下降)，于是大量請求都會打到存儲層，存儲層的調用量會暴增，造成存儲層也會級聯(lián)宕機的情況。
預防和解決緩存雪崩問題，可以從以下三個方面進行著手。
- 保證緩存層服務高可用性，比如使用Redis Sentinel或Redis Cl
uster。 - 依賴隔離組件為后端限流熔斷并降級。比如使用Sentinel或Hystrix限流降級組件。
比如服務降級，我們可以針對不同的數(shù)據(jù)采取不同的處理方式。當業(yè)務應用訪問的是非核心數(shù)據(jù)（例如電商商品屬性，用戶信息等)時，暫時停止從緩存中查詢這些數(shù)據(jù)，而是直接返回預定義的默認降級信息、空值或是錯誤提示信息;當業(yè)務應用訪問的是核心數(shù)據(jù)(例如電商商品庫存）時，仍然允許查詢緩存，如果緩存缺失，也可以繼續(xù)通過數(shù)據(jù)庫讀取。 - 提前演練。在項目上線前，演練緩存層宕掉后，應用以及后端的負載情況以及可能出現(xiàn)的問題，在此基礎上做一些預案設定。
3. 大V直播帶貨導致線上商品系統(tǒng)崩潰原因分析
像一些特別大的直播帶貨主播可能會上一些非常冷門的商品，就是之前根本沒有買的商品，也沒有訪問的商品。但是當這些大主播們在直播間讓大家搶這些商品的時候，可能一下幾百萬人去請求這個商品，但是這個商品在緩存里面沒有，因為他是冷門的商品嘛。
假設現(xiàn)在一下有幾萬個請求來調用這個方法，然后查緩存是沒有的，這個時候就會走到數(shù)據(jù)庫這邊來。但是數(shù)據(jù)的抗壓能力很弱的。不過這個是小概率事件，因為可能這個冷門的商品在上架之前先進行訪問就會緩存起來，我們不考慮這種情況，我們就考慮這種小概率的事件，就是這個冷門的商品緩存失效了，然后又有很多人來訪問，現(xiàn)在就會壓力全給到數(shù)據(jù)庫，數(shù)據(jù)庫承受壓力很小的，這樣就會導致數(shù)據(jù)庫可能會掛掉。這樣就會防止這種情況的。
雖然是小概率事件，我們還是要規(guī)避的。這就是突發(fā)性熱點緩存重建導致系統(tǒng)壓力暴增問題
4. 突發(fā)性熱點緩存重建導致系統(tǒng)壓力暴增問題
這個問題怎么解決呢？
最簡單的方式就是加鎖。就是單例模式里面有一個DCL（Double Check Lock）雙重檢測鎖。這個就可以解決這個問題。
就是雙重查詢
對于那些突發(fā)性的熱點緩存，并發(fā)重建的問題就解決了。一下來了幾萬條數(shù)據(jù)需要重建緩存，沒關系，只有一個人能重建緩存。這個時候其他的請求就得等著這個重建緩存，但是等這個重建完成之后，進到這塊代碼的時候發(fā)現(xiàn)緩存里面有數(shù)據(jù)了，就不會再添加緩存了。
其實這樣做還是回有問題，就是synchronized只在單節(jié)點內是有效的。如果這個是一個web應用的一個集群，用這個代碼做的話，他的每個web服務器上都要重建一次，synchronized{this}中使用this肯定是不行的。就是比如101商品是在A的直播間里面加鎖了，那么現(xiàn)在來了一個102商品在B直播間，是不是也阻塞住了，這樣是不應該的，關鍵現(xiàn)在是不同的商品，現(xiàn)在因為一個商品會導致別的商品阻塞住。這個時候就可以使用分布式鎖。把這個鎖替換成分布式鎖就得到了解決。分布式鎖就是解決多節(jié)點間的并發(fā)問題。而且重建只需要建一次。
如果我們在開發(fā)的時候，開發(fā)著開發(fā)著發(fā)現(xiàn)里面的代碼開始比較多了，且里面還有重復的，這個時候我們就可以重構一下：
這個時候仍然會有一個小問題
如果這個里面的數(shù)據(jù)是不存在的，然后里面放的是空緩存，但是我們這個時候返回的是null，再走到上面就會又去查數(shù)據(jù)庫，這個時候是沒必要的，因此需要區(qū)分一下。
5. 緩存數(shù)據(jù)庫雙寫不一致問題
下面這兩種情況全部都是緩存數(shù)據(jù)庫雙寫不一致問題：
刪除緩存同樣也會有這樣的問題
分布式鎖就可以解決這個問題，
意思就是在一個線程操作的時候加上分布式鎖即可
現(xiàn)在開始加鎖
在更新、創(chuàng)建的地方都應該加這樣的分布式鎖，直接復制過去即可。
其實看著這樣寫了很多代碼，會覺得在執(zhí)行的時候效率很低。其實不是的，因為這個解決的是小概率事件，其中90%還是在緩存了就會讀到。
其實在一些電商平臺，基本上95%還是讀操作，只有你加入購物車了或者是下單了才會涉及到寫操作。也就是電商平臺就是讀多寫少的問題，針對這個問題使用分布式鎖去解決問題，可以借助分布式的讀寫鎖優(yōu)化，這種情況下可以借助分布式的讀寫鎖redisson優(yōu)化。讀就加讀鎖，寫就加寫鎖，因為寫寫會沖突，讀寫會沖突，但是讀讀是不會有沖突的。
如果現(xiàn)在大家伙都在讀，在加讀鎖的時候是互相不沖突的，大家都可以進行讀。也就是并行執(zhí)行。秒殺之前大家都是讀，都去并發(fā)執(zhí)行，效率是很高的，也就那1s時間是有寫讀或者寫寫共存的情況。
- 第一句代碼使用 Redisson 的 getReadWriteLock() 方法獲取了一個名為 LOCK_PRODUCT_UPDATE_PREFIX + productId 的讀寫鎖 productUpdateLock，用于保證對 productId 對應的數(shù)據(jù)的讀寫操作是互斥的。
- 第二句代碼通過 productUpdateLock 的 writeLock() 方法獲取了一個寫入鎖 writeLock，用于保證對 productId 對應的數(shù)據(jù)的寫操作是互斥的。
- 第三句代碼使用 writeLock 的 lock() 方法獲取了寫入鎖，并阻塞當前線程，直到獲取到鎖為止。然后，該線程可以執(zhí)行對 productId 對應數(shù)據(jù)的寫操作。
這把讀寫鎖，這個鎖的key必須是一樣的。
下面是讀鎖的底層源碼：
如果第一個線程是寫鎖，現(xiàn)在來了一個線程，首先判斷這個鎖的模式，如果是讀鎖，那就把這個在寫鎖上加1，如果是寫鎖你就在這等著。
分布式鎖有很多的優(yōu)化場景，要根據(jù)不同的場景使用不同的鎖。
下面這塊應該使用不了讀寫鎖優(yōu)化，那么應該怎么來進行優(yōu)化。
假如我們知道有99.99%的線程會在1s鐘將這個方法里面的所有的步驟執(zhí)行完，因此這個時候串行就可以轉成并行
就是我等1s時間，如果我還加不上鎖我就走了，返回方法。
package com.hs.distributlock.service;
import com.alibaba.fastjson.JSON;
import com.hs.distributlock.entity.ProductEntity;
import com.hs.distributlock.mapper.ProductMapper;
import org.redisson.Redisson;
import org.redisson.api.RLock;
import org.redisson.api.RReadWriteLock;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.stereotype.Service;
import org.springframework.util.StringUtils;
import java.util.Objects;
import java.util.Random;
import java.util.concurrent.TimeUnit;
/**
* @Description: 高并發(fā)緩存架構
* @Author 胡尚
* @Date: 2023/3/25 20:10
*/
@Service
public class ProductService {
@Autowired
StringRedisTemplate redisTemplate;
@Autowired
Redisson redisson;
@Autowired
ProductMapper productMapper;
/**
* 緩存穿透默認值
*/
public static final String PRODUCT_PENETRATE_DEFAULT = "{}";
/**
* 突發(fā)性熱點緩存重建時加的鎖
*/
public static final String LOCK_PRODUCT_HOT_CACHE_CREATE_PREFIX = "lock:product:hot_cache_create:";
/**
* 突發(fā)性熱點緩存重建時加的鎖
*/
public static final String LOCK_CACHE_DB_UNLIKE_PREFIX = "lock:cache_db_unlike:";
public void updateProduct(ProductEntity entity){
// 解決緩存與數(shù)據(jù)庫雙寫 數(shù)據(jù)不一致問題 而加寫鎖
RReadWriteLock readWriteLock = redisson.getReadWriteLock(LOCK_CACHE_DB_UNLIKE_PREFIX + entity.getId());
RLock wLock = readWriteLock.writeLock();
wLock.lock();
try {
// 更新DB 更新緩存
productMapper.update(entity);
String json = JSON.toJSONString(entity);
redisTemplate.opsForValue().set("product:id:" + entity.getId(), json, 12*60*60+getRandomTime(), TimeUnit.SECONDS);
}finally {
wLock.unlock();
}
}
public void insertProduct(ProductEntity entity){
// 解決緩存與數(shù)據(jù)庫雙寫 數(shù)據(jù)不一致問題 而加寫鎖
RReadWriteLock readWriteLock = redisson.getReadWriteLock(LOCK_CACHE_DB_UNLIKE_PREFIX + entity.getId());
RLock wLock = readWriteLock.writeLock();
wLock.lock();
try {
// 更新DB 更新緩存
productMapper.insert(entity);
String json = JSON.toJSONString(entity);
redisTemplate.opsForValue().set("product:id:" + entity.getId(), json, 12*60*60+getRandomTime(), TimeUnit.SECONDS);
}finally {
wLock.unlock();
}
}
/**
* 重點方法，這其中使用了雙重檢測去查詢緩存，還加了讀鎖去解決緩存和數(shù)據(jù)庫雙寫導致的數(shù)據(jù)不一致問題
*/
public ProductEntity queryProduct(Long id) throws InterruptedException {
String productKey = "product:id:" + id;
// 從緩存取數(shù)據(jù)
ProductEntity entity = queryCache(productKey);
if (entity != null){
return entity;
}
// 突發(fā)性熱點緩存重建問題，避免大量請求直接去請求DB，進而加鎖攔截
RLock lock = redisson.getLock(LOCK_PRODUCT_HOT_CACHE_CREATE_PREFIX + id);
lock.tryLock(3, 30, TimeUnit.SECONDS);
try {
// 第二次驗證 從緩存取數(shù)據(jù)
entity = queryCache(productKey);
if (entity != null){
return entity;
}
// 緩存與DB數(shù)據(jù)雙寫不一致問題 加鎖
RReadWriteLock readWriteLock = redisson.getReadWriteLock(LOCK_CACHE_DB_UNLIKE_PREFIX + id);
RLock rLock = readWriteLock.readLock();
rLock.lock();
try {
// 查詢數(shù)據(jù)庫 更新緩存
entity = queryDatabase(productKey, id);
}finally {
rLock.unlock();
}
}finally {
lock.unlock();
}
return entity;
}
/**
* 從緩存中查詢
*/
private ProductEntity queryCache(String key){
ProductEntity entity = null;
String json = redisTemplate.opsForValue().get(key);
if (StringUtils.hasLength(json)){
// 判斷是否為解決緩存穿透而手動存儲的值，如果是則直接返回一個新對象，并和前端約定好錯誤提示
if (Objects.equals(PRODUCT_PENETRATE_DEFAULT, json)){
return new ProductEntity();
}
entity = JSON.parseObject(json, ProductEntity.class);
// 延期
redisTemplate.expire(key, 12*60*60+getRandomTime(), TimeUnit.SECONDS);
}
return entity;
}
/**
* 從數(shù)據(jù)庫中查詢，如果查詢到了就將數(shù)據(jù)在緩存中保存一份，如果沒有查詢到則往緩存中存一個默認值來解決緩存擊穿問題
*/
private ProductEntity queryDatabase(String productKey, long id){
ProductEntity entity = productMapper.get(id);
// 如果數(shù)據(jù)庫中也沒有查詢到，那么就往緩存中存一個默認值，去解決緩存擊穿問題
if (entity == null){
redisTemplate.opsForValue().set(productKey, PRODUCT_PENETRATE_DEFAULT, 60*1000, TimeUnit.SECONDS);
} else {
redisTemplate.opsForValue().set(productKey, JSON.toJSONString(entity), 12*60*60+getRandomTime(), TimeUnit.SECONDS);
}
return entity;
}
private Integer getRandomTime(){
return new Random().nextInt(5) * 60 * 60;
}
}
在這段代碼中，使用了Redisson提供的分布式鎖來解決緩存和數(shù)據(jù)庫雙寫導致的數(shù)據(jù)不一致問題。具體來說，使用了Redisson提供的讀寫鎖（RReadWriteLock）來對緩存和數(shù)據(jù)庫進行加鎖。
在updateProduct和insertProduct方法中，首先獲取了一個寫鎖（RReadWriteLock.writeLock()）wLock，然后使用wLock.lock()方法獲取鎖并阻塞當前線程，直到獲取到鎖為止。在獲取到鎖之后，更新了數(shù)據(jù)庫中的數(shù)據(jù)，然后更新了緩存中的數(shù)據(jù)，最后釋放鎖，以便其他線程能夠獲取鎖并進行操作。
在queryProduct方法中，首先從緩存中查詢數(shù)據(jù)，如果緩存中不存在，則使用Redisson提供的分布式鎖（RLock）來解決突發(fā)性熱點緩存重建問題。具體來說，使用redisson.getLock(LOCK_PRODUCT_HOT_CACHE_CREATE_PREFIX + id)獲取一個名為LOCK_PRODUCT_HOT_CACHE_CREATE_PREFIX + id的鎖lock，然后使用lock.tryLock(3, 30, TimeUnit.SECONDS)方法獲取鎖并阻塞當前線程，直到獲取到鎖為止。在獲取到鎖之后，再次從緩存中查詢數(shù)據(jù)，如果緩存中不存在，則使用Redisson提供的讀寫鎖（RReadWriteLock）來對緩存和數(shù)據(jù)庫進行加鎖。
具體來說，使用redisson.getReadWriteLock(LOCK_CACHE_DB_UNLIKE_PREFIX + id)獲取一個名為LOCK_CACHE_DB_UNLIKE_PREFIX + id的讀寫鎖readWriteLock，然后使用readWriteLock.readLock()獲取一個讀鎖rLock，使用rLock.lock()方法獲取鎖并阻塞當前線程，直到獲取到鎖為止。在獲取到讀鎖之后，查詢數(shù)據(jù)庫并更新緩存中的數(shù)據(jù)，最后釋放讀鎖，以便其他線程能夠獲取鎖并進行操作。最后，釋放熱點緩存重建鎖，以便其他線程能夠獲取鎖并進行操作。
需要注意的是，獲取鎖后必須執(zhí)行對應的解鎖操作，以便其他線程能夠獲取鎖并進行操作。在上述代碼示例中，使用了try-finally語句塊來確保鎖的釋放。這樣，即使在執(zhí)行操作時拋出異常，也能夠保證鎖會被正確釋放。
6. 一次微博明星熱點事件導致系統(tǒng)崩潰原因分析
可能同時上百萬的人訪問，一個單個節(jié)點redis就是再緩存大概能支持10萬個，因此redis可能也扛不住，redis扛不住，web請求可能就會報錯。
也就是緩存雪崩文章來源：http://www.zghlxwxcb.cn/news/detail-723012.html
針對這種問題我們可以限流。這個即使前端代碼層已經(jīng)有限流，也要在后端也進行限流。萬一前端沒有限流成功，后端可以。也就是多加一級緩存，也就是多級緩存架構。文章來源地址http://www.zghlxwxcb.cn/news/detail-723012.html
到了這里，關于5. 一線大廠高并發(fā)緩存架構實戰(zhàn)與性能優(yōu)化的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
