這篇文章為大家帶來了關於Redis的相關知識，其中主要介紹了關於緩存雪崩、緩存擊穿和緩存穿透的相關內容，下面一起來看一下，希望對大家有幫助。
推薦學習：Redis影片教學
#關於Redis的高頻問題，快取雪崩、快取擊穿和快取穿透一定少不了，相信大家在面試中都被問過類似的問題。為什麼這些問題一直很熱門呢？因為我們在使用Redis快取時，這些問題都是很容易遇到的。接下來我們就來看看這些問題都是怎麼產生的，對應的解決方案都有哪些吧。
快取雪崩
首先來看看快取雪崩，快取雪崩的概念就是：大量的請求沒有在Redis快取中處理，導致請求都湧入到資料庫中，然後資料庫的壓力劇增。
造成快取雪崩的原因可總結為2個：
- 快取中有大量的資料同時過期，這樣此時大量的請求都懟到資料庫了。
- Redis快取執行個體發生故障了，無法處理大量請求，也會導致請求都跑到資料庫去了。
先來看看第一個場景：快取中大量的資料同時過期問題。
快取中大量的資料同時過期
結合圖例來看，就是大量的資料在同一時間過期，然後此時又有很多的請求要讀取這些資料。當然就會發生緩存雪崩，導致資料庫壓力劇增了。
大量資料同時過期的解決方案
應對大量資料同時過期問題，通常有2種方案：
- 資料過期設定增加隨機時間：也就是用expire指令設定過期時間時，增加一個隨機的時間，例如資料a是5分鐘過期，在5分鐘的基礎上隨機增加10-120秒時間。這樣就能避免大量數據同時過期。
- 服務降級：也就是發生快取雪崩時，（1）若存取的不是核心數據，當沒有快取命中時，不去資料庫了，直接返回預先設定好的信息，例如空值或錯誤資訊；（2）當存取的是核心數據，快取未命中時，允許去資料庫查詢。這樣就將不是核心資料的請求都拒絕懟到資料庫了。
看完了大量資料同時過期的狀況，再來看看Redis快取實例故障的情況。
Redis快取實例故障導致的快取雪崩
這種情況下，Redis無法處理讀取請求了，請求自然就懟到資料庫了。
通常來說，應對這種情況，我們也有2種方式：
- 在業務系統中做好服務熔斷/請求限流。
- 事前預防：建立Redis高可靠集群，例如主從集群的主備切換。
服務熔斷，也就是當Redis發生故障時，暫停請求對快取系統的存取。等到Redis恢復正常了再開啟請求存取。
這種方式我們需要對Redis或資料庫的運作狀態進行監控，例如MySQL的負載壓力、Redis的CPU使用率、記憶體使用率及QPS等。當發現Redis實例快取雪崩了，就暫停服務。
這種情況能有效放置大量請求對資料庫造成壓力。但是會暫停請求訪問，對業務端的影響很大。
因此，為了減少對業務端的影響，我們可以使用請求限流方式，控制QPS，避免過多的請求懟到資料庫。例如下面圖例，本身有2萬每秒的請求，但因為Redis故障宕機了。我們限流作業將qps降到2千每秒，資料庫處理2000的qps還是沒問題的。
快取擊穿
快取擊穿就是指個別存取頻繁的熱點資料無法快取命中，然後請求都湧入資料庫。它經常會在熱點資料過期時發生。
對於快取擊穿問題，我們知道這些都是被存取非常頻繁的熱點數據，處理方式就簡單粗暴了，直接不設定過期時間了。等熱點資料不頻繁存取再手動處理即可。
Cache Penetration
Cache avalanche is something special. It means that the data to be accessed is neither in the Redis cache nor in the database. When a large number of requests enter the system, Redis and the database will be under tremendous pressure.
There are usually two reasons for cache penetration:
- The data is accidentally deleted, resulting in no data in the cache and database. However, the client doesn't know this and is still requesting frantically.
- In the case of malicious attacks: that is, someone is targeting you to check for data that is not available.
For cache penetration, you can refer to the following solutions:
-
is to set a null value or default value for the cache value. For example, when cache penetration occurs, set a null value/default value in the Redis cache. Subsequent queries for this value will directly return this default value.
- Use Bloom filter to determine whether the data exists and avoid querying from the database.
-
Perform request detection on the front end. For example, filter some illegal requests directly on the front end instead of sending them to the back end for processing.
The first and third points are easier to understand and will not be described here. Let’s focus on the second point: Bloom filters.
Bloom filter
The Bloom filter is mainly used to determine whether an element is in a set. It consists of a fixed-size binary vector (can be understood as a bit array with a default value of 0) and a series of mapping functions.
Let’s first take a look at how the Bloom filter marks a data a:
- In the first step, multiple mapping functions (hash functions) will be used. Each Each function will calculate the hash value of this data a;
- In the second step, these calculated hash values will be modulo the length of the bit array respectively, so that each hash value on the array is obtained position;
- The third step is to set the positions obtained in the second step to 1 on the bit array respectively.
After these 3 steps, data labeling is completed. Then you need to query the data when it is not there:
- First calculate the multiple positions of this data in the bit array;
- Then check these positions of the bit array respectively bit value. Only if the bit value of each position is 1, it means that the data may exist, otherwise the data must not exist.
Combined with the picture below, the basic principle is like this.
Recommended learning: Redis video tutorial
以上是一文搞懂redis緩存雪崩、緩存擊穿和緩存穿透的詳細內容。更多資訊請關注PHP中文網其他相關文章！
