使用緩存

為什么使用緩存

緩存就是數(shù)據(jù)交換的緩沖區(qū)（稱作Cache），目的就是提高我們的接口性能，特別是那些需要大量CPU計算和I/O獲取的數(shù)據(jù)。

使用緩存帶來的問題

緩存雖然能夠提高應(yīng)用程序的性能，但也會帶來一些問題。比如：緩存失效，緩存擊穿，緩存雪崩，數(shù)據(jù)一致性問題

緩存雪崩

緩存失效為什么會帶來問題呢？試想一下，單個的緩存失效其實并不會引發(fā)多大的問題，問題在于當(dāng)大量的Key同時失效時，在高并發(fā)的情況下，大量的請求同時到數(shù)據(jù)庫層，會給數(shù)據(jù)庫層帶來壓力，從而引發(fā)其他的問題。

解決方案

優(yōu)化過期時間

既然是同時失效，那么我們只需要在Key的失效時間上再加上一個隨機時間就好了，也就是失效時間 + 隨機時間。go-zero 上已經(jīng)有相關(guān)的代碼，我簡單摘抄出來看下

// A Unstable is used to generate random value around the mean value base on given deviation.
type Unstable struct {
	deviation float64
	r         *rand.Rand
	lock      *sync.Mutex
}


// AroundDuration returns a random duration with given base and deviation.
func (u Unstable) AroundDuration(base time.Duration) time.Duration {
	u.lock.Lock()
	val := time.Duration((1 + u.deviation - 2*u.deviation*u.r.Float64()) * float64(base))
	u.lock.Unlock()
	return val
}

優(yōu)化緩存

采用多級緩存，不同級別緩存設(shè)置的超時時間不同，及時某個級別緩存都過期，也有其他級別緩存兜底。代碼如下，完整代碼見：cache_redis.go

func (r *RedisCacheClient) Get(ctx context.Context, key string, fetch fetchFunc) (result []byte, err error) {
	var byteValue []byte
	fullKey := getFullKey(r.prefix, key)
	fullKeyByte, _ := json.Marshal(fullKey)
	if val, err := r.localCache.Get(fullKeyByte); err == nil {
		r.status.IncrementLocalCacheHit()
		return val, nil
	}
	r.status.IncrementLocalCacheMiss()
	startTime := time.Now()
	byteValue, err = r.client.Get(fullKey).Bytes()
	elapsed := time.Since(startTime).Milliseconds()
	for _, p := range r.plugins {
		p.OnGetRequestEnd(ctx, cmdGet, elapsed, fullKey, err)
	}
	
	// 數(shù)據(jù)源拉取原始數(shù)據(jù)
    ........	
}

緩存擊穿

對于某些key設(shè)置了過期時間，但是其是熱點數(shù)據(jù)，如果某個key失效，可能大量的請求打過來，緩存未命中，然后去數(shù)據(jù)庫訪問，此時數(shù)據(jù)庫訪問量會急劇增加。

解決方案

多級緩存+singleflight

我們可以設(shè)置多級緩存，每一級緩存失效時間不一樣，某個級別緩存過期，也有其他級別緩存兜底。而且再加上singleflight 限制，就可以做每一個服務(wù)實例只有一個請求最終到數(shù)據(jù)庫源上，大大減輕了數(shù)據(jù)源壓力

緩存穿透

緩存穿透是指查詢的數(shù)據(jù)在數(shù)據(jù)庫是沒有的，那么在緩存中自然也沒有，所以，在緩存中查不到就會去數(shù)據(jù)庫取查詢，這樣的請求一多，那么我們的數(shù)據(jù)庫的壓力自然會增大。

解決方案

設(shè)置Null值

• 約定:對于返回為Null的依然緩存，對于拋出異常的返回不進(jìn)行緩存,注意不要把拋異常的也給緩存了。采用這種手段的會增加我們緩存的維護(hù)成本，需要在插入緩存的時候刪除這個空緩存，當(dāng)然我們可以通過設(shè)置較短的超時時間來解決這個問題。

數(shù)據(jù)過濾

• 小數(shù)據(jù)用BitMap，大數(shù)據(jù)可以用布隆過濾器

數(shù)據(jù)一致性問題

我們通常說的數(shù)據(jù)一致性指的是在程序運行過程中本地緩存、分布式緩存、mysql數(shù)據(jù)庫三者之間的數(shù)據(jù)一致性

本地緩存與DB保持一致

解決方案

MQ 方案

• 應(yīng)用實例1收到請求，更新 db，同時更新應(yīng)用自己的本地緩存.
• 應(yīng)用實例1 發(fā)送更新 mq 廣播消息.
• 應(yīng)用 實例2 和應(yīng)用實例3 收到消息，查詢 db，更新本地緩存.
• 這個時候應(yīng)用實例1，2，3與 DB 數(shù)據(jù)就保持一致

Redis與DB保持一致

基于 binlog 方案

• 更新 db 數(shù)據(jù)
• 監(jiān)聽 mysql binlog, 并寫入到MQ
• 啟動一個數(shù)據(jù)處理應(yīng)用，消費 MQ 數(shù)據(jù)并進(jìn)行數(shù)據(jù)加工
• 將加工后的數(shù)據(jù)寫入 redis
• 查詢 redis 數(shù)據(jù)返回

延遲雙刪方案

先進(jìn)行緩存清除，再執(zhí)行 update sql，最后（延遲 N 秒）再執(zhí)行緩存清除。
上述中（延遲 N 秒）的時間要大于一次寫操作的時間，一般為 3-5 秒。

基于定時任務(wù)方案

1.更新 db 數(shù)據(jù)，同時寫入數(shù)據(jù)到 redis
2.啟動一個定時任務(wù)定時將 db 數(shù)據(jù)同步到 redis

熱key和大key問題

熱key

熱key是服務(wù)端的常見問題，指一段時間內(nèi)某個key的訪問量遠(yuǎn)遠(yuǎn)超過其他的key，導(dǎo)致大量訪問流量落在某一個redis實例中；或者是帶寬使用率集中在特定的key

以被請求頻率來定義是否是熱key，沒有固定經(jīng)驗值。某個key被高頻訪問導(dǎo)致系統(tǒng)穩(wěn)定性變差，都可以定義為熱key。

可能造成的問題

• 占用大量的CPU資源，影響其他請求并導(dǎo)致整體性能降低。
• 集群架構(gòu)下，產(chǎn)生訪問傾斜，即某個數(shù)據(jù)分片被大量訪問，而其他數(shù)據(jù)分片處于空閑狀態(tài)，可能引起該數(shù)據(jù)分片的連接數(shù)被耗盡，新的連接建立請求被拒絕等問題。
• 在搶購或秒殺場景下，可能因商品對應(yīng)庫存Key的請求量過大，超出Redis處理能力造成超賣。
• 熱Key的請求壓力數(shù)量超出Redis的承受能力易造成緩存擊穿，即大量請求將被直接指向后端的存儲層，導(dǎo)致存儲訪問量激增甚至宕機，從而影響其他業(yè)務(wù)。

發(fā)現(xiàn)方法

開發(fā)獨立的熱 key 檢測系統(tǒng)

提供單獨的熱 key 檢測的接入 sdk，應(yīng)用系統(tǒng)引入該 sdk 后，熱 key 檢測系統(tǒng)自動計
算是否熱 key 并推送相關(guān)結(jié)果給應(yīng)用系統(tǒng)，應(yīng)用系統(tǒng)根據(jù)業(yè)務(wù)實際情況進(jìn)行相應(yīng)處理。

改寫 redis 客戶端收集上報數(shù)據(jù)

改寫 Redis SDK，記錄每個請求，定時把收集到的數(shù)據(jù)上報，然后由一個統(tǒng)一的服務(wù)進(jìn)行聚合計算。

解決方案

利用本地緩存

在你發(fā)現(xiàn)熱 key 以后，把熱 key 加載到系統(tǒng)的內(nèi)存中。針對這種熱 key 請求，會直接從內(nèi)存中取，而不會走到 redis 層。

• 優(yōu)點：內(nèi)存訪問和 redis 訪問的速度不在一個量級，基于本地緩存，接口性能非常好， 可以
  大大增加單實例的 QPS。
• 缺點：受應(yīng)用內(nèi)存限制，容量有限，數(shù)據(jù)量非常大的時候，占用太多內(nèi)存，不太適合。部分熱點數(shù)據(jù)，需要提前預(yù)知。熱點數(shù)據(jù)自動檢測有一定的延遲，系統(tǒng)短時間內(nèi)承受的風(fēng)險比較大。

大key

大key是指當(dāng)redis的字符串類型占用內(nèi)存過大或非字符串類型元素數(shù)量過多

生產(chǎn)環(huán)境中，綜合衡量運維和環(huán)境的情況，給大key定義參考值如下：

• string類型的key超過10KB
• hash/set/zset/list等數(shù)據(jù)結(jié)構(gòu)中元素個數(shù)大于5k/整體占用內(nèi)存大于10MB

可能造成的問題

• 客戶端執(zhí)行命令的時長變慢。
• Redis內(nèi)存達(dá)到maxmemory參數(shù)定義的上限引發(fā)操作阻塞或重要的Key被逐出，甚至引發(fā)內(nèi)存溢出（Out Of Memory）。
• 集群架構(gòu)下，某個數(shù)據(jù)分片的內(nèi)存使用率遠(yuǎn)超其他數(shù)據(jù)分片，無法使數(shù)據(jù)分片的內(nèi)存資源達(dá)到均衡。
• 對大Key執(zhí)行讀請求，會使Redis實例的帶寬使用率被占滿，導(dǎo)致自身服務(wù)變慢，同時易波及相關(guān)的服務(wù)。
• 對大Key執(zhí)行刪除操作，易造成主庫較長時間的阻塞，進(jìn)而可能引發(fā)同步中斷或主從切換。

發(fā)現(xiàn)方法

實時統(tǒng)計

我們可以通過在Redis 客戶端上實時統(tǒng)計出大Key，直接計算出Key對應(yīng)的Value值大小就可以，例如

// b 為序列化之后的數(shù)據(jù)
b, err := utils.Serialize(value, c.getSerializer())
if err != nil {
   return err
}
// var b []byte
// 長度
reqSize =  len(b)

// 10KB
bigKey := 1024 * 10
if reqSize > bigKey {
    
}

• 優(yōu)點：對性能幾乎無影響。
• 缺點：返回的Key序列化長度并不等同于它在內(nèi)存空間中的真實長度，因此不夠準(zhǔn)確，僅可作為參考。

離線全量Key分析

• 對Redis的RDB備份文件進(jìn)行定制化的分析，幫助您發(fā)現(xiàn)實例中的大Key，掌握Key在內(nèi)存中的占用和分布

• Redis提供了bigkeys參數(shù)能夠使redis-cli以遍歷的方式分析Redis實例中的所有Key，并返回Key的整體統(tǒng)計信息與每個數(shù)據(jù)類型中Top1的大Key，bigkeys僅能分析并輸入六種數(shù)據(jù)類型（STRING、LIST、HASH、SET、ZSET、STREAM）,命令示例為redis-cli -h 127.0.0.1 -p 6379 --bigkeys

• 優(yōu)點：可對歷史備份數(shù)據(jù)進(jìn)行分析，對線上服務(wù)無影響。

• 缺點：時效性差，RDB文件較大時耗時較長。

解決方案

• 業(yè)務(wù)拆分，將key的含義更細(xì)粒度化，避免大key出現(xiàn)。
• 數(shù)據(jù)結(jié)構(gòu)上拆分。如果大key是個大json，可以通過mset的方式，將這個key的內(nèi)容打散到各個實例中，減小大key對數(shù)據(jù)量傾斜的影響；如果是大list，可以拆成list_1,list_2,list_N；其他數(shù)據(jù)結(jié)構(gòu)同理。（可以考慮增加單獨key存儲大key被拆分的個數(shù)或元數(shù)據(jù)信息）
• 對于長文本，更建議使用文檔型數(shù)據(jù)庫例如MongoDB等。
• 對一致性要求不高的場景，嘗試使用客戶端緩存。（只解決了redis的阻塞問題，但機器或局域網(wǎng)的帶寬問題沒有改善）
• 對大key的壓縮。相當(dāng)于用cpu資源來降低網(wǎng)絡(luò)io，其中g(shù)oogle提出的snappy算法較常用。
• 對于hash等數(shù)據(jù)結(jié)構(gòu)，需要注意業(yè)務(wù)是否可以引入定期清理無效field的機制。
  • Hash 結(jié)構(gòu)不建議使用，沒有辦法對具體的Key做過期時間設(shè)置，只能再額外開發(fā)功能去做，增加開發(fā)成本

到此這篇關(guān)于一文了解發(fā)現(xiàn)并解決Redis熱key與大key問題的文章就介紹到這了,更多相關(guān)Redis熱key與大key內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！