1. 從一次線上查詢超時說起為什么我們需要關(guān)注MyBatis緩存那天下午監(jiān)控系統(tǒng)突然告警一個核心的訂單詳情接口響應(yīng)時間從平時的50ms飆升至5秒以上。我們緊急排查數(shù)據(jù)庫負載正常SQL執(zhí)行計劃也沒問題最后定位到問題出在應(yīng)用層——一個被高頻調(diào)用的getOrderById方法。這個方法邏輯很簡單就是根據(jù)ID從數(shù)據(jù)庫查一條記錄。在壓力測試時我們明明看到它很快為什么線上就慢了呢深入代碼發(fā)現(xiàn)這個方法在一個循環(huán)中被調(diào)用了上百次每次調(diào)用都“看似”獨立地執(zhí)行了一次數(shù)據(jù)庫查詢。問題的根源就在于開發(fā)者對MyBatis的緩存機制一無所知或者說沒有正確地理解和利用它。如果當時正確配置并理解了MyBatis的三級緩存這次事故完全可以避免數(shù)據(jù)庫的壓力也能大幅降低。這就是我們今天要深入探討的MyBatis三級緩存。它絕不僅僅是配置文件里的幾個開關(guān)而是一個貫穿SqlSession生命周期、甚至應(yīng)用生命周期的性能優(yōu)化體系。理解它你就能寫出更高效、更健壯的數(shù)據(jù)庫訪問代碼忽視它你可能就會埋下我們剛剛提到的性能陷阱甚至是更棘手的數(shù)據(jù)一致性問題。簡單來說MyBatis的三級緩存為我們提供了三層數(shù)據(jù)暫存區(qū)一級緩存也叫本地緩存Local Cache它的作用域是一個SqlSession。在同一個SqlSession中執(zhí)行相同的查詢MyBatis會直接從內(nèi)存返回結(jié)果而不會再次訪問數(shù)據(jù)庫。二級緩存它的作用域是一個Mapper的命名空間Namespace可以跨SqlSession共享。當多個SqlSession操作同一個Mapper時它們可以共享緩存數(shù)據(jù)。三級緩存這是一個更寬泛的概念指的是整合外部緩存中間件如Redis、Ehcache等實現(xiàn)應(yīng)用級甚至分布式級別的緩存共享。接下來我們將一層層剝開它的面紗不僅告訴你它是什么、怎么用更重要的是結(jié)合我踩過的坑告訴你為什么這么設(shè)計以及在實際生產(chǎn)中如何權(quán)衡利弊、規(guī)避風險。2. 一級緩存SqlSession級別的“私人備忘錄”你可以把一級緩存想象成每個SqlSession自帶的“私人備忘錄”。當這個SqlSession執(zhí)行一條查詢語句后它會把結(jié)果記在自己的小本本緩存上。如果緊接著在同一個SqlSession里又執(zhí)行了一模一樣的查詢它就不會再去麻煩數(shù)據(jù)庫執(zhí)行SQL而是直接從小本本上把結(jié)果抄過來。2.1 一級緩存的工作原理與生命周期一級緩存是默認開啟的你不需要做任何配置。它的實現(xiàn)非常直接底層就是一個簡單的HashMap存儲的Key是CacheKey對象。這個CacheKey由哪些因素決定呢它是由以下元素共同計算出來的Mapper Statement的ID即命名空間方法名。查詢的偏移量offset和限制條數(shù)limit即分頁參數(shù)。本次查詢所生成的SQL語句。傳遞給SQL的實際參數(shù)值。環(huán)境ID如果你的配置了多個數(shù)據(jù)源環(huán)境。只有當以上所有條件都完全一致時MyBatis才會認為兩次查詢是“相同的”從而命中一級緩存。那么這個“私人備忘錄”什么時候會失效、被清空呢理解這一點至關(guān)重要執(zhí)行了增、刪、改操作INSERT, UPDATE, DELETE這是最常見也最容易被忽略的失效條件。只要在同一個SqlSession中執(zhí)行了任何寫操作無論這個寫操作是否影響到你緩存的數(shù)據(jù)整個一級緩存都會被清空。這是MyBatis為了保證數(shù)據(jù)強一致性而采取的保守策略。例如你先查詢了用戶A的信息然后修改了用戶B的信息此時再查詢用戶A緩存已經(jīng)失效會重新查庫。手動調(diào)用sqlSession.clearCache()方法這是顯式清空緩存的方式。對SqlSession執(zhí)行了commit()或close()操作提交事務(wù)或關(guān)閉會話自然意味著當前會話的結(jié)束緩存也隨之銷毀。在Mapper映射文件中配置了flushCachetrue這通常用于特定的查詢語句強制每次執(zhí)行都刷新緩存。2.2 一級緩存的典型陷阱與實戰(zhàn)解析很多開發(fā)者對一級緩存的認知停留在“同會話同查詢不走數(shù)據(jù)庫”的層面這遠遠不夠。下面結(jié)合幾個真實場景看看它如何“坑人”。場景一循環(huán)中的無效查詢這就是我們開篇事故的簡化版。假設(shè)有以下代碼try (SqlSession sqlSession sqlSessionFactory.openSession()) { OrderMapper mapper sqlSession.getMapper(OrderMapper.class); for (Long id : idList) { // 開發(fā)者以為每次循環(huán)都是獨立的查詢 Order order mapper.selectOrderById(id); // ... 處理order } }如果idList包含100個不同的ID這段代碼會執(zhí)行100次數(shù)據(jù)庫查詢嗎會的。因為每次查詢的CacheKey中的參數(shù)值id都不同所以無法命中緩存。一級緩存在這里沒有起到任何優(yōu)化作用。正確的優(yōu)化應(yīng)該是在業(yè)務(wù)邏輯層做聚合查詢或者使用二級緩存。場景二寫操作引發(fā)的“幽靈”失效try (SqlSession sqlSession sqlSessionFactory.openSession()) { UserMapper mapper sqlSession.getMapper(UserMapper.class); // 第一次查詢緩存結(jié)果 User user1 mapper.selectUserById(1L); System.out.println(user1.getName()); // 輸出: 張三 // 執(zhí)行一個無關(guān)的更新操作 mapper.updateUserStatus(2L, inactive); // 更新了ID2的用戶 // 第二次查詢參數(shù)完全相同 User user2 mapper.selectUserById(1L); System.out.println(user2.getName()); // 輸出: 張三但這次真的又訪問了數(shù)據(jù)庫 // 因為update操作清空了整個一級緩存 }這個例子清晰地展示了MyBatis一級緩存“寧可錯殺不可放過”的失效策略。即使你更新的是ID2的用戶ID1的用戶的緩存也被清除了。這在一些復雜的業(yè)務(wù)邏輯中可能導致性能波動難以定位。場景三Spring集成下的特殊表現(xiàn)在Spring MyBatis的經(jīng)典組合中我們通常使用Transactional注解來管理事務(wù)。Spring默認將SqlSession的生命周期與事務(wù)綁定。這意味著在同一個Transactional方法內(nèi)部多次調(diào)用同一個查詢是可以命中一級緩存的。但是一旦方法執(zhí)行完畢事務(wù)提交SqlSession就被關(guān)閉緩存也隨之銷毀。因此跨方法的調(diào)用即使是在同一個Service類中如果不在同一個事務(wù)上下文中就無法利用一級緩存。實操心得一級緩存更像是一個“會話內(nèi)”的臨時加速器它的作用域太小失效又太“激進”。對于大多數(shù)需要性能優(yōu)化的場景我們不能依賴它。它的主要價值在于避免在同一個事務(wù)方法內(nèi)對完全相同的數(shù)據(jù)進行重復查詢。在代碼審查時要特別警惕在循環(huán)內(nèi)進行單條查詢的模式這通常是一級緩存無法優(yōu)化的性能瓶頸點。3. 二級緩存Namespace級別的“團隊共享白板”如果一級緩存是私人備忘錄那么二級緩存就是掛在團隊辦公室里的“共享白板”。它的作用域是一個Mapper的namespace所有屬于這個namespace的SqlSession都可以讀取和寫入這塊白板。3.1 二級緩存的啟用與核心配置二級緩存默認是關(guān)閉的需要顯式開啟。配置分為兩步第一步在MyBatis全局配置文件mybatis-config.xml中開啟緩存通常默認就是開啟的。settings !-- 默認就是true通常不需要顯式配置 -- setting namecacheEnabled valuetrue/ /settings第二步在需要啟用二級緩存的Mapper XML文件中添加cache/標簽。?xml version1.0 encodingUTF-8? !DOCTYPE mapper PUBLIC -//mybatis.org//DTD Mapper 3.0//EN http://mybatis.org/dtd/mybatis-3-mapper.dtd mapper namespacecom.example.mapper.UserMapper !-- 聲明啟用本Mapper的二級緩存 -- cache/ select idselectUserById resultTypeUser select * from user where id #{id} /select !-- ... 其他語句 -- /mapper一個簡單的cache/標簽會使用MyBatis默認的緩存實現(xiàn)一個基于內(nèi)存的LRU緩存。你可以通過標簽屬性進行詳細配置cache evictionLRU !-- 回收策略LRU最近最少使用、FIFO先進先出、SOFT軟引用、WEAK弱引用 -- flushInterval60000 !-- 刷新間隔毫秒。不設(shè)置則不清空 -- size1024 !-- 最多緩存對象個數(shù) -- readOnlytrue/ !-- 是否只讀。只讀緩存性能更高但返回的是緩存對象的引用修改它會影響緩存中的數(shù)據(jù) --重要提示readOnlytrue時MyBatis會直接返回緩存對象的引用性能最好但要求緩存的對象必須是可序列化的并且調(diào)用方不能修改返回的對象。readOnlyfalse時MyBatis會返回緩存對象的深拷貝通過序列化/反序列化安全但性能有損耗。3.2 二級緩存的工作機制與數(shù)據(jù)同步問題二級緩存的工作流程比一級緩存復雜當一個SqlSession執(zhí)行查詢后在關(guān)閉或提交時它才會決定是否將查詢結(jié)果提交到二級緩存。另一個SqlSession執(zhí)行查詢時會先嘗試從二級緩存中獲取。任何一個SqlSession執(zhí)行了INSERT、UPDATE、DELETE操作并提交后MyBatis會清空整個對應(yīng)Mapper namespace的二級緩存。這里就引出了二級緩存最核心、也最讓人頭疼的問題數(shù)據(jù)一致性問題。問題一跨命名空間的緩存污染假設(shè)有兩個MapperUserMapper和OrderMapper。Order對象中關(guān)聯(lián)了一個User對象通過userId。你在OrderMapper.xml中配置了cache/并寫了一個聯(lián)表查詢selectOrderWithUser。!-- OrderMapper.xml -- cache/ select idselectOrderWithUser resultMaporderWithUserMap select o.*, u.name as user_name from orders o left join user u on o.user_id u.id where o.id #{id} /select當你查詢一個訂單時用戶信息也會被緩存到OrderMapper的二級緩存中。此時如果另一個程序直接通過UserMapper更新了該用戶的名字OrderMapper的緩存是感知不到的它里面存儲的還是舊的用戶名。這就導致了數(shù)據(jù)不一致。解決方案通過cache-ref標簽建立緩存引用關(guān)系。!-- OrderMapper.xml -- cache-ref namespacecom.example.mapper.UserMapper/這樣OrderMapper就不會維護自己的緩存而是共享UserMapper的緩存空間。當UserMapper的緩存因更新而清空時OrderMapper查詢到的關(guān)聯(lián)用戶信息也會失效。但這種方式增加了耦合需謹慎使用。問題二多表操作與緩存清空粒度正如一級緩存二級緩存在執(zhí)行寫操作時清空的也是整個namespace的緩存。如果你有一個UserMapper里面既有selectUserById也有selectAllUsers。當你更新了一個用戶后所有用戶的緩存包括那個列表查詢的緩存都會被清空。這可能不是你想要的特別是當列表查詢非常耗時的時候。解決方案更精細的緩存控制。你可以在單個語句上設(shè)置useCache和flushCache屬性。select idselectAllUsers resultTypeUser useCachefalse select * from user /select將非常耗時的、或者實時性要求不高的列表查詢設(shè)置為useCachefalse不讓它進入二級緩存?；蛘邔τ谀承┫Ｍ麑崟r性的查詢設(shè)置flushCachetrue確保每次執(zhí)行都刷新緩存并獲取最新數(shù)據(jù)。3.3 二級緩存的適用場景與避坑指南二級緩存并非銀彈它有非常明確的適用邊界適合的場景只讀或極少修改的數(shù)據(jù)例如國家省份字典表、配置信息表、歷史歸檔數(shù)據(jù)等。對實時性要求不高的統(tǒng)計類查詢例如每日報表、歷史趨勢分析。單體應(yīng)用且數(shù)據(jù)訪問模式相對簡單沒有復雜的多表關(guān)聯(lián)更新。需要規(guī)避或謹慎使用的場景多表關(guān)聯(lián)且關(guān)聯(lián)表會被頻繁更新的查詢?nèi)缟衔乃鰳O易出現(xiàn)數(shù)據(jù)不一致。在分布式部署環(huán)境下默認的基于內(nèi)存的二級緩存是應(yīng)用內(nèi)緩存多個應(yīng)用實例之間無法同步。實例A更新了數(shù)據(jù)清空了自己的緩存但實例B的緩存里還是舊數(shù)據(jù)。對數(shù)據(jù)強一致性要求極高的業(yè)務(wù)如金融交易核心數(shù)據(jù)。實操心得我的建議是在中小型單體應(yīng)用中可以針對性地為少數(shù)真正的只讀數(shù)據(jù)開啟二級緩存并仔細評估其關(guān)聯(lián)關(guān)系。在微服務(wù)或分布式架構(gòu)中默認關(guān)閉所有二級緩存將緩存的需求上移到業(yè)務(wù)層使用Redis等分布式緩存中間件來統(tǒng)一管理這樣可控性、一致性和擴展性都更強。不要因為“可能有性能提升”就盲目開啟二級緩存它帶來的數(shù)據(jù)一致性問題往往比性能提升更棘手。4. 整合外部緩存“三級緩存”走向分布式與專業(yè)化當二級緩存無法滿足分布式環(huán)境下的數(shù)據(jù)共享和容量需求時我們就需要引入“三級緩存”——即外部的專業(yè)緩存中間件如Redis、Memcached、Ehcache集群模式等。MyBatis本身提供了一個Cache接口允許我們方便地集成這些實現(xiàn)。4.1 為何需要外部緩存分布式共享這是最主要的原因。在集群部署中多個應(yīng)用實例需要共享同一份緩存數(shù)據(jù)避免每個實例都緩存一份導致數(shù)據(jù)不一致和內(nèi)存浪費。容量與持久化應(yīng)用內(nèi)存有限而Redis等中間件可以提供GB甚至TB級別的緩存容量并且支持持久化防止應(yīng)用重啟后緩存雪崩。豐富的特性外部緩存提供了更豐富的功能如設(shè)置不同的過期時間TTL、發(fā)布訂閱、復雜數(shù)據(jù)結(jié)構(gòu)支持、高可用集群等。專業(yè)化管理緩存中間件有專業(yè)的監(jiān)控、管理和運維工具便于排查問題。4.2 如何集成Redis作為MyBatis二級緩存這里以集成Redis為例展示一種常見的實現(xiàn)方式。我們通常不直接替換MyBatis默認的二級緩存而是通過實現(xiàn)org.apache.ibatis.cache.Cache接口創(chuàng)建一個RedisCache。第一步添加依賴以Spring Boot為例dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency第二步實現(xiàn)Cache接口import org.apache.ibatis.cache.Cache; import org.springframework.data.redis.core.RedisTemplate; import org.springframework.data.redis.serializer.StringRedisSerializer; import java.util.concurrent.TimeUnit; import java.util.concurrent.locks.ReadWriteLock; import java.util.concurrent.locks.ReentrantReadWriteLock; public class RedisCache implements Cache { private final ReadWriteLock readWriteLock new ReentrantReadWriteLock(); private final String id; // Mapper的namespace private static RedisTemplateString, Object redisTemplate; // 需要靜態(tài)注入 public RedisCache(String id) { if (id null) { throw new IllegalArgumentException(Cache instances require an ID); } this.id id; } // 靜態(tài)方法用于在應(yīng)用啟動時注入RedisTemplate public static void setRedisTemplate(RedisTemplateString, Object redisTemplate) { RedisCache.redisTemplate redisTemplate; // 建議設(shè)置key和value的序列化器這里示例使用String序列化keyJackson序列化value redisTemplate.setKeySerializer(new StringRedisSerializer()); // 設(shè)置ValueSerializer例如使用GenericJackson2JsonRedisSerializer } Override public String getId() { return this.id; } Override public void putObject(Object key, Object value) { if (redisTemplate ! null value ! null) { // 將CacheKey轉(zhuǎn)換為String作為Redis的key String redisKey id : key.toString(); // 存入Redis可以設(shè)置過期時間例如30分鐘 redisTemplate.opsForValue().set(redisKey, value, 30, TimeUnit.MINUTES); } } Override public Object getObject(Object key) { if (redisTemplate ! null) { String redisKey id : key.toString(); return redisTemplate.opsForValue().get(redisKey); } return null; } Override public Object removeObject(Object key) { if (redisTemplate ! null) { String redisKey id : key.toString(); Object oldValue redisTemplate.opsForValue().get(redisKey); redisTemplate.delete(redisKey); return oldValue; } return null; } Override public void clear() { // 清空整個namespace的緩存可以使用通配符刪除 if (redisTemplate ! null) { SetString keys redisTemplate.keys(id :*); if (keys ! null !keys.isEmpty()) { redisTemplate.delete(keys); } } } Override public int getSize() { Long size 0L; if (redisTemplate ! null) { SetString keys redisTemplate.keys(id :*); size keys ! null ? (long) keys.size() : 0L; } return size.intValue(); } Override public ReadWriteLock getReadWriteLock() { // 在分布式緩存中讀寫鎖通常意義不大返回一個空實現(xiàn)或簡單的鎖即可 return this.readWriteLock; } }第三步在應(yīng)用啟動時配置RedisTemplate并注入到Cache實現(xiàn)中Configuration public class MyBatisRedisCacheConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); template.setKeySerializer(new StringRedisSerializer()); template.setValueSerializer(new GenericJackson2JsonRedisSerializer()); template.afterPropertiesSet(); // 注入到我們的RedisCache類中 RedisCache.setRedisTemplate(template); return template; } }第四步在Mapper XML中指定使用自定義的Cache實現(xiàn)mapper namespacecom.example.mapper.UserMapper !-- 使用自定義的Redis緩存 -- cache typecom.example.cache.RedisCache/ !-- 后續(xù)的SQL語句 -- /mapper4.3 使用外部緩存的注意事項與優(yōu)化序列化與反序列化開銷對象需要在Java內(nèi)存和Redis存儲間序列化/反序列化這會帶來CPU開銷和延遲。要選擇高效的序列化方案如Kryo、Protobuf或Jackson的Smile格式并評估緩存對象的大小和復雜度。緩存Key的設(shè)計上面的示例簡單使用了CacheKey的toString()這可能產(chǎn)生很長且不易讀的Key。在生產(chǎn)環(huán)境中最好能設(shè)計一個更簡潔、可讀的Key生成策略便于監(jiān)控和排查。過期策略與內(nèi)存管理一定要為緩存設(shè)置合理的TTL生存時間防止冷數(shù)據(jù)常駐內(nèi)存。同時要監(jiān)控Redis的內(nèi)存使用情況避免緩存擊穿或雪崩。緩存穿透、擊穿、雪崩這是使用任何分布式緩存都要面對的經(jīng)典問題。需要在業(yè)務(wù)代碼或緩存中間件層面考慮解決方案如布隆過濾器、互斥鎖、隨機過期時間等。事務(wù)一致性MyBatis的緩存清空機制在寫操作后清空對應(yīng)namespace緩存在分布式環(huán)境下依然有效但清空的是Redis中的對應(yīng)鍵。你需要確保Redis操作和數(shù)據(jù)庫事務(wù)的最終一致性這通常比本地緩存更復雜。實操心得將MyBatis緩存擴展到Redis實際上是將緩存的管理職責從ORM框架部分轉(zhuǎn)移到了專門的緩存基礎(chǔ)設(shè)施。這帶來了更大的靈活性和更強的能力同時也引入了新的復雜度。我個人的做法是在業(yè)務(wù)層Service層顯式地使用Redis緩存而不是在MyBatis Mapper層做透明集成。這樣緩存的讀、寫、失效邏輯完全由業(yè)務(wù)代碼控制意圖更清晰更容易處理復雜的數(shù)據(jù)一致性問題也便于做更精細的監(jiān)控和治理。MyBatis自帶的二級緩存機制在這種架構(gòu)下通常會被選擇關(guān)閉。5. 緩存策略的深度思考與生產(chǎn)實踐建議經(jīng)過對三級緩存的層層剖析我們最后需要跳出具體的技術(shù)細節(jié)從更高維度思考在實際項目中我們到底該如何制定緩存策略5.1 不同層級緩存的定位與選擇我們可以把數(shù)據(jù)訪問的路徑想象成一條有多個檢查站的公路一級緩存SqlSession是第一個、也是最快速的檢查站但它只對當前這輛車當前會話本次行程有效。它的作用是消除同一事務(wù)上下文內(nèi)的絕對重復查詢。二級緩存Namespace是第二個檢查站所有走這條公路訪問這個Mapper的車都能共享信息。但它建在路邊應(yīng)用內(nèi)存其他平行的公路其他應(yīng)用實例看不到。適合緩存全局性、極少變更的只讀數(shù)據(jù)。外部緩存如Redis是一個建在云端的中央情報站所有公路上的車都能實時同步信息。它能力強大但訪問它需要一點時間網(wǎng)絡(luò)IO。適合作為業(yè)務(wù)層緩存存儲經(jīng)過加工的熱點數(shù)據(jù)支撐高并發(fā)場景。選擇建議默認策略在大多數(shù)Spring Boot項目中結(jié)合MyBatis-Plus或默認配置可以完全依賴一級緩存來處理會話內(nèi)重復查詢而顯式關(guān)閉所有XML中的二級緩存cache enabledfalse/。將緩存的重任交給業(yè)務(wù)層和Redis。何時啟用二級緩存僅當你能百分百確定某個Mapper對應(yīng)的表是“靜態(tài)表”如數(shù)據(jù)字典且?guī)缀鯖]有其他表與之關(guān)聯(lián)更新時可以謹慎開啟。并務(wù)必設(shè)置合理的flushInterval和size。何時使用外部緩存當你的應(yīng)用需要部署多個實例或者需要緩存的數(shù)據(jù)量很大、結(jié)構(gòu)復雜或者需要對緩存有更精細的控制如不同鍵不同TTL時就必須引入Redis等分布式緩存。此時MyBatis的二級緩存應(yīng)被禁用。5.2 緩存模式與失效策略的設(shè)計在業(yè)務(wù)層使用緩存特別是Redis時有幾種常見模式Cache-Aside旁路緩存這是最常用的模式。應(yīng)用代碼直接管理緩存。讀流程先讀緩存命中則返回未命中則讀數(shù)據(jù)庫并將結(jié)果寫入緩存。寫流程先更新數(shù)據(jù)庫然后刪除緩存而非更新緩存。這是為了避免在并發(fā)寫時出現(xiàn)更新順序問題導致臟緩存。// 偽代碼示例Cache-Aside模式 public User getUserById(Long id) { String key user: id; // 1. 讀緩存 User user redis.get(key); if (user ! null) { return user; } // 2. 緩存未命中讀數(shù)據(jù)庫 user userMapper.selectById(id); if (user ! null) { // 3. 寫入緩存設(shè)置過期時間 redis.setex(key, 300, user); // 過期時間5分鐘 } return user; } public void updateUser(User user) { // 1. 更新數(shù)據(jù)庫 userMapper.updateById(user); // 2. 刪除緩存 redis.delete(user: user.getId()); }Write-Through直寫任何對數(shù)據(jù)庫的寫操作都同步更新緩存。這對緩存的一致性保障最好但每次寫操作都有額外的緩存更新開銷通常需要緩存組件本身提供這種支持。Write-Behind后寫先更新緩存然后異步批量更新數(shù)據(jù)庫。性能最高但存在數(shù)據(jù)丟失風險緩存宕機。在生產(chǎn)環(huán)境中Cache-Aside 刪除失效是最為穩(wěn)健和靈活的策略。對于“刪除緩存”這一步在超高并發(fā)場景下還需要考慮“先刪緩存再更新數(shù)據(jù)庫”可能引發(fā)的并發(fā)問題如經(jīng)典的“讀寫并發(fā)導致舊緩存回填”問題有時會采用“延遲雙刪”等更復雜的策略來保證最終一致性。5.3 監(jiān)控、排查與性能調(diào)優(yōu)引入了緩存就必須配套完善的監(jiān)控體系。監(jiān)控指標緩存命中率Hit Ratio這是最重要的指標。命中率過低如低于80%說明緩存策略可能有問題或者緩存的數(shù)據(jù)不是熱點。緩存容量與內(nèi)存使用率防止Redis被撐滿。緩存操作耗時特別是網(wǎng)絡(luò)往返時間RTT。數(shù)據(jù)庫QPS觀察引入緩存后數(shù)據(jù)庫壓力的下降是否達到預期。常見問題排查思路緩存穿透大量請求查詢一個不存在的數(shù)據(jù)如不存在的用戶ID。解決方案對不存在的數(shù)據(jù)也進行短時間緩存如緩存null值設(shè)置很短TTL或者使用布隆過濾器Bloom Filter在查詢前進行攔截。緩存擊穿某個熱點Key過期瞬間大量請求同時到達數(shù)據(jù)庫。解決方案使用互斥鎖Mutex Lock只讓一個請求去加載數(shù)據(jù)其他請求等待?；蛘咴跇I(yè)務(wù)允許的情況下設(shè)置熱點數(shù)據(jù)永不過期由后臺任務(wù)異步更新。緩存雪崩大量Key在同一時間點過期導致所有請求涌向數(shù)據(jù)庫。解決方案為緩存Key的過期時間設(shè)置一個隨機波動值例如基礎(chǔ)TTL隨機分鐘數(shù)避免同時失效。MyBatis緩存調(diào)試在開發(fā)階段可以開啟MyBatis的日志級別來觀察緩存行為。將org.apache.ibatis.cache包的日志級別設(shè)為DEBUG可以看到緩存命中、未命中和清空的具體日志對于理解緩存行為非常有幫助。緩存是提升系統(tǒng)性能的利器但也是一把雙刃劍。它通過引入額外的復雜度一致性、維護成本來換取性能的提升。沒有一個放之四海而皆準的緩存方案。最關(guān)鍵的是深入理解你的業(yè)務(wù)數(shù)據(jù)訪問模式哪些是熱點數(shù)據(jù)數(shù)據(jù)的更新頻率如何一致性要求有多高只有回答了這些問題你才能設(shè)計出最適合當前場景的、優(yōu)雅的緩存方案。從MyBatis內(nèi)置的輕量級緩存到強大的分布式Redis緩存工具就在那里而如何用好它們才是對我們開發(fā)者真正的考驗。