MyBatisPlus租户插件实现多用户AI服务隔离-编程阁

MyBatisPlus租户插件实现多用户AI服务隔离

在如今的AI应用浪潮中，越来越多原本面向个人用户的工具开始向企业级SaaS平台演进。以语音合成系统IndexTTS2为例，早期版本仅支持单机本地运行，所有数据归一人所有。但随着团队协作、商业授权等需求兴起，如何让多个用户安全共用同一套服务实例，同时确保彼此的数据互不干扰，成为亟待解决的问题。

直接为每个用户部署独立环境？成本太高；微服务拆分？架构复杂度陡增。有没有一种轻量、高效又兼容性强的方案？答案是：利用MyBatisPlus的租户插件，在数据库层面实现透明化的多租户数据隔离。

这不仅避免了大规模重构，还能快速支撑起企业级多用户场景下的权限控制与审计能力。更重要的是——它几乎不需要你在每个DAO方法里重复写WHERE tenant_id = ?。

我们先来看一个典型的痛点场景：假设某用户A通过Web界面访问自己的语音任务历史列表，请求到了后端接口/api/tasks。如果此时没有有效的隔离机制，攻击者只需修改参数中的ID或绕过前端限制，就可能查到用户B的任务记录，甚至删除不属于自己的音频文件。

传统做法是在每个业务方法中手动校验当前登录用户是否拥有该资源的操作权限，但这依赖开发者的自觉性，容易遗漏，且代码冗余严重。而更理想的解决方案，是从底层SQL执行层面对数据访问进行统一拦截和过滤。

这正是MyBatisPlusTenantLineInnerInterceptor的用武之地。

这个插件属于MyBatisPlus拦截器体系的一部分，工作在SQL解析阶段。它的核心逻辑很简单：当执行任何查询、更新或删除操作时，自动检测当前表是否需要启用租户隔离，若需，则在原有SQL的WHERE条件中追加一句类似tenant_id = 1001的过滤语句。整个过程对开发者透明，无需改动Mapper XML或Service层代码。

举个例子：

<select id="listAllTasks" resultType="Task"> SELECT * FROM task_record ORDER BY create_time DESC </select>

看起来没有任何租户相关的条件，但在实际运行时，插件会将其重写为：

SELECT * FROM task_record WHERE tenant_id = 1001 ORDER BY create_time DESC;

你没看错，连一行额外的代码都不用写，就能保证每个用户只能看到自己的数据。

当然，也不是所有表都需要这种隔离。比如字典表、公共模型配置表，往往是全系统共享的。这时候可以通过配置忽略列表来排除这些表的影响：

@Override public boolean ignoreTable(String tableName) { return Arrays.asList("sys_dict", "public_model", "user_info").contains(tableName); }

这样一来，查询字典项时就不会被错误地加上租户条件，导致数据查不出来。

那租户ID从哪来？这就涉及到上下文传递的设计。通常我们会借助JWT Token或Session在登录后提取用户身份，并将其映射为一个唯一的租户标识（可以是用户ID，也可以是组织ID）。然后通过一个基于ThreadLocal的上下文工具类将这个值绑定到当前线程：

public class TenantContextHolder { private static final ThreadLocal<String> CONTEXT = new ThreadLocal<>(); public static void setTenantId(String tenantId) { CONTEXT.set(tenantId); } public static String getTenantId() { return CONTEXT.get(); } public static void clear() { CONTEXT.remove(); } }

一般在Filter或Spring MVC的Interceptor中完成设置。例如，在请求进入Controller前，解析Token并调用TenantContextHolder.setTenantId(userId)，之后的所有数据库操作都会自动携带该租户上下文。

值得注意的是，插入操作不会被插件自动填充tenant_id字段。也就是说，当你保存一条新任务记录时，必须显式设置tenant_id值，否则这条数据虽然存进去了，但由于缺少正确的租户标识，后续查询将无法命中——相当于“看不见”的幽灵数据。

所以建议在基类实体或通用Service中封装默认赋值逻辑，或者使用MyBatisPlus的自动填充功能（@TableField(fill = FieldFill.INSERT)）配合MetaObjectHandler统一处理。

再来看看在IndexTTS2这类AI语音服务平台中的具体落地。

系统采用前后端分离架构，前端通过浏览器提交语音合成任务，后端Spring Boot应用接收请求，将任务信息存入MySQL数据库，并调度本地PyTorch/ONNX推理引擎生成音频。所有用户的任务记录、情感参数、输出路径等均存储于带tenant_id字段的业务表中。

一旦开启租户插件，哪怕是最简单的taskMapper.selectList(queryWrapper)调用，也会自动附加租户过滤条件。无论是查询历史、删除任务还是导出报表，都天然具备了数据边界意识。

这种设计带来的好处远不止安全性提升：

开发效率显著提高：过去每个DAO方法都要加参数、写条件，现在90%以上的查询完全不用改；
运维管理更集中：一套数据库结构即可支撑多租户，版本升级、备份恢复更加便捷；
审计与计费更容易：按tenant_id分组统计调用次数、资源消耗，轻松实现用量追踪和商业化计费；
平滑演进路径：无需推倒重来，即可将单机版产品升级为企业级SaaS服务。

当然，也有一些细节需要注意：

首先是字段命名一致性。建议所有业务表统一使用tenant_id BIGINT NOT NULL DEFAULT 0这样的定义，便于插件识别，也利于后期维护。不要有的叫org_id，有的叫user_tenant，那样容易出错。

其次是性能优化。既然每条查询都带tenant_id，那就一定要给它建索引。最好是联合索引，比如(tenant_id, create_time)，这样既能快速定位租户数据，又能支持按时间排序的常见查询模式，避免全表扫描拖慢响应速度。

还有就是旧数据迁移问题。如果系统已有存量数据，需要根据用户归属关系补全tenant_id字段。可以编写脚本按创建人映射分配，或者结合日志分析反推归属关系。

最后别忘了兜底机制。在获取租户ID的方法中加入空值判断：

@Override public Expression getTenantId() { String tenantId = TenantContextHolder.getTenantId(); if (tenantId == null) { throw new RuntimeException("未获取到租户ID，请检查登录状态"); } return new LongValue(Long.parseLong(tenantId)); }

否则一旦上下文未正确初始化，可能导致SQL中tenant_id = NULL或干脆没加条件，造成全量数据泄露，后果非常严重。

另外，推荐将租户上下文与认证框架深度集成。比如结合Spring Security的SecurityContext，或国产生态中的Sa-Token、JeeSite等权限系统，确保租户信息来源于可信的身份验证流程，而不是前端随意传入的参数。

说到这里，你可能会问：这种方式真的足够安全吗？

答案是：它是“双重防护”中不可或缺的一环。即使某个接口因疏忽未做权限校验，SQL层面依然会被租户条件拦截，大大降低了越权访问的风险。但它不能替代应用层的权限控制，两者应相辅相成。

未来还可以在此基础上进一步扩展：