當前位置：首頁 > 前端技术 > vue >内容正文

vue

Vue + Spring Boot 项目实战（二十一）：缓存的应用

發布時間：2023/12/20 vue 49 豆豆

生活随笔收集整理的這篇文章主要介紹了 Vue + Spring Boot 项目实战（二十一）：缓存的应用小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

重要鏈接：
「系列文章目錄」

「項目源碼（GitHub）」

本篇目錄

前言
一、緩存：工程思想的產物
二、Web 中的緩存
- 1.緩存的工作模式
- 2.緩存的常見問題
三、緩存應用實戰
- 1.Redis 與 Spring Data Redis
- 2.Redis 安裝
- 3.Spring Data Redis 配置
- 4.緩存實現
- 5.驗證
小結
附錄：關于單元測試

前言

大家好，這次過了三個月，再次創下新的記錄，大概鴿真的是人類的本性。

不過好在大多數讀者看這個教程的目的是做畢業設計，前面的內容都做出來再修修補補一下，老師大概率也不會為難你，所以更新慢也沒太大問題。

前兩天有讀者留言說我寫的越來越隨意了，但我的直觀感受是自己寫的越來越艱難。我瞄了一眼被吐槽的那篇文章的數據，貌似收藏和點贊數量都幾乎是最高的，看來可能只是覺得代碼講解少吧。

其實真的，貼代碼講代碼是最容易的，我可以這樣很輕松地寫三四十篇文章，但我覺得沒有意義。

在這兩個月里，我又重新系統地學了一遍軟件工程、瀏覽器工作原理，跟進網絡、軟件設計、產品方面的課程，并同時對一些技術進行了深入的了解，在這個基礎上，我才敢往后推進。

作為一個興趣使然的假程序員，我想我能告訴大家的最有價值的東西并不在技術細節上，畢竟我身在另一個賽道已經很久了。

我希望你們看到這一篇時，已經把前面說的各種操作、技巧、配置、字段都忘了，這些不重要。

咱們這個項目，缺乏商業價值，架構設計粗糙，代碼不夠整潔，編程風格混亂，依賴關系復雜，框架過度使用，算法不夠高效，安全防范缺失，開發過程隨意，缺少測試代碼，沒有監控措施，缺失關鍵文檔，缺少版本控制。

你說它成功么？并不成功。但是失敗么？這套教程目前獲得了 70W+ 閱讀量，GitHub 倉庫將近千星，為我帶來了 1W+ 讀者里的百分之八十，所以我覺得并不失敗。而且正是由于我做到了現在，才知道原來一個項目要考慮這么多的因素，才總結的出如此之多的漏洞與不足。

唯一讓我感到遺憾的是沒有精力再從頭整理一遍，前面的文章還是有很多讓人困惑的地方。vue-cli 3.x 出了好久了，很多同學反映前面創建項目報錯，還有幾個氣的罵罵咧咧的，倒是可以理解，我雖然一直說人必須得學會自己解決問題，但畢竟如果入門都入不了的話也沒興趣解決問題對不對。

說了這么多，關鍵是想讓大家明白，我真的不是因為女朋友給我買了 switch，當上了海拉魯老流氓才混了這么長時間的，玩什么不是玩對不對，怪物獵人它不香么。

。。。

那么根據很久之前的計劃以及大家的反饋，這次我們來聊一聊緩存的使用。主要有以下幾個關注點：

緩存是什么？為什么需要緩存？
使用緩存需要注意哪些問題？
Redis 是什么？
針對我們的項目，應該如何使用緩存？

一、緩存：工程思想的產物

緩存一詞最初主要指 CPU 與內存之間的高速靜態隨機存取存儲器（SRAM）。

我們知道，CPU 需要頻繁從內存中讀取指令、數據，但各個硬件的發展是不均衡的，我們當前使用的主流的動態隨機存儲存取器（DRAM）內存技術無法滿足 CPU 高速讀取的需求，成為制約計算機運行效率的重要因素之一。

而 SRAM 速度快，但體積大，成本高，就目前來講，一塊 16G 的 SRAM 可能比主板還大，且價格極高，因此短期之內不可能替代 DRAM 成為內存的主流技術選擇。

怎么辦呢，妥協一下，用塊小的 SRAM 放到 DRAM 的內存和 CPU 之間，不占什么地方，也不貴。那放上去有什么用？數據豈不是還要多經過一層 SRAM 才能到 CPU？這樣會變快嗎？

當然不會更快，但計算機的運行效率確實提升了，這是為什么？因為實際上在一段時間里，一小部分指令或數據會被 CPU 頻繁讀取，機智的人類通過算法，把這些指令、數據提取出來放到緩存里，這樣就能夠四兩撥千斤，取得明顯的效果。

你看，使用緩存不是必須的，如果我們能造出高速、便宜的存儲，就沒有這么多麻煩了。但在現實中，總會有各種各樣的不完美，機會總是稍縱即逝，如果去等待完美的條件，就難以向前邁進。

工程思想的核心，就是權衡與妥協，接受不完美、不確定，通過各種手段把缺陷控制在可以容忍的范圍內，在有限的條件下盡可能地完成設定的目標、事業。

緩存是一種工程思想下自然而然的優秀實踐，這一實踐逐漸被抽象成一種設計思路，在各種受到資源獲取開銷制約的場景下得到廣泛應用。

二、Web 中的緩存

在做項目的過程中，不知道你們有沒有感嘆過，一個平平無奇的應用，涉及的點實在是太多了。各個點之間需要銜接，要銜接就會有兩個層次的不均衡：

一是性能的不均衡，包括速率、吞吐量等，造成這種不均衡的原因包括軟件、硬件、網絡、協議、策略等、位置多個維度
二是數據本身活躍性的不均衡，有些數據會被頻繁傳遞，有些很久才被訪問一次

基于這兩個不平衡，誕生了各種緩存方案。比較常見的有以下幾種：

瀏覽器緩存，包括本地的頁面資源文件和 DNS 映射
DNS 服務器上的緩存（IP - 域名映射）
CDN，利用邊緣 Cache 服務器提高訪問速度
ORM 框架提供的緩存，比如 Spring Data JPA 的持久化上下文
利用高性能非關系型數據庫（如 Redis）提供緩存服務，作為對關系型數據庫的補充
數據庫提供的緩存，比如 MySQL 自帶的查詢緩存，會把執行語句與查詢結果以 K-V 形式緩存在內存中（由于該緩存命中率較低，不建議使用，且 8.0 版本已刪除此功能）

不得不說，對成熟的應用來說，一個普通的請求想過了緩存這關還真不容易。

看起來緩存還真是個好東西，到哪都好用。但多用了一個東西，畢竟還是會增加復雜性，復雜性越高越不好控制，我們設計一個軟件的架構，就是要讓它在夠用的前提下盡可能簡單，實現簡單、控制簡單、維護簡單。

1.緩存的工作模式

緩存的實際使用方法是有一些規律可循的，我們來簡單了解一下常見的幾種模式。

Cache-Aside:

最常見的模式，可以翻譯為旁路緩存或邊緣緩存。緩存作為數據庫（或存儲）的補充，數據的獲取策略是，如果緩存中存在，則從緩存獲取，如果不存在，則從數據庫獲取，并寫入緩存。

Read-Through:

把數據庫藏在緩存背后，一切請求交由緩存響應。也就是說，如果命中緩存，則直接從緩存獲取，如果沒有命中，則從數據庫中查詢，寫入緩存后再由緩存返回。

應用這種模式，寫入緩存的操作會阻塞請求的響應，我覺得其實大部分情況下沒有必要使用。

Write-Through:

對于需要動態更新數據的應用來說，僅僅通過讀操作觸發緩存更新肯定是不夠的，如果數據庫更新了而緩存遲遲沒有更新肯定說不過去。

當更新數據庫的數據時，也有兩種常見的操作緩存的模式。Write-Through 模式是：請求更新數據，如果該數據在緩存中存在，則先更新緩存，再更新數據庫。

Write-Back:

請求更新數據，更新緩存，至于數據庫什么時候更新，不一定，有機會再更新，可以攢一波再更新，有緩存在就行。

這種異步的方式一聽就有數據不一致的風險，但因為夠快，所以在一些要求高并發大吞吐量的系統中比較常見。其實高并發的一個核心解決方案就是緩存，高并發的復雜性很大程度上取決于緩存方案的復雜性。

這些方案具體怎么用其實還是看場景，要配置相應的策略防止出現一些問題。

2.緩存的常見問題

在使用緩存時，我們一般都會考慮以下幾個問題：

數據一致性問題，緩存的數據與數據庫由于各種原因產生差異
緩存穿透，明明已經用緩存了，還是有一堆請求殺到了數據庫。
緩存雪崩，一大批緩存同時過期，一大波請求趁虛而入，如同雪崩一般。

下面我們來聊一聊這三個問題如何應對。

數據一致性問題：

一個系統，如果數據都是不變的，應用 Cache-Aside 模式，可以做到緩存中的數據永遠和數據庫中一致，需要考慮的就是緩存什么時候過期，或者緩存更新的算法，做到盡可能地找出熱點數據即可。

但大部分系統是要更新數據的，數據更新了緩存沒有及時更新，有時候沒有問題，但在一些場景下不能容忍，比如支付寶，你買了東西一看錢沒變，于是瘋狂買買買，后來突然一下錢全沒了，這誰頂的住對不對。

于是我們在寫場景下更新緩存，采用先更數據庫再更緩存的模式，比如你買了個煎餅果子，支付寶實際余額從 100 變成了 90，你老婆同時在別的地方用你的支付寶又買了杯豆漿，實際余額變成 85，數據庫沒問題，但你買煎餅果子時緩存服務卡了一下子，更新操作發生在了豆漿事件的后面，你們倆回家一看查出來的余額是 90，以為白嫖了 5 塊錢，但其實還是假象。

其實數據一致性問題還是在并發這個范疇內，整體原則就是分析實際場景，盡可能選擇既高效又安全的方案。當然這并不是一件容易的事，如果容易就沒有那么多年薪百萬的架構師了。

緩存穿透：

引發緩存穿透的情形一般有兩種，一是大量查詢一個數據庫里也沒有的數據，這種數據正常不會被緩存，結果每次都要到數據庫里兜一圈。那我們可以設置一個規則，數據庫沒有的數據我們也緩存起來，值設置成空就行了。

另一種情形是，數據庫里有這個數據，之前從沒人查詢過，但突然有那么一瞬間來了一大波請求，緩存根本來不及反應，壓力就全都到了數據庫上。這種怎么辦？兩種辦法，一是限流，二是預判。

限流好理解，請求少了就反應的過來了。預判怎么預判？你怎么知道哪個數據會被頻繁訪問？

不好意思，一般還真的知道，一個數據突然被訪問的情況，一般是你自己搗鼓出來的什么幺蛾子，比如淘寶要搞雙十一，那有些數據一定會被突然頻繁訪問，這些數據當然能預判個八九不離十。在請求排山倒海般到來之前，先把它填充到緩存里就完事兒了。（這種做法通常稱為緩存預熱）

緩存雪崩：

其實本質上雪崩和穿透是一類問題，只是出現的階段不一樣，穿透是緩存已經穩定建立起來了，雪崩是緩存突然同時過期了。當然還有一種情況，就是完全還沒有緩存的時候，一大波請求涌入。比如緩存沒做持久化，結果機房斷電了，重啟之后就是沒有緩存的。

解決方法仍然是限流和緩存預熱。其實這些名詞也是沒意思，奈何總是有人會問，有人會考。

三、緩存應用實戰

了解了緩存的基本概念和應用模式，我們來整點實際操作。前端頁面的本地緩存已經由瀏覽器實現了，我們不用管，主要操心一下后端。

你看，前端后端都有緩存，但各自解決問題的邊界是不一樣的，前端緩存應對的是靜態頁面資源的訪問，本地緩存可以更具體地說是同一用戶（終端）的多次訪問，而后端緩存更多的考慮多個用戶的多次訪問，面向的資源主要是數據庫里的數據。

對于我們項目的后端呢，我想了半天，覺得沒有需要的地方，我們這么簡單一應用，也沒用戶，也沒流量，要啥自行車啊？

但為了學習嘛，就強行假設有很多人用咱們做的這個破網站吧。那哪些場景用的比較多，數據庫壓力比較大呢？應該是前臺的圖書信息和文章兩個部分。

那么用什么來實現緩存呢？目前最常見的做法是用 Redis 來實現。

1.Redis 與 Spring Data Redis

首先我們要記住，Redis 和 MySQL 一樣，是一個數據庫管理系統，人家不是就為了做緩存的。

Redis ≠ 緩存 ，只是由于這玩意兒現在訪問速度快，但又不能完全替代關系型數據庫，所以確實適合用來做關系型數據庫的緩存，都是形勢所迫，說不定哪一天就翻身了。

我們要在應用中操縱這個數據庫，自然也需要與關系型數據庫相似的訪問方法。MySQL 我們用 Spring Data JPA，Redis 我們就用 Spring Data Redis。

其實在此之前，Java 訪問 Redis 主要是通過 Jedis 和 Lettuce 兩種由不同團隊開發的客戶端（提供訪問、操作所需的 API），Jedis 比較原生，Lettuce 提供的能力更加全面。

Spring Data Redis 是在 Lettuce 的基礎上做了一些封裝，與 Spring 生態更加貼合，使用起來也更簡便。

2.Redis 安裝

官方下載地址：https://redis.io/download

正常 Redis 只提供 Linux 版本，Windows 版本由微軟提供，版本只到 3.2.100，在 2016 年以后就沒有再更新過。下載地址為：https://github.com/microsoftarchive/redis/releases

Linux 下可以用 docker 安裝鏡像，更下方便。我下載的是 Windows 版，但不推薦大家使用。

3.Spring Data Redis 配置

這部分內容可以參考 @MacroZheng 的「Spring Data Redis 最佳實踐！」

首先是在 pom.xml 中添加依賴

<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId> </dependency>  <dependency><groupId>org.apache.commons</groupId><artifactId>commons-pool2</artifactId> </dependency>

再在 application.properties 中配置一些參數，常用的有以下幾種：

spring.redis.host=localhost spring.redis.port=6379 # Redis 數據庫索引（默認為 0） spring.redis.database=0 # Redis 服務器連接密碼（默認為空） spring.redis.password= #連接池最大連接數（使用負值表示沒有限制） spring.redis.lettuce.pool.max-active=8 # 連接池最大阻塞等待時間（使用負值表示沒有限制） spring.redis.lettuce.pool.max-wait=-1 # 連接池中的最大空閑連接 spring.redis.lettuce.pool.max-idle=8 # 連接池中的最小空閑連接 spring.redis.lettuce.pool.min-idle=0 # 連接超時時間（毫秒） spring.redis.timeout=2000 # redis 只用作緩存，不作為 repository spring.data.redis.repositories.enabled=false

Java 中的對象存儲進 Redis 之前需要進行序列化，默認為字節數組。我們為了方便解析，可以將其配置為 JSON 格式。可以創建一個 RedisConfig 類，代碼如下：

package com.gm.wj.config;import com.fasterxml.jackson.annotation.JsonAutoDetect; import com.fasterxml.jackson.annotation.PropertyAccessor; import com.fasterxml.jackson.databind.ObjectMapper; import org.springframework.cache.annotation.CachingConfigurerSupport; import org.springframework.cache.annotation.EnableCaching; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.data.redis.cache.RedisCacheConfiguration; import org.springframework.data.redis.cache.RedisCacheManager; import org.springframework.data.redis.cache.RedisCacheWriter; import org.springframework.data.redis.connection.RedisConnectionFactory; import org.springframework.data.redis.core.RedisTemplate; import org.springframework.data.redis.serializer.Jackson2JsonRedisSerializer; import org.springframework.data.redis.serializer.RedisSerializationContext; import org.springframework.data.redis.serializer.RedisSerializer; import org.springframework.data.redis.serializer.StringRedisSerializer;import java.time.Duration;@EnableCaching @Configuration public class RedisConfig extends CachingConfigurerSupport {public static final String REDIS_KEY_DATABASE="wj";@Beanpublic RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {RedisSerializer<Object> serializer = redisSerializer();RedisTemplate<String, Object> redisTemplate = new RedisTemplate<>();redisTemplate.setConnectionFactory(redisConnectionFactory);redisTemplate.setKeySerializer(new StringRedisSerializer());// 設置 redisTemplate 的序列化器redisTemplate.setValueSerializer(serializer);redisTemplate.setHashKeySerializer(new StringRedisSerializer());redisTemplate.setHashValueSerializer(serializer);redisTemplate.afterPropertiesSet();return redisTemplate;}@Beanpublic RedisSerializer<Object> redisSerializer() {//創建JSON序列化器Jackson2JsonRedisSerializer<Object> serializer = new Jackson2JsonRedisSerializer<>(Object.class);ObjectMapper objectMapper = new ObjectMapper();objectMapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);objectMapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);serializer.setObjectMapper(objectMapper);return serializer;}@Beanpublic RedisCacheManager redisCacheManager(RedisConnectionFactory redisConnectionFactory) {RedisCacheWriter redisCacheWriter = RedisCacheWriter.nonLockingRedisCacheWriter(redisConnectionFactory);//設置Redis緩存有效期為1天RedisCacheConfiguration redisCacheConfiguration = RedisCacheConfiguration.defaultCacheConfig().serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(redisSerializer())).entryTtl(Duration.ofDays(1));return new RedisCacheManager(redisCacheWriter, redisCacheConfiguration);} }

上面的文章里介紹了如何通過注解使用緩存，我們一般希望能夠更靈活地運用，因此通常選用 RedisTemplate 來實現自由操作。

RedisTemplate 是 Spring Data Redis 提供的一個完成 Redis 操作、異常轉換和序列化的類，我們可以類比 JdbcTemplate 去使用它。官方文檔地址：

docs.spring.io - RedisTemplate

4.緩存實現

下面我們來嘗試實現為項目的圖書館頁面和筆記本（文章）頁面加上緩存。首先編寫一個 Service 類，封裝我們將要用到的操作。

package com.gm.wj.redis;import org.springframework.beans.factory.annotation.Autowired; import org.springframework.data.redis.core.*; import org.springframework.stereotype.Service;import java.util.Set; import java.util.concurrent.TimeUnit;@Service public class RedisService {@Autowiredprivate RedisTemplate<String, Object> redisTemplate;// 設置帶過期時間的緩存public void set(String key, Object value, long time) {redisTemplate.opsForValue().set(key, value, time, TimeUnit.SECONDS);}// 設置緩存public void set(String key, Object value) {redisTemplate.opsForValue().set(key, value);}// 根據 key 獲得緩存public Object get(String key) {return redisTemplate.opsForValue().get(key);}// 根據 key 刪除緩存public Boolean delete(String key) {return redisTemplate.delete(key);}// 根據 keys 集合批量刪除緩存public Long delete(Set<String> keys) {return redisTemplate.delete(keys);}// 根據正則表達式匹配 keys 獲取緩存public Set<String> getKeysByPattern(String pattern) {return redisTemplate.keys(pattern);} }

注意這里存儲對象均被視為 Object，如果存儲對象為 String，可以進一步使用 StringRedisTemplate 來實現更貼合字符串的處理方法。

接下來，就可以在具體的 Service 里添加緩存的處理邏輯。

BookService：

針對獲取圖書列表的請求，可以先根據設置的 key 查詢緩存，如果有則直接從緩存里獲取，如果沒有則從數據庫查詢并寫入緩存。

public List<Book> list() {List<Book> books;String key = "booklist";Object bookCache = redisService.get(key);if (bookCache == null) {Sort sort = new Sort(Sort.Direction.DESC, "id");books = bookDAO.findAll(sort);redisService.set(key, books);} else {books = CastUtils.objectConvertToList(bookCache, Book.class);}return books; }

注意從緩存拿回來的是 Object ，我們需要編寫一個方法把它轉換為 List：

public static <T> List<T> objectConvertToList(Object obj, Class<T> clazz) {List<T> result = new ArrayList<T>();if(obj instanceof List<?>){for (Object o : (List<?>) obj){result.add(clazz.cast(o));}return result;}return null; }

如果我們對圖書的信息進行了修改，需要對緩存也進行相應的修改。因為我們緩存的粒度是整個列表，所以在對數據庫進行增刪改操作時可以直接將書籍列表的緩存全部清除。

這樣其實避免了上面說的緩存更新順序不一致的問題，我就硬刪除，先刪后刪緩存里結果都一樣。

public void addOrUpdate(Book book) {redisService.delete("booklist");bookDAO.save(book);}public void deleteById(int id) {redisService.delete("booklist");bookDAO.deleteById(id);}

問題還是來了，即使在理想的情況下，數據庫和緩存的操作都不會失敗，假如我在后臺刪了一本書，緩存被清除了，數據庫還沒來得及更新，這個節骨眼上有用戶訪問了一下，結果又拿到了舊的數據還寫入了緩存，那下次清除緩存前用戶拿到的全是舊數據。

如果我先改數據庫再刪緩存呢？

public void addOrUpdate(Book book) {bookDAO.save(book);redisService.delete("booklist");}public void deleteById(int id) {bookDAO.deleteById(id);redisService.delete("booklist");}

還是不妥，雖然前面沒刪緩存，但假如緩存先自然失效了，用戶的訪問還是會觸發緩存寫入操作，此后極短時間內我們又更新了書籍，這兩個事件是異步的，我們無法得知緩存寫入何時能夠完成，如果是在緩存刪除之后，那緩存中就還是會長期存在舊的數據。

此外，如果前面不刪緩存，有那么一丟丟的時間，數據庫更新了而緩存沒有更新，用戶還是會拿到舊的數據。

前后刪都不行，怎么辦？

又有人提出了 “延時雙刪” 策略，就是先清除緩存，在更新數據庫后，等一段時間，再去第二次執行刪除操作。這樣，用戶拿到舊庫的數據，并且在第二次刪除緩存之后才觸發緩存更新的概率就比較低。這個時間怎么把握呢？可以測試、估算，沒有一個準數。這個過程最好設置成異步的，以免阻塞正常操作。

在這個等待的過程中，還是可能出現有用戶讀到舊數據的緩存的情況，腦殼疼。。。

現實中還有很多更合理高效的方案，但我估計都不那么完美，我們只能根據實際需要，在合理的成本范圍內做出選擇。

OK，最后再貼一下為文章設置緩存的代碼：

package com.gm.wj.service;import com.gm.wj.dao.JotterArticleDAO; import com.gm.wj.entity.JotterArticle; import com.gm.wj.redis.RedisService; import com.gm.wj.util.MyPage; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.data.domain.Page; import org.springframework.data.domain.PageRequest; import org.springframework.data.domain.Sort; import org.springframework.stereotype.Service;import java.util.Set;@Service public class JotterArticleService {@AutowiredJotterArticleDAO jotterArticleDAO;@AutowiredRedisService redisService;// MyPage 是自定義的 Spring Data JPA Page 對象的替代public MyPage list(int page, int size) {MyPage<JotterArticle> articles;// 用戶訪問列表頁面時按頁緩存文章String key = "articlepage:" + page;Object articlePageCache = redisService.get(key);if (articlePageCache == null) {Sort sort = new Sort(Sort.Direction.DESC, "id");Page<JotterArticle> articlesInDb = jotterArticleDAO.findAll(PageRequest.of(page, size, sort));articles = new MyPage<>(articlesInDb);redisService.set(key, articles);} else {articles = (MyPage<JotterArticle>) articlePageCache;}return articles;}public JotterArticle findById(int id) {JotterArticle article;// 用戶訪問具體文章時緩存單篇文章，通過 id 區分String key = "article:" + id;Object articleCache = redisService.get(key);if (articleCache == null) {article = jotterArticleDAO.findById(id);redisService.set(key, article);} else {article = (JotterArticle) articleCache;}return article;}public void addOrUpdate(JotterArticle article) {jotterArticleDAO.save(article);// 刪除當前選中的文章和所有文章頁面的緩存redisService.delete("article" + article.getId());Set<String> keys = redisService.getKeysByPattern("articlepage*");redisService.delete(keys);}public void delete(int id) {jotterArticleDAO.deleteById(id);// 刪除當前選中的文章和所有文章頁面的緩存redisService.delete("article:" + id);Set<String> keys = redisService.getKeysByPattern("articlepage*");redisService.delete(keys);} }

這里我就直接后刪緩存了，不多費勁。這里注意 Spring Data JPA 的 Page 對象無法被反序列化，因為它的實現類 PageImpl 沒有空參構造器。因此我們需要自定義一個 MyPage 類：

package com.gm.wj.util;import org.springframework.data.domain.Page; import java.io.Serializable; import java.util.ArrayList; import java.util.Collections; import java.util.Iterator; import java.util.List;public class MyPage<T> implements Iterable<T>, Serializable {private static final long serialVersionUID = -3720998571176536865L;private List<T> content = new ArrayList<>();private long totalElements;private int pageNumber;private int pageSize;private boolean first;private boolean last;private boolean empty;private int totalPages;private int numberOfElements;public MyPage() {}//只用把原來的page類放進來即可public MyPage(Page<T> page) {this.content = page.getContent();this.totalElements = page.getTotalElements();this.pageNumber = page.getPageable().getPageNumber();this.pageSize = page.getPageable().getPageSize();this.numberOfElements = page.getNumberOfElements();}//是否有前一頁public boolean hasPrevious() {return getPageNumber() > 0;}//是否有下一頁public boolean hasNext() {return getPageNumber() + 1 < getTotalPages();}//是否第一頁public boolean isFirst() {return !hasPrevious();}//是否最后一頁public boolean isLast() {return !hasNext();}//獲取內容public List<T> getContent() {return Collections.unmodifiableList(content);}//設置內容public void setContent(List<T> content) {this.content = content;}//是否有內容public boolean hasContent() {return getNumberOfElements() > 0;}//獲取單頁大小public int getPageSize() {return pageSize;}//設置單頁大小public void setPageSize(int pageSize) {this.pageSize = pageSize;}//獲取全部元素數目public long getTotalElements() {return totalElements;}//設置全部元素數目public void setTotalElements(long totalElements) {this.totalElements = totalElements;}//設置是否第一頁public void setFirst(boolean first) {this.first = first;}// 設置是否最后一頁public void setLast(boolean last) {this.last = last;}//獲取當前頁號public int getPageNumber() {return pageNumber;}//設置當前頁號public void setPageNumber(int pageNumber) {this.pageNumber = pageNumber;}//獲取總頁數public int getTotalPages() {return getPageSize() == 0 ? 1 : (int) Math.ceil((double) totalElements / (double) getPageSize());}//設置總頁數public void setTotalPages(int totalPages) {this.totalPages = totalPages;}//獲取單頁元素數目public int getNumberOfElements() {return numberOfElements;}//設置單頁元素數目public void setNumberOfElements(int numberOfElements) {this.numberOfElements = numberOfElements;}//判斷是否為空public boolean isEmpty() {return !hasContent();}//設置是否為空public void setEmpty(boolean empty) {this.empty = empty;}//迭代器@Overridepublic Iterator<T> iterator() {return getContent().iterator();} }

唉，還是這么多代碼，到時候報錯多了又得有人噴我，幸虧我一直比較皮實，心態還算可以。

5.驗證

以 Windows 為例，打開緩存服務（cmd 進入緩存文件夾，執行 redis-sever），顯示界面如下：

打開項目，可以在 application.properties 中配置一條語句，顯示后端執行的 sql 命令：

spring.jpa.properties.hibernate.show_sql=true

運行項目，訪問文章頁面、圖書館頁面、點擊最上面的文章。

這時，控制臺顯示了一些語句

可以再啟動一個終端，進入 redis 目錄輸入 redis-cli 打開客戶端，輸入 keys * 查看保存的鍵

可以看到，第 1 頁（JPA 分頁默認第一頁為 0）、圖書列表、第三篇文章（逆序第一篇）被添加進了 Redis 里。

之后，我們再刷新圖書館、筆記本頁面或者訪問第一篇文章時，sql 語句就不會再顯示了。

不知道大家是否還記得前面提到過的 JPA 持久化上下文，實際上，就算輸出了這些指令，也不會真的去查詢數據庫，而是復用之前已經查詢到的對象。那為什么還要用 Redis 呢？其實一開始我也說了，真的沒有必要。

當然，這只是因為我們的項目結構比較簡單。假如我們想把緩存服務部署在別的服務器上，持久化上下文就無法生效了。或者我想使用更靈活的算法，比如只緩存比較活躍的數據，而不是來者不拒，就還是需要有更強大的能力支持。

小結

這篇文章說的東西比較多，稍微做個總結吧。

不用記得太多，下面幾句話就夠了：

緩存是工程思想的產物，是解決不對稱問題的一種優秀實踐，并得到了廣泛應用
緩存的引入會提高項目復雜度，要綜合取舍使用方案
Redis 不是緩存，但可以實現緩存服務

在寫新的內容之外，我準備背地里偷偷優化一下前面的文章，不過你們都看到這兒了，也沒必要回頭再去找哪些地方改了，向前看就好了。

之前開玩笑說這個教程能寫到退休，但我仔細想了一下，還是盡快地收個尾吧，都兩年了，再過去兩年，可能教程里用的技術都過時百分之八十了。

這個系列完結后，我會多寫一些偏理論的文章。我干的工作比較雜，比起深入鉆研一個技術點，可能還是更適合幫助大家了解一個行業、一個生態的全貌。

各位放心，我不會再鴿這么長時間了，那倆垃圾游戲已經被我打通關了，DLC 什么的等我漲工資了再買吧。

2020 都不容易，送給大家一句話，要敢于做困難事，堅持做困難事，困難是人進步的源泉，總有一天你會發現，自己變禿了，也變強了。

總有人覺得一年不如一年，但我始終認為我們就身處在最好的時代，風起云涌，無限可能。

上一篇：Vue + Spring Boot 項目實戰（二十）：前端優化實戰

附錄：關于單元測試

本來按照計劃下一篇要講一講單元測試，但是我發現白卷項目在可測試性上一塌糊涂，在寫下一篇文章前折騰了兩天，還是沒能讓單元測試的代碼符合我自己的審美。（嗯，這個理由我認可了）

那這里我們先打個引子，講一講單元測試是什么、有什么用以及重點在哪里。其它的以后再說吧，不然又要托更了。

首先，關于測試，比較常見的分類方式有：

按開發周期：單元測試、集成測試、系統測試、驗收測試
按實施者：α、β、第三方
按是否執行代碼：靜態測試、動態測試
按代碼可見性：黑盒測試、白盒測試、灰盒測試
按是否自動執行：自動化測試、手工測試
按測試對象：性能測試、安全測試、兼容性測試、文檔測試、易用性測試、業務測試、界面測試、可安裝性測試

在這個框架之下，我們所說的單元測試，是指開發人員在代碼編寫階段同步實施的動態白盒測試，測試內容一般是業務邏輯和安全性，既可以手動編寫測試代碼，也可以借助一些自動化工具。

作為程序員，寫單元測試是一件煩躁的事情。因為寫單元測試，看起來大部分都是無用功，會嚴重拖慢開發的進程。

有一種常見的想法就是，代碼質量和工作效率不可兼得，我知道測試有用，但現在就是著急出成果，沒辦法，不得不先放下。

這種想法乍一看沒什么問題，我也時常覺得推進工作需要權衡和妥協，但實際上，代碼質量與工作效率并不矛盾，這種認識是一種誤區。如果不注重代碼質量，也許只是起步快一點，但在通往終點的路上，一定困難重重。

不只是開發，其實在任何工作中都是這樣一個規律，那就是問題發現的越早，解決問題需要的成本就越低。我們雖然無法做到萬無一失，但一定要在心里有一桿秤，什么樣的風險是要盡量早些規避的。評估風險的大小有一個簡單的公式，即：

風險 = 損失 * 概率

其實單元測試的重點不是編寫測試代碼的套路，它真正的功夫體現在測試用例的設計上。而設計全面且高效的測試用例并不那么容易，需要有相當全面的知識，老道的經驗，還要講究一些方法論，比如等價類劃分、邊界值分析等。

我有一個朋友，有一天寫了一個登錄功能，跑起來一試，賬號 admin，密碼 123 ，進去了，歐了。

過了一天，覺得不對勁，試了試賬號 admin，密碼 456，也進去了，他說哦，原來是昨天，有個地方寫錯了，改了就完了。

又過了兩天，又覺得不對，試了試賬號 admin，密碼不填，又進去了，好吧，大意了，再來一遍。

終于覺得沒有問題了，代碼到了測試手里。沒多久突然有個同事問他發生甚么事了，給他發來幾張截圖，他一看代碼被返工了，老大臉色鐵青地殺過來一頓臭罵。兩分多鐘以后，測試跑過來說對不起對不起，我不是找茬，我就隨便一試。他可不是隨便一試啊，暴力破解、SQL 注入、XSS，訓練有素，后來他說他學過三四年滲透，看來是有備而來。

后來，我這個朋友沒事就跑到測試旁邊，觀察他們的用例，模仿他們的做法，漸漸地犯的錯誤就越來越少了。

實際上當你時刻把單元測試放在心上，即使這個測試并沒有執行，也會極大地減少犯錯的概率，提高代碼的質量。