第gozero微服務高在請求量下如何優化目錄引言本地緩存自動識別熱點數據緩存使用技巧結束語

引言

前兩篇文章我們介紹了緩存使用的各種最佳實踐，首先介紹了緩存使用的基本姿勢，分別是如何利用go-zero自動生成的緩存和邏輯代碼中緩存代碼如何寫，接著講解了在面對緩存的穿透、擊穿、雪崩等常見問題時的解決方案，最后還重點講解了如何保證緩存的一致性。

因為緩存對于高并發服務來說實在是太重要了，所以這篇文章我們還會繼續一起學習下緩存相關的知識。

本地緩存

當我們遇到極端熱點數據查詢的時候，這個時候就要考慮本地緩存了。熱點本地緩存主要部署在應用服務器的代碼中，用于阻擋熱點查詢對于Redis等分布式緩存或者數據庫的壓力。

在我們的商城中，首頁Banner中會放一些廣告商品或者推薦商品，這些商品的信息由運營在管理后臺錄入和變更。這些商品的請求量非常大，即使是Redis也很難扛住，所以這里我們可以使用本地緩存來進行優化。

在product庫中先建一張商品運營表product_operation，為了簡化只保留必要字段，product_id為推廣運營的商品id，status為運營商品的狀態，status為1的時候會在首頁Banner中展示該商品。

CREATETABLE`product_operation`(

`id`bigintunsignedNOTNULLAUTO_INCREMENT,

`product_id`bigintunsignedNOTNULLDEFAULT0COMMENT'商品id',

`status`intNOTNULLDEFAULT'1'COMMENT'運營商品狀態0-下線1-上線',

`create_time`datetimeNOTNULLDEFAULTCURRENT_TIMESTAMPCOMMENT'創建時間',

`update_time`datetimeNOTNULLDEFAULTCURRENT_TIMESTAMPONUPDATECURRENT_TIMESTAMPCOMMENT'更新時間',

PRIMARYKEY(`id`),

KEY`ix_update_time`(`update_time`)

)ENGINE=InnoDBDEFAULTCHARSET=utf8mb4COMMENT='商品運營表';

本地緩存的實現比較簡單，我們可以使用map來自己實現，在go-zero的collection中提供了Cache來實現本地緩存的功能，我們直接拿來用，重復造輪子從來不是一個明智的選擇，localCacheExpire為本地緩存過期時間，Cache提供了Get和Set方法，使用非常簡單

localCache,err:=collection.NewCache(localCacheExpire)

先從本地緩存中查找，如果命中緩存則直接返回。沒有命中緩存的話需要先從數據庫中查詢運營位商品id，然后再聚合商品信息，最后回塞到本地緩存中。詳細代碼邏輯如下：

func(l*OperationProductsLogic)OperationProducts(in*product.OperationProductsRequest)(*product.OperationProductsResponse,error){

opProducts,ok:=l.svcCtx.LocalCache.Get(operationProductsKey)

ifok{

returnproduct.OperationProductsResponse{Products:opProducts.([]*product.ProductItem)},nil

pos,err:=l.svcCtx.OperationModel.OperationProducts(l.ctx,validStatus)

iferr!=nil{

returnnil,err

varpids[]int64

for_,p:=rangepos{

pids=append(pids,p.ProductId)

products,err:=ductListLductsByIds(l.ctx,pids)

iferr!=nil{

returnnil,err

varpItems[]*product.ProductItem

for_,p:=rangeproducts{

pItems=append(pItems,product.ProductItem{

ProductId:p.Id,

Name:p.Name,

l.svcCtx.LocalCache.Set(operationProductsKey,pItems)

returnproduct.OperationProductsResponse{Products:pItems},nil

}

使用grpurl調試工具請求接口，第一次請求cachemiss后，后面的請求都會命中本地緩存，等到本地緩存過期后又會重新回源db加載數據到本地緩存中

~grpcurl-plaintext-d'{}':8081product.Product.OperationProducts

"products":[

"productId":"32",

"name":"電風扇6"

"productId":"31",

"name":"電風扇5"

"productId":"33",

"name":"電風扇7"

}

注意，并不是所有信息都適用于本地緩存，本地緩存的特點是請求量超高，同時業務上能夠允許一定的不一致，因為本地緩存一般不會主動做更新操作，需要等到過期后重新回源db后再更新。所以在業務中要視情況而定看是否需要使用本地緩存。

自動識別熱點數據

首頁Banner場景是由運營人員來配置的，也就是我們能提前知道可能產生的熱點數據，但有些情況我們是不能提前預知數據會成為熱點的。

所以就需要我們能自適應地自動的識別這些熱點數據，然后把這些數據提升為本地緩存。

我們維護一個滑動窗口，比如滑動窗口設置為10s，就是要統計這10s內有哪些key被高頻訪問，一個滑動窗口中對應多個Bucket，每個Bucket中對應一個map，map的key為商品的id，value為商品對應的請求次數。

接著我們可以定時的(比如10s)去統計當前所有Buckets中的key的數據，然后把這些數據導入到大頂堆中，輕而易舉的可以從大頂堆中獲取topK的key，我們可以設置一個閾值，比如在一個滑動窗口時間內某一個key訪問頻次超過500次，就認為該key為熱點key，從而自動地把該key升級為本地緩存。

緩存使用技巧

下面介紹一些緩存使用的小技巧

key的命名要盡量易讀，即見名知意，在易讀的前提下長度要盡可能的小，以減少資源的占用，對于value來說可以用int就盡量不要用string，對于小于N的value，redis內部有shared_object緩存。在redis使用hash的情況下進行key的拆分，同一個hashkey會落到同一個redis節點，hash過大的情況下會導致內存以及請求分布的不均勻，考慮對hash進行拆分為小的hash，使得節點內存均勻避免單節點請求熱點。為了避免不存在的數據請求，導致每次請求都緩存miss直接打到數據庫中，進行空緩存的設置。緩存中需要存對象的時候，序列化盡量使用protobuf，盡可能減少數據大小。新增數據的時候要保證緩存務必存在的情況下再去操作新增，使用Expire來判斷緩存是否存在。對于存儲每日登錄場景的需求，可以使用BITSET，為了避免單個BITSET過大或者熱點，可以進行sharding。在使用sortedset的時候，避免使用zrange或者zrevrange返回過大的集合，復雜度較高。在進行緩存操作的時候盡量使用PIPELINE，但也要注意避免集合過大。避免超大的value。緩存盡量要設置過期時間。慎用全量操作命令，比如Hash類型的HGETALL、Set類型的SMEMBERS等，這些操作會對Hash和Set的底層數據結構進行全量掃描，如果數據量較多的話，會阻塞Redis主線程。獲取集合類型的全量數據可以使用SSCAN、HSCAN等命令分批返回集合中的數據，減少對主線程的阻塞。慎用MONITOR命令，MONITOR命令會把監控到的內容持續寫入輸出緩沖區，如果線上命令操作很多，輸出緩沖區很快就會溢出，會對Redis性能造成影響。生產環境禁用KEYS、FLUSHALL、FLUSHDB等命令。

結束語

已知的熱點緩存比較簡單，從數據庫中提前加載到內存中即可，未知的熱點