一、序言
在使用MyBatis、MybatisPlus等DAO層資料庫訪問框架式，常常會與一級快取、二級快取打交道，為了增強對快取體系的整體把控力，提高軟體應用回應速度，這里對三級快取一次梳理，
快取固然能夠提高系統性能，與此同時也帶來了臟資料的副作用，系統的快取體系、快取結構、快取策略、快取介質等對可能出現的臟資料產生影響，
快取是一把雙刃劍，既能夠提高應用系統的效率，同時避免臟資料發生也是不小的作業量，特別是不同的層次的快取同時使用時，出現資料例外的概率快速提高，
二、一級快取
以MyBatis技術為基礎的一級快取默認是開啟的且無法關閉，有SESSION和STATEMENT兩種型別，同一會話在關閉前可以執行多個陳述句，會話在關閉時，一級快取生命周期結束，常見的情況是一個會話執行一條SQL陳述句，因此這兩種型別區別不大，
mybatis:
configuration:
# 強制使用陳述句級快取
local-cache-scope: statement
1、臟資料分析
一級快取可能出現的臟資料問題：當一次會話呼叫兩次以上相同的查詢陳述句（包含查詢條件）時，第二次以后呼叫會從本地快取取資料，與此同時如果另一個會話將有關的資料修改，顯而易見從快取查詢的資料是臟資料，
盡管這種現象是存在的，考慮到會話的持續時間可控，會話結束后資料查詢即恢復正常，大多數情況下資料的實時行達不到此要求，
2、回避臟資料
- 強制使用陳述句級快取
在全域配置中強制使用陳述句級快取，防止系統因會話未及時關閉而產生的快取臟資料
- 會話及時關閉
推薦一個會話僅執行一條SQL陳述句，并且SQL陳述句執行完畢后及時關倍訓話，會話關閉時，根據事務自動提交機制，本次會話快取自動釋放，
- 避免使用復雜查詢陳述句
將復雜查詢陳述句轉變成多條簡單陳述句，在業務層通過事務匯總處理，事實上，隨著資料量的急劇膨脹，復雜SQL陳述句對查詢性能的負面影響越來越大，MybatisPlus連接查詢解決方案甚至強烈推薦開發者棄用傳統方式上的多表連接查詢，
三、二級快取
二級快取面向namespace，同一個 Mapper 檔案下所有的 DAO 方法都能對快取施加影響，二級快取默認是關閉狀態，
正確使用二級快取，請參考MybatisPlus二級快取解決方案一文，
1、臟資料分析
二級快取產生臟資料的情況有很多，典型的場景如下：
- 聯合查詢
當表 A 和表 B 聯合查詢時，將查詢資料添加至所在 Mapper 所屬namespace的快取中，與此同時，表 A 或者表 B 對資料庫資料做了更新，聯合查詢與更新表如果不在同一個namespace下，在快取重繪時間結束前是收不到更新快取的信號的，毫無疑問是存在臟資料的，
2、回避臟資料
- 設定合理的快取過期時間
二級快取資料強制設定過期時間，保證快取資料擁有被動失效的能力，
- 避免使用傳統意義上的多表連接查詢
強烈推薦使用MybatisPlus作為基礎技術操作資料訪問，保證能夠正確的基于namespace為單位的快取資料能夠主動重繪，新型多表連接查詢操作，請查看MybatisPlus連接查詢解決方案，
四、三級快取
三級快取指業務層快取，通常面向service層，主要快取不常變化或者重復計算耗費CPU資源的資料，一般來講，三級快取存在于二級快取之上，業務層快取實作非常多，常見有快取實作有：
- Caffeine使用手冊
- EhCache使用手冊
- Redis使用手冊
業務層快取自主可控強，能夠全方位掌控快取的生命周期，相當靈活方便，
1、使用場景
業務快取，顧名思義是因處理業務流程而產生的資料快取需要，比如說一項重復的計算，因為呼叫頻率較高，因此可以對結果予以快取，
業務層呼叫DAO層獲取資料建議使用二級快取完成，業務層的主要目標是使用資料，快取資料并不是其主要職責，
五、介面快取
介面快取面向整個介面，面向用戶端提高介面的回應性能，介面層可以直接呼叫資料訪問層，或者呼叫資料訪問層（二級快取），異或呼叫業務層，異或呼叫業務層（三級快取），甚至對介面回傳結果本身進行快取，
喜歡本文就【??推薦??】一下，激勵我持續創作，這個Github同樣精彩，收到您的star我會很激動，本文歸檔在專題博客，視頻講解在B站，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/436307.html
標籤：Java