?? 一、為什么 MyBatis 原生二級(jí)緩存“難以修復(fù)”？

MyBatis 二級(jí)緩存的底層設(shè)計(jì)存在結(jié)構(gòu)性缺陷，不是加個(gè)插件就能完美解決的：

?? 這些是架構(gòu)級(jí)缺陷，靠攔截器或裝飾器插件無(wú)法根本解決。

?? 二、社區(qū)增強(qiáng)插件方案（可選，但需謹(jǐn)慎）

雖然不能“修復(fù)”，但有插件替換緩存實(shí)現(xiàn)，提升可用性：

1.mybatis-redis（最常用）

• GitHub: https://github.com/mybatis/redis-cache
• 原理：用 Redis 作為二級(jí)緩存的存儲(chǔ)后端，解決多節(jié)點(diǎn)一致性問(wèn)題
• 使用方式：

@Mapper
@CacheNamespace(implementation = RedisCache.class)
public interface OrderMapper {
    // ...
}

• ? 優(yōu)點(diǎn)：跨實(shí)例一致、可設(shè) TTL（需自定義）
• ? 缺點(diǎn)：
  • 仍無(wú)法解決 Key 語(yǔ)義問(wèn)題（分頁(yè)/動(dòng)態(tài) SQL 緩存 key 仍可能沖突）
  • 每次查詢都多一次 Redis 網(wǎng)絡(luò) IO，在 10w QPS 下可能成為瓶頸
  • 序列化成本高（Java 對(duì)象需序列化為 byte[]）

?? 適用場(chǎng)景：讀多寫少、數(shù)據(jù)變更不頻繁、對(duì)延遲不敏感的配置類數(shù)據(jù)（如字典表）

2.自定義 Cache 實(shí)現(xiàn)（繼承 MyBatisCache接口）

你可以自己實(shí)現(xiàn)帶版本號(hào)或邏輯過(guò)期的緩存：

public class VersionedCache implements Cache {
    private final String id;
    private final RedisTemplate redis;
    @Override
    public void putObject(Object key, Object value) {
        // key = "order:123", value = { data: {...}, version: 20251203 }
        redis.opsForHash().put("mybatis:cache:" + id, serialize(key), wrapWithVersion(value));
    }
    @Override
    public Object getObject(Object key) {
        Object cached = redis.opsForHash().get("mybatis:cache:" + id, serialize(key));
        if (cached != null && isVersionValid(cached)) {
            return unwrap(cached);
        }
        return null;
    }
}

• ? 優(yōu)點(diǎn)：可控制緩存結(jié)構(gòu)、加版本、加 TTL
• ? 缺點(diǎn)：開發(fā)維護(hù)成本高，且仍受限于 MyBatis 緩存 key 生成邏輯

?? 三、我們的選擇：棄用二級(jí)緩存，自建業(yè)務(wù)緩存層

在高并發(fā)訂單系統(tǒng)中，我們最終徹底關(guān)閉 MyBatis 二級(jí)緩存，原因如下：

1. 控制權(quán)不足：MyBatis 緩存是“黑盒”，無(wú)法插入降級(jí)、熔斷、監(jiān)控邏輯
2. 異常難追溯：緩存臟數(shù)據(jù)問(wèn)題往往延遲暴露，修復(fù)成本高
3. 違背“可觀測(cè)性”原則：緩存命中/失效無(wú)法對(duì)接 Prometheus / SkyWalking

? 替代方案：業(yè)務(wù)層 + Redis + 冪等 + 版本號(hào)

@Service
public class OrderService {
    public Order getOrder(Long id) {
        String cacheKey = "order:v2:" + id;
        Order order = redis.get(cacheKey, Order.class);
        if (order != null) return order;
        // 雙檢鎖 + 空值緩存防穿透
        synchronized (getLockKey(id)) {
            order = redis.get(cacheKey, Order.class);
            if (order == null) {
                order = orderMapper.findById(id);
                if (order != null) {
                    redis.setex(cacheKey, 300, order); // 5分鐘過(guò)期
                } else {
                    redis.setex("empty:" + cacheKey, 60, "1"); // 防緩存穿透
                }
            }
        }
        return order;
    }
    @Transactional
    public void updateOrder(Order order) {
        orderMapper.update(order);
        // 主動(dòng)失效緩存（旁路刪除）
        redis.delete("order:v2:" + order.getId());
    }
}

? 優(yōu)勢(shì)：

• 緩存 key 語(yǔ)義清晰（含版本 v2，便于灰度/回滾）
• 支持 TTL、空值緩存、主動(dòng)失效
• 可集成 緩存命中率監(jiān)控、慢查詢告警
• 與 Flink/Canal 數(shù)據(jù)對(duì)齊 機(jī)制無(wú)縫銜接

?? 總結(jié)：二級(jí)緩存不是“能不能修”，而是“值不值得用”

最終口訣更新：

“二級(jí)緩存看似香，架構(gòu)缺陷難躲藏；
分頁(yè)排序易沖突，多機(jī)部署更遭殃；
插件替換治標(biāo)難，自建緩存才穩(wěn)當(dāng)；
Key 帶版本加 TTL，高并發(fā)下不慌張！”

如果你正在設(shè)計(jì)高并發(fā)系統(tǒng)，放棄對(duì) MyBatis 二級(jí)緩存的幻想，把緩存控制權(quán)拿回業(yè)務(wù)層，才是真正的“韌性設(shè)計(jì)”。

到此這篇關(guān)于MyBatis 原生二級(jí)緩存“難以修復(fù)”的原因解析及解決方案的文章就介紹到這了,更多相關(guān)mybatis二級(jí)緩存修復(fù)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！