MyBatis-Plus缓存一致性解决方案：CacheEvictInterceptor设计思路

背景与痛点分析

在现代企业级应用开发中，缓存作为提升系统性能的关键组件被广泛使用。然而，缓存与数据库之间的一致性问题一直是开发者面临的重大挑战。特别是在使用MyBatis-Plus这类ORM框架时，开发者经常遇到以下典型问题：

1. 历史遗留代码难以改造：在存量系统中，数据变更入口分散在各个Service层，全面覆盖缓存清理点需要极高的改造成本
2. 复杂SQL难以维护：面对嵌套查询、JOIN操作等复杂SQL场景，人工维护表影响关系容易出错且难以持续
3. 声明式注解的局限性：现有的@CacheEvict等注解方案需要显式声明受影响表，在面对动态SQL时显得力不从心

解决方案设计

针对上述问题，我们提出基于MyBatis-Plus拦截器机制的CacheEvictInterceptor解决方案。该方案的核心思想是通过SQL解析自动识别数据变更操作影响的数据库表，进而触发相应的缓存清理逻辑。

核心架构

[MyBatis执行引擎]
       |
       v
[CacheEvictInterceptor]  --(解析SQL)--> [SQL解析器]
       |
       v
[缓存清理策略] --(通知)--> [Redis/本地缓存]

关键技术实现

1. SQL语法树解析：

   • 支持完整的DML操作解析(INSERT/UPDATE/DELETE)
   • 构建语法树识别表引用关系
   • 处理带schema的表名(如dbo.user)

2. 复杂查询支持：

   • 嵌套子查询的递归解析
   • JOIN操作的表关联识别
   • UNION/UNION ALL集合操作处理
   • WHERE条件中的子查询提取

3. 缓存清理策略：

   • 基于表名的维度触发清理
   • 支持MappedStatement ID过滤
   • 可扩展的清理逻辑接口

生产实践案例

在某大型企业生产环境中，该方案被应用于管理8-10张业务表的下拉框常用数据缓存。相比传统方案，实现了：

1. 零侵入性：无需修改现有业务代码
2. 全面覆盖：自动捕获所有数据变更点
3. 维护简便：表关系由系统自动维护，无需人工干预

实现建议

对于希望自行实现的开发者，可参考以下伪代码：

public class CacheEvictInterceptor implements Interceptor {
    
    @Override
    public Object intercept(Invocation invocation) {
        // 获取执行的SQL
        String sql = getExecutedSql(invocation);
        
        // 解析受影响表
        Set<String> affectedTables = SqlParser.parseTables(sql);
        
        // 执行缓存清理
        affectedTables.forEach(table -> {
            CacheTemplate.evictByTable(table);
        });
        
        return invocation.proceed();
    }
    
    // SQL解析器实现
    static class SqlParser {
        public static Set<String> parseTables(String sql) {
            // 实现SQL语法解析逻辑
            // 返回所有受影响的表名
        }
    }
}

总结与展望

CacheEvictInterceptor方案为MyBatis-Plus项目提供了一种优雅的缓存一致性解决方案。它不仅解决了历史项目的改造难题，还通过自动化表关系维护大幅降低了开发者的心智负担。未来，该方案可进一步扩展支持：

1. 多级缓存联动：整合本地缓存与分布式缓存
2. 细粒度控制：支持字段级别的缓存清理
3. 性能优化：实现增量式的缓存更新机制

对于面临缓存一致性挑战的MyBatis-Plus用户，这一方案无疑提供了值得参考的设计思路和实践路径。