美團技術-緩存那些事

緩存特徵（描述緩存模型的重要指標）

命中率

命中率=返回正確結果數/請求緩存次數，命中率問題是緩存中的一個很是重要的問題，它是衡量緩存有效性的重要指標。命中率越高，代表緩存的使用率越高。

最大元素（或最大空間）

緩存中能夠存放的最大元素的數量，一旦緩存中元素數量超過這個值（或者緩存數據所佔空間超過其最大支持空間），那麼將會觸發緩存啓動清空策略根據不一樣的場景合理的設置最大元素值每每能夠必定程度上提升緩存的命中率，從而更有效的時候緩存。

清空策略

如上描述，緩存的存儲空間有限制，當緩存空間被用滿時，如何保證在穩定服務的同時有效提高命中率？這就由緩存清空策略來處理，設計適合自身數據特徵的清空策略能有效提高命中率。

常見的緩存清空策略

FIFO(first in first out)--比較元素的建立時間

    先進先出策略，最早進入緩存的數據在緩存空間不夠的狀況下（超出最大元素限制）會被優先被清除掉，以騰出新的空間接受新的數據。策略算法主要比較緩存元素的建立時間。在數據實效性要求場景下可選擇該類策略，優先保障最新數據可用。

LFU(less frequently used)--比較元素的命中次數

    最少使用策略，不管是否過時，根據元素的被使用次數判斷，清除使用次數較少的元素釋放空間。策略算法主要比較元素的hitCount（命中次數）。在保證高頻數據有效性場景下，可選擇這類策略。

LRU(least recently used)--比較元素的最後使用時間

    最近最少使用策略，不管是否過時，根據元素最後一次被使用的時間戳，清除最遠使用時間戳的元素釋放空間。策略算法主要比較元素最近一次被get使用時間。在熱點數據場景下較適用，優先保證熱點數據的有效性。

除此以外，還有一些簡單策略好比：

    根據過時時間判斷，清理過時時間最長的元素；

    根據過時時間判斷，清理最近要過時的元素；

    隨機清理；

    根據關鍵字（或元素內容）長短清理等。

緩存介質

雖然從硬件介質上來看，無非就是內存和硬盤兩種，但從技術上，能夠分紅內存、硬盤文件、數據庫。

內存

將緩存存儲於內存中是最快的選擇，無需額外的I/O開銷，可是內存的缺點是沒有持久化落地物理磁盤，一旦應用異常break down而從新啓動，數據很難或者沒法復原。

硬盤

通常來講，不少緩存框架會結合使用內存和硬盤，在內存分配空間滿了或是在異常的狀況下，能夠被動或主動的將內存空間數據持久化到硬盤中，達到釋放空間或備份數據的目的。

數據庫

前面有提到，增長緩存的策略的目的之一就是爲了減小數據庫的I/O壓力。如今使用數據庫作緩存介質是 不是又回到了老問題上了？其實，數據庫也有不少種類型，像那些不支持SQL，只是簡單的key-value存儲結構的特殊數據庫（如BerkeleyDB 和Redis），響應速度和吞吐量都遠遠高於咱們經常使用的關係型數據庫等。

緩存分類和應用場景

緩存有各種特徵，並且有不一樣介質的區別，那麼實際工程中咱們怎麼去對緩存分類呢？在目前的應用服務框架中，比較常見的，時根據緩存與應用的藕合度，分爲local cache（本地緩存）和remote cache（分佈式緩存）。

本地緩存

指的是在應用中的緩存組件，其最大的優勢是應用和cache是在同一個進程內部，請求緩存很是快速，沒有過多的網絡開銷等，在單應用不須要集羣支持或者集羣狀況下各節點無需互相通知的場景下使用本地緩存較合適；同時，它的缺點也是應爲緩存跟應用程序耦合，多個應用程序沒法直接的共享緩存，各應用或集羣的各節點都須要維護本身的單獨緩存，對內存是一種浪費。

分佈式緩存

指的是與應用分離的緩存組件或服務，其最大的優勢是自身就是一個獨立的應用，與本地應用隔離，多個應用可直接的共享緩存。

說明

目前各類類型的緩存都活躍在成千上萬的應用服務中，還沒有一種緩存方案能夠解決一切的業務場景或數據類型，咱們須要根據自身的特殊場景和背景，選擇最適合的緩存方案。緩存的使用是程序員、架構師的必備技能，好的程序員能根據數據類型、業務場景來準確判斷使用何種類型的緩存，如何使用這種緩存，以最小的成本最快的效率達到最優的目的。

本地緩存

編程直接實現緩存

Ehcache

Guava Cache

分佈式緩存

memcached緩存

Redis緩存

★實際工程中，對於緩存的應用能夠有多種的實戰方式，包括侵入式硬編碼，抽象服務化應用，以及輕量的註解式使用等

將redis集成進系統，也是能夠採用這幾種方式：侵入式硬編碼，抽象服務化應用，以及輕量的註解式使用。

侵入式硬編碼太low，並且代碼可讀性差且很差維護，不推薦這種方式。學習、試驗時能夠嘗試寫小例子來理解涉及的接口和類，可是實際項目中最好不要採用。

註解式是SpringBoot中提供和推薦的方式，實際項目中可使用。可是有個性化的需求時不必定能知足項目需求，可能還須要在此基礎上進行擴展。

抽象化服務要作好有較高的要求，須要對框架源碼有深刻的理解，長期跟蹤維護、優化代碼。固然，這也是能提現出理解力和水平的一個方向。