如何提升Redis緩存命中率

轉摘於 ：http://www.javashuo.com/article/p-hgjtdlyh-q.html

              https://blog.csdn.net/weixin_34238633/article/details/85968131

緩存命中率的介紹

命中：能夠直接經過緩存獲取到須要的數據。

不命中：沒法直接經過緩存獲取到想要的數據，須要再次查詢數據庫或者執行其它的操做。緣由多是因爲緩存中根本不存在，或者緩存已通過期。

一般來說，緩存的命中率越高則表示使用緩存的收益越高，應用的性能越好（響應時間越短、吞吐量越高），抗併發的能力越強。

因而可知，在高併發的互聯網系統中，緩存的命中率是相當重要的指標。

如何監控緩存的命中率

redis提供了INFO這個命令，可以隨時監控服務器的狀態，只用telnet到對應服務器的端口，執行命令便可：

telnet localhost 6379  info

在輸出的信息裏面有這幾項和緩存的狀態比較有關係：

keyspace_hits:14414110  
keyspace_misses:3228654  
used_memory:433264648  
expired_keys:1333536  
evicted_keys:1547380

經過計算hits和miss，咱們能夠獲得緩存的命中率：14414110 / (14414110 + 3228654) = 81% ，一個緩存失效機制，和過時時間設計良好的系統，命中率能夠作到95%以上

有個ruby gem叫redis-stat，它利用INFO命令展示出更直觀的信息報表，推薦：
https://github.com/junegunn/redis-stat

同時，zabbix也提供了相關的插件對redis服務進行監控。

影響緩存命中率的幾個因素

以前的章節中咱們提到了緩存命中率的重要性，下面分析下影響緩存命中率的幾個因素。

1.業務場景和業務需求

緩存適合「讀多寫少」的業務場景，反之，使用緩存的意義其實並不大，命中率會很低。

業務需求決定了對時效性的要求，直接影響到緩存的過時時間和更新策略。時效性要求越低，就越適合緩存。在相同key和相同請求數的狀況下，緩存時間越長，命中率會越高。

互聯網應用的大多數業務場景下都是很適合使用緩存的。

2.緩存的設計（粒度和策略）

一般狀況下，緩存的粒度越小，命中率會越高。舉個實際的例子說明：

當緩存單個對象的時候（例如：單個用戶信息），只有當該對象對應的數據發生變化時，咱們才須要更新緩存或者讓移除緩存。而當緩存一個集合的時候（例如：全部用戶數據），其中任何一個對象對應的數據發生變化時，都須要更新或移除緩存。

還有另外一種狀況，假設其餘地方也須要獲取該對象對應的數據時（好比其餘地方也須要獲取單個用戶信息），若是緩存的是單個對象，則能夠直接命中緩存，反之，則沒法直接命中。這樣更加靈活，緩存命中率會更高。

此外，緩存的更新/過時策略也直接影響到緩存的命中率。當數據發生變化時，直接更新緩存的值會比移除緩存（或者讓緩存過時）的命中率更高，固然，系統複雜度也會更高。

3.緩存容量和基礎設施

緩存的容量有限，則容易引發緩存失效和被淘汰（目前多數的緩存框架或中間件都採用了LRU算法）。同時，緩存的技術選型也是相當重要的，好比採用應用內置的本地緩存就比較容易出現單機瓶頸，而採用分佈式緩存則畢竟容易擴展。因此須要作好系統容量規劃，並考慮是否可擴展。此外，不一樣的緩存框架或中間件，其效率和穩定性也是存在差別的。

4.其餘因素

當緩存節點發生故障時，須要避免緩存失效並最大程度下降影響，這種特殊狀況也是架構師須要考慮的。業內比較典型的作法就是經過一致性Hash算法，或者經過節點冗餘的方式。

 

有些朋友可能會有這樣的理解誤區：既然業務需求對數據時效性要求很高，而緩存時間又會影響到緩存命中率，那麼系統就別使用緩存了。其實這忽略了一個重要因素--併發。一般來說，在相同緩存時間和key的狀況下，併發越高，緩存的收益會越高，即使緩存時間很短。

提升緩存命中率的方法

從架構師的角度，須要應用盡量的經過緩存直接獲取數據，並避免緩存失效。這也是比較考驗架構師能力的，須要在業務需求，緩存粒度，緩存策略，技術選型等各個方面去通盤考慮並作權衡。儘量的聚焦在高頻訪問且時效性要求不高的熱點業務上（如字典數據、session、token），經過緩存預加載（預熱）、增長存儲容量、調整緩存粒度、更新緩存等手段來提升命中率。

對於時效性很高（或緩存空間有限），內容跨度很大（或訪問很隨機），而且訪問量不高的應用來講緩存命中率可能長期很低，可能預熱後的緩存還沒來得被訪問就已通過期了。