Spring Boot2(二):使用Spring Boot2整合Mybatis快取機制
前言
學習SpringBoot整合Mybatis的第二章,瞭解到Mybatis自帶的快取機制,在部署的時候踩過了一些坑。在此記錄和分享一下Mybatis的快取作用。
本文章的原始碼再文章末尾
什麼是查詢快取
MyBatis有一級快取和二級快取。記錄可以看下這篇博文:
一級快取
首先看一下什麼是一級快取,一級快取是指SqlSession。一級快取的作用域是一個SqlSession。Mybatis預設開啟一級快取。
在同一個SqlSession中,執行相同的查詢SQL,第一次會去查詢資料庫,並寫到快取中;第二次直接從快取中獲取。當執行SQL查詢前後發生增刪改操作時,則SqlSession的快取清空。
具體可以看這段程式碼:
@Test public void testLocalCacheScope() throws Exception { SqlSession sqlSession1 = factory.openSession(true); SqlSession sqlSession2 = factory.openSession(true); StudentMapper studentMapper = sqlSession1.getMapper(StudentMapper.class); StudentMapper studentMapper2 = sqlSession2.getMapper(StudentMapper.class); System.out.println("studentMapper讀取資料: " + studentMapper.getStudentById(1)); System.out.println("studentMapper讀取資料: " + studentMapper.getStudentById(1)); System.out.println("studentMapper2更新了" + studentMapper2.updateStudentName("小岑",1) + "個學生的資料"); System.out.println("studentMapper讀取資料: " + studentMapper.getStudentById(1)); System.out.println("studentMapper2讀取資料: " + studentMapper2.getStudentById(1)); }
開啟兩個sqlSession
從列印日誌可以看出,前面兩個說明sqlSession1的會話快取生效了,第三個對sqlSession2會話執行了更新操作,這時候資料庫發生資料變化,sqlSession2被清空。可是在執行第四個查詢是,是查詢的sqlSession1會話,由於sqlSession1沒有被清空,所以還是查詢的快取的資料,是資料更新之前的,查詢的是髒資料,一級快取sqlSession是不共享的。證明了一級快取只是在資料庫會話內部共享的。
二級快取
Mybatis的二級快取是指mapper對映檔案。二級快取的作用域是同一個namespace下的mapper對映檔案內容,多個SqlSession共享,Mybatis需要手動設定二級快取。
在同一個namespace下的mapper檔案中,執行相同的查詢SQL,第一次會查詢資料庫,並寫道快取中;第二次z直接從快取中獲取。當執行SQL查詢前後發生增刪改操作時,則二級快取清空。
上面說到二級快取可以共享多個SqlSession。可以解決不同SqlSession回話中查詢到髒資料的問題了。
SpringBoot整合Mybatis開啟二級快取
首先,Mybatis預設是開啟一級快取的,即同一個SqlSession每次查詢都會去快取中查詢,沒有資料的話,再去資料庫獲取資料。但是,整合到SpringBoot中後,一級快取就會被關閉。為什麼會出現這種原因呢,可以看下這篇文章:
好了,現在來建立專案,可以根據前一篇文章來建立專案,在這基礎上修改
pom.xml新增mybatis快取包caches
<dependency>
<groupId>org.mybatis.caches</groupId>
<artifactId>mybatis-ehcache</artifactId>
<version>1.1.0</version>
</dependency>
SysUserDao.xml新增開啟Mybatis二級快取
<cache />
加上這個標籤,二級快取就會開啟,他的預設屬性如下
- 對映語句檔案中的所有 select 語句將會被快取。
- 對映語句檔案中的所有 insert,update 和 delete 語句會重新整理快取。
- 快取會使用 Least Recently Used(LRU,最近最少使用的)演算法來收回。
- 根據時間表(比如 no Flush Interval,沒有重新整理間隔), 快取不會以任何時間順序來重新整理。
- 快取會儲存列表集合或物件(無論查詢方法返回什麼)的 1024 個引用。
快取會被視為是 read/write(可讀/可寫)的快取,意味著物件檢索不是共享的,而且可以安全地被呼叫者修改,而不干擾其他呼叫者或執行緒所做的潛在修改。
也可以自定義二級快取的屬性,例如:
<cache
eviction="FIFO"
flushInterval="60000"
size="512"
readOnly="true"/>
這個更高階的配置建立了一個 FIFO 快取,並每隔 60 秒重新整理,存數結果物件或列表的 512 個引用,而且返回的物件被認為是隻讀的,因此在不同執行緒中的呼叫者之間修改它們會 導致衝突。
可用的收回策略有:
- LRU – 最近最少使用的:移除最長時間不被使用的物件。
- FIFO – 先進先出:按物件進入快取的順序來移除它們。
- SOFT – 軟引用:移除基於垃圾回收器狀態和軟引用規則的物件。
- WEAK – 弱引用:更積極地移除基於垃圾收集器狀態和弱引用規則的物件。
預設的是 LRU。
flushInterval(重新整理間隔)可以被設定為任意的正整數,而且它們代表一個合理的毫秒 形式的時間段。預設情況是不設定,也就是沒有重新整理間隔,快取僅僅呼叫語句時重新整理。
size(引用數目)可以被設定為任意正整數,要記住你快取的物件數目和你執行環境的 可用記憶體資源數目。預設值是 1024。
readOnly(只讀)屬性可以被設定為 true 或 false。只讀的快取會給所有呼叫者返回緩 存物件的相同例項。因此這些物件不能被修改。這提供了很重要的效能優勢。可讀寫的快取 會返回快取物件的拷貝(通過序列化) 。這會慢一些,但是安全,因此預設是 false。
測試驗證
編寫Controller介面
/**
* 查詢所有使用者資訊
* @return
*/
@RequestMapping("/getAll")
private List<SysUserEntity> getUser() {
List<SysUserEntity> userList = sysUserService.queryUserAll();
return userList;
}
/**
* 根據userId查詢使用者資訊
* @return
*/
@RequestMapping("/getUser")
private List<SysUserEntity> getUser(@RequestParam(value = "userId", required = false) Long userId) {
List<SysUserEntity> userList = sysUserService.queryUserInfo(userId);
return userList;
}
/**
* 更新使用者資訊
* @param user
* @return
*/
@RequestMapping("/updateUser")
private int updateUser(@RequestBody SysUserEntity user) {
return sysUserService.updateUserInfo(user);
}
通過postman傳送介面請求進行測試:
1、傳送查詢使用者全部資訊:http://localhost:8080/getAll
2、根據userId查詢使用者資訊:http://localhost:8080/getUser?userId=1
3、更新使用者資訊http://localhost:8080/updateUser
更新使用者資訊介面傳送報文:
{
"userId":5,
"email":"12321321",
"mobile":"11111111111213"
}
通過日誌可以看到,第一次傳送1介面請求,對資料庫進行了查詢
可以看到,第二次和第三次查詢沒有查詢資料庫的SQL列印,而是去資料庫獲取資料
此時傳送3介面,進行更新操作,在傳送1介面,查詢改使用者的資料
可以看到,當執行資料庫更新操作後,再進行查詢,此時快取已經清空,需要從資料庫中重新查詢獲取。
這就演示了SpringBoot整合Mybatis的快取機制測試。
總結
1、快取的物件必須實現序列化。因為二級快取的資料不一定都是儲存到記憶體中,它的儲存介質多種多樣,所以需要給快取的物件執行序列化,才可以確保獲取無誤。
2、Mybatis的二級快取相比於一級快取來說,實現了SqlSession之間的快取資料的共享,做到namespace級別,粒度更細
3、在分散式環境下,由於預設的MyBatis Cache實現都是基於本地的,分散式環境下必然會出現讀取到髒資料,需要使用集中式快取將MyBatis的Cache介面實現,有一定的開發成本,直接使用Redis、Memcached等分散式快取可能成本更低,安全性也更高。
不過建議Mybatis的快取特性再生產環境下進行關閉,單純作為一個
使用可能更加合適。
下篇文章計劃寫SpringBoot整合Mybatis,使用Redis實現快取基本配置。
示例程式碼-git