Redis快取命中率

快取命中率的介紹

命中：可以直接通過快取獲取到需要的資料。

不命中：無法直接通過快取獲取到想要的資料，需要再次查詢資料庫或者執行其它的操作。原因可能是由於快取中根本不存在，或者快取已經過期。

通常來講，快取的命中率越高則表示使用快取的收益越高，應用的效能越好（響應時間越短、吞吐量越高），抗併發的能力越強。由此可見，在高併發的網際網路系統中，快取的命中率是至關重要的指標。

如何監控快取的命中率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命令展現出更直觀的資訊報表，推薦：同時，zabbix也提供了相關的外掛程式對redis服務進行監控。

影響快取命中率的幾個因素

之前的章節中我們提到了快取命中率的重要性，下面分析下影響快取命中率的幾個因素。

1.業務場景和業務需求

快取適合「讀多寫少」的業務場景，反之，使用快取的意義其實並不大，命中率會很低。業務需求決定了對時效性的要求，直接影響到快取的過期時間和更新策略。時效性要求越低，就越適合快取。在相同key和相同請求數的情況下，快取時間越長，命中率會越高。網際網路應用的大多數業務場景下都是很適合使用快取的。

2.快取的設計（粒度和策略）

通常情況下，快取的粒度越小，命中率會越高。舉個實際的例子說明：當快取單個物件的時候（例如：單個使用者資訊），只有當該物件對應的資料發生變化時，我們才需要更新快取或者讓移除快取。而當快取乙個集合的時候（例如：所有使用者資料），其中任何乙個物件對應的資料發生變化時，都需要更新或移除快取。還有另一種情況，假設其他地方也需要獲取該物件對應的資料時（比如其他地方也需要獲取單個使用者資訊），如果快取的是單個物件，則可以直接命中快取，反之，則無法直接命中。這樣更加靈活，快取命中率會更高。此外，快取的更新/過期策略也直接影響到快取的命中率。當資料發生變化時，直接更新快取的值會比移除快取（或者讓快取過期）的命中率更高，當然，系統複雜度也會更高。

3.快取容量和基礎設施

快取的容量有限，則容易引起快取失效和被淘汰（目前多數的快取框架或中介軟體都採用了lru演算法）。同時，快取的技術選型也是至關重要的，比如採用應用內建的本地快取就比較容易出現單機瓶頸，而採用分布式快取則畢竟容易擴充套件。所以需要做好系統容量規劃，並考慮是否可擴充套件。此外，不同的快取框架或中介軟體，其效率和穩定性也是存在差異的。

4.其他因素

當快取節點發生故障時，需要避免快取失效並最大程度降低影響，這種特殊情況也是架構師需要考慮的。業內比較典型的做法就是通過一致性hash演算法，或者通過節點冗餘的方式。

有些朋友可能會有這樣的理解誤區：既然業務需求對資料時效性要求很高，而快取時間又會影響到快取命中率，那麼系統就別使用快取了。其實這忽略了乙個重要因素–併發。通常來講，在相同快取時間和key的情況下，併發越高，快取的收益會越高，即便快取時間很短。

提高快取命中率的方法

從架構師的角度，需要應用盡可能的通過快取直接獲取資料，並避免快取失效。這也是比較考驗架構師能力的，需要在業務需求，快取粒度，快取策略，技術選型等各個方面去通盤考慮並做權衡。盡可能的聚焦在高頻訪問且時效性要求不高的熱點業務上（如字典資料、session、token），通過快取預載入（預熱）、增加儲存容量、調整快取粒度、更新快取等手段來提高命中率。對於時效性很高（或快取空間有限），內容跨度很大（或訪問很隨機），並且訪問量不高的應用來說快取命中率可能長期很低，可能預熱後的快取還沒來得被訪問就已經過期了。

Redis快取命中率

redis快取命中率介紹

快取命中率

快取命中率

相關推薦