SpringBoot對快取的支援
頁面快取是否有必要？
幾乎所有的網站的首頁都是訪問率最高的，而首頁上的資料來源又是非常廣泛的，大多數來自不同的物件，而且有可能來自不同的db ，所以給首頁做快取是很必要的。那麼主頁的快取策略應該怎樣設計呢？我認為應該是某個固定時間之內不變的，比如說2分鐘更新一次。那麼這個快取應該做在什麼地方呢？讓我們來看一下，當前我們的的應用的結構一般是是page-filter-action-service-dao-db ，這個過程中的- 的地方都是可以做快取的地方，根據頁面快取的特徵，應該把頁面快取做到儘量靠近客戶的地方，就是在page 和filter 之間，這樣的優點就是第一個使用者請求之後，頁面被快取，第二個使用者再來請求的時候，走到filter 這個請求就結束了，無需再走後面的action-service-dao-db 。帶來的好處是伺服器壓力的減低和客戶段頁面響應速度的加快。瞭解了這些之後我們開始介紹重點。
Spring Cache是作用在方法上的，其核心思想是這樣的：當我們在呼叫一個快取方法時會把該方法引數和返回結果作為一個鍵值對存放在快取中，等到下次利用同樣的引數來呼叫該方法時將不再執行該方法，而是直接從快取中獲取結果進行返回。所以在使用Spring Cache的時候我們要保證我們快取的方法對於相同的方法引數要有相同的返回結果。
SpringBoot支援很多種快取方式：比如分散式快取：redis、memcached，本地快取：ehcache、CaffeineCache 、guava等等。
應用場景：
ehcache直接在jvm虛擬機器中快取，速度快，效率高；但是快取共享麻煩，叢集分散式應用不方便。
redis是通過socket訪問到快取服務，效率比ecache低，比資料庫要快很多，處理叢集和分散式快取方便，有成熟的方案。
如果是單個應用或者對快取訪問要求很高的應用，用ehcache。
如果是大型系統，存在快取共享、分散式部署、快取內容很大的，建議用redis。
補充下：ehcache也有快取共享方案，不過是通過RMI或者Jgroup多播方式進行廣播快取通知更新，快取共享複雜，維護不方便；簡單的共享可以，但是涉及到快取恢復，大資料快取，則不合適
redis和memcached相比的獨特之處：
1、redis可以用來做儲存(storage),而memcached是用來做快取(cache)
這個特點主要因為其有持久化功能
2、redis中儲存的資料有多種結構，而memcached儲存的資料只有一種型別“字串”
區別二:
Redis：屬於獨立的執行程式，需要單獨安裝後，使用JAVA中的Jedis來操縱。因為它是獨立，所以如果你寫個單元測試程式，放一些資料在Redis中，然後又寫一個程式去拿資料，那麼是可以拿到這個資料的。
ehcache：與Redis明顯不同，它與java程式是綁在一起的，java程式活著，它就活著。譬如，寫一個獨立程式放資料，再寫一個獨立程式拿資料，那麼是拿不到資料的。只能在獨立程式中才能拿到資料。
SpringBoot 快取之EhCache 篇
https://blog.csdn.net/fmwind/article/details/83030504