为什么 MyBatis 原生二级缓存“难以修复”？

原创已于 2025-12-04 10:42:00 修改 · 427 阅读

10 ·

CC 4.0 BY-SA版权

文章标签：

#mybatis #java #java-ee

于 2025-12-03 20:07:55 首次发布

java-ee 专栏收录该内容

18 篇文章

订阅专栏

🚫 一、为什么 MyBatis 原生二级缓存“难以修复”？

MyBatis 二级缓存的底层设计存在结构性缺陷，不是加个插件就能完美解决的：

问题	原因	高并发影响
缓存 Key 粒度粗糙	Key = `namespace + sql + params`，但 params 是对象哈希，分页/排序等参数容易哈希冲突或忽略语义差异	返回错误数据（如分页错乱）
无 TTL / 过期机制	默认使用 `PerpetualCache`，数据永不过期	内存泄漏 + 脏读
跨 JVM 无法共享	缓存是本地内存（JVM 内），多实例部署时各节点缓存不一致	数据分裂，用户看到不同结果
写操作不自动失效关联缓存	更新 `User` 表，不会自动清理 `OrderMapper` 中关联的 `user_orders` 缓存	脏读持续存在

⚠️ 这些是架构级缺陷，靠拦截器或装饰器插件无法根本解决。

🔧 二、社区增强插件方案（可选，但需谨慎）

虽然不能“修复”，但有插件替换缓存实现，提升可用性：

1. mybatis-redis（最常用）

GitHub: https://github.com/mybatis/redis-cache
原理：用 Redis 作为二级缓存的存储后端，解决多节点一致性问题
使用方式：

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

✅ 优点：跨实例一致、可设 TTL（需自定义）
❌ 缺点：
- 仍无法解决 Key 语义问题（分页/动态 SQL 缓存 key 仍可能冲突）
- 每次查询都多一次 Redis 网络 IO，在 10w QPS 下可能成为瓶颈
- 序列化成本高（Java 对象需序列化为 byte[]）

💡 适用场景：读多写少、数据变更不频繁、对延迟不敏感的配置类数据（如字典表）

2. 自定义 Cache 实现（继承 MyBatis `Cache` 接口）

你可以自己实现带版本号或逻辑过期的缓存：

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;
    }
}

✅ 优点：可控制缓存结构、加版本、加 TTL
❌ 缺点：开发维护成本高，且仍受限于 MyBatis 缓存 key 生成逻辑

🛑 三、我们的选择：弃用二级缓存，自建业务缓存层

在高并发订单系统中，我们最终彻底关闭 MyBatis 二级缓存，原因如下：

控制权不足：MyBatis 缓存是“黑盒”，无法插入降级、熔断、监控逻辑
异常难追溯：缓存脏数据问题往往延迟暴露，修复成本高
违背“可观测性”原则：缓存命中/失效无法对接 Prometheus / SkyWalking

✅ 替代方案：业务层 + Redis + 幂等 + 版本号

@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分钟过期
                } else {
                    redis.setex("empty:" + cacheKey, 60, "1"); // 防缓存穿透
                }
            }
        }
        return order;
    }

    @Transactional
    public void updateOrder(Order order) {
        orderMapper.update(order);
        // 主动失效缓存（旁路删除）
        redis.delete("order:v2:" + order.getId());
    }
}

✅ 优势：

缓存 key 语义清晰（含版本 v2，便于灰度/回滚）
支持 TTL、空值缓存、主动失效
可集成 缓存命中率监控、慢查询告警
与 Flink/Canal 数据对齐 机制无缝衔接

🧠 总结：二级缓存不是“能不能修”，而是“值不值得用”

方案	适合场景	高并发推荐度
MyBatis 原生二级缓存	单机、低频、只读数据	❌ 不推荐
mybatis-redis 插件	多实例、读多写少、容忍一定延迟	⚠️ 谨慎评估
自定义 Cache 实现	有强缓存治理能力的团队	⚠️ 成本高
业务层自建缓存	高并发、强一致性、可观测性要求高	✅ 强烈推荐