今天給大家來分享一個知識，那就是平時我們開發系統的時候，如何運用 Ehcache 這款本地緩存框架，把我們的查詢性能大幅度提升優化，甚至讓很多查詢操作性能提升到 100 倍以上，下面就來講講這個話題。

業務場景

首先給大家引入一個場景，就是假設咱們寫的一套 Java 系統要跑一個幾百行的大 SQL 從 MySQL 里查詢數據，這個查詢是不是會速度非常的慢?

那肯定是了，這種幾百行大 SQL 往往都是那種超級復雜的查詢，可能涉及到了多表的關聯，也有的是那種數據指標的查詢，當然這種數據指標的查詢其實是會常見一些，就是針對各種數據表關聯起來查詢和統計一些指標。

一般來說的話，遇到這種超級大 SQL，往往會導致查詢 MySQL 性能很差，一般跑個 1s 甚至好幾秒那是很常見的了。

比如下圖：

所以 往往對于這種場景來說，如果想要優化一下這個查詢的性能，我們一般會用緩存。

也就是說，這一次用幾百行 SQL 語句查詢出了結果，好不容易用了幾秒鐘特別特別慢，接著其實就把這個結果緩存起來，下次請求過來，直接就用這個緩存里的數據拿出來返回就可以了，從緩存里讀結果以及返回，最多就是個 1ms 的事兒，根本不用幾秒那么漫長了。

如何通過緩存優化查詢接口

那么問題來了，這個緩存的結果是放哪里?可能很多兄弟說可以放 Redis 里啊!但是，一定要每次用緩存就立馬上 Redis 嗎?

畢竟 Redis 還得額外部署集群，一旦引入 Redis，你還得考慮 Redis 是否會有故障，他的一些接入問題，以及跟 Redis 進行網絡通信畢竟也是要耗時的。

所以說，其實咱們優先啊，可以先上本地緩存，也就是說，在業務系統運行的 JVM 的堆內存里，來緩存我們的查詢結果，下次請求來了，就從本地緩存里取出來直接返回就可以了。

如下圖：

基于大數據離線平臺進行緩存預熱

那么下一個問題又來了，很多查詢他可能當天第一次查的時候，本地緩存里是沒有的，還是得去 MySQL 里花費幾秒鐘來查詢，查完了以后才能放入到本地緩存里去，那這樣豈不是每天都有一些人第一次查詢很慢很慢嗎?

有沒有更好的辦法呢?當然有了，那就是緩存預熱，我們的業務系統可以把每天的查詢請求和參數都記錄下來。

對于一些數據報表的復雜查詢，其實每天的查詢條件都是差不多的，只不過是當天的日期會有變化而已，另外就是對于一些數據報表的數據，往往是通過大數據平臺進行離線計算的。

啥叫做離線計算呢?就是說可能有一個大數據系統每天凌晨的時候會把昨天的數據算一遍，算好的數據結果寫入到 MySQL 里去，然后每天更新數據就這一次，接著當天就不更新數據了。

如下圖：

然后呢，用戶每天都會對我們的系統發起很多次復雜報表查詢語句，但是這個 SQL 多表關聯的一些邏輯，以及附加的一些查詢條件幾乎都是有規律的是差不多的，就是每天選擇的當天日期是不太一樣的。

所以此時我們就可以把這些查詢條件記錄下來，然后每天凌晨的時候，趁著大家都睡覺了，就根據經常查詢的條件和當天日期，提前去查詢數據，查詢結果提前寫入本地緩存。

這樣用戶第一次來訪問，就可以直接從本地緩存里拿到最新的數據了，如下圖：

本地緩存框架：Ehcache

接著給大家講講咱們常用的本地緩存框架，Ehcache，這是大名鼎鼎的一個本地緩存框架，基本上 Ehcache 和 Guava 兩款本地緩存框架，用的是最多的，我們以 Ehcache 舉例來講講本地緩存框架是怎么用的。

首先得在咱們的項目 pom.xml 里引入對應的依賴，如下所示：

<dependency>
  <groupId>net.sf.ehcache</groupId>
  <artifactId>ehcache</artifactId>
  <version>2.10.2</version>
</dependency>

接著就惡意引入一個 ehcache.xml 這種配置文件，對我們的緩存框架進行一定的配置了。

如下所示：

下面給大家解釋一下 ehcache 框架運行起來以后上述那些參數對他的影響，首先 maxElementsInMemory 說的就是他在內存里可以緩存多少條數據。

eternal 意思是說這個緩存是否是永久有效的，如果要是永久有效了那么 timeToLiveSeconds 也就沒用了。

但是如果不是永久有效的，就可以設置 timeToLiveSeconds 了，比如說可以設置緩存數據生存 24 小時，然后就自動過期，接著就必須要強制從數據庫里來查詢了。

overflowToDisk 是說如果緩存的數據要是超過了 maxElementsInMemory 的時候，是不是把多余的數據刷寫到磁盤里去。

diskPersistent 是說在 JVM 重啟的時候，要不要把內存里緩存的數據刷寫到磁盤里去，然后 JVM 重啟后再把磁盤里的數據恢復到內存里來，這倆參數，如果要是緩存的數據特別多的話，其實還是可以開啟的。

一方面是內存緩存不下了可以刷寫到磁盤去，一方面是內存里的數據重啟的時候還是持久化一下，然后重新加載到內存里來。

還有一個是 memoryStoreEvictionPolixy 是緩存的回收策略，因為如果要是緩存數據量過多了，導致內存和磁盤都放不下了，這個時候就必須回收掉一部分的數據了，一般都是用 LRU，最近最少使用策略來回收的。

下面是 Ehcache 在代碼里的使用示例：

<?xml version="1.0" encoding="UTF-8"?>
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd">
    <cache name="report" 
         maxElementsInMemory="1000" 
         eternal="false" 
         timeToLiveSeconds="86400" 
         overflowToDisk="false" 
         disPersistent="false" 
         memoryStoreEvictionPolicy="LRU" />
</ehcache>

希望今天給大家分享的本地緩存知識可以幫助到大家以后遇到類似的復雜報表數據查詢場景的時候，可以利用這個知識點去優化自己系統的性能!