Java多租户框架中如何隔离数据库？

Question

在Java多租户系统中，如何通过共享数据库但隔离Schema的方式实现数据安全与资源高效利用？常见问题包括：多租户间数据误查或越权访问、连接池动态切换Schema失败、ORM框架（如Hibernate）对多Schema支持不灵活、DDL变更难以批量同步到各租户Schema。如何在Spring Boot + MyBatis或JPA环境中，结合拦截器与数据源路由机制，实现透明化的租户级数据库隔离？

Answer 1

一、多租户系统中共享数据库与Schema隔离的架构背景

在SaaS（Software as a Service）系统中，多租户架构是实现资源高效利用的核心模式之一。其中，“共享数据库 + 隔离Schema”是一种平衡成本与安全性的主流方案：所有租户共用一个物理数据库实例，但每个租户拥有独立的Schema（或称命名空间），从而实现逻辑隔离。

该模式的优势包括：

• 降低数据库连接数和硬件开销
• 便于集中管理与监控
• 支持灵活扩展新租户
• 相比独立数据库更节省运维成本

然而，在Java生态中，尤其是在Spring Boot集成MyBatis或JPA/Hibernate时，面临诸多挑战。

二、常见技术问题深度剖析

问题类型	具体表现	潜在风险
数据误查/越权访问	未正确绑定当前租户Schema，导致跨租户查询	严重数据泄露，违反GDPR等合规要求
连接池动态切换失败	使用HikariCP等连接池后，连接预创建导致Schema无法运行时变更	请求路由错乱，出现“张三看到李四数据”
ORM框架支持不灵活	Hibernate默认Schema固定，MyBatis需手动拼接表名	代码侵入性强，维护困难
DDL变更难以同步	新增字段需逐个Schema执行ALTER语句	发布效率低，易遗漏租户
事务跨Schema污染	分布式事务中误操作多个Schema	数据一致性破坏

三、核心解决方案设计：基于拦截器与数据源路由机制

为实现透明化租户级数据库隔离，需构建一套完整的上下文感知体系。整体流程如下所示：

// 示例：定义租户上下文持有者
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();
    }
}

graph TD A[HTTP请求] --> B{解析租户标识} B -->|Header/X-tenant-id| C[设置TenantContext] C --> D[DataSource路由拦截] D --> E[动态选择Schema] E --> F[执行SQL] F --> G[结果返回] H[MyBatis Interceptor] --> D I[JPA Hibernate MultiTenantConnectionProvider] --> D

四、Spring Boot + MyBatis 实现路径

通过自定义MyBatis拦截器，在SQL执行前动态重写表名为schema.table格式：

@Intercepts({
    @Signature(type = Executor.class, method = "query", 
               args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}),
    @Signature(type = Executor.class, method = "update", 
               args = {MappedStatement.class, Object.class})
})
public class TenantSchemaInterceptor implements Interceptor {

    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        String tenantId = TenantContextHolder.getTenantId();
        if (tenantId != null) {
            // 动态修改SQL中的表名为 schema_name.table_name
            Configuration config = ((MappedStatement)invocation.getArgs()[0]).getConfiguration();
            // 使用SQL Parser进行AST改写（可借助JSqlParser）
        }
        return invocation.proceed();
    }
}

同时配置动态数据源：

public class DynamicDataSource extends AbstractRoutingDataSource {
    @Override
    protected Object determineCurrentLookupKey() {
        return TenantContextHolder.getTenantId();
    }
}

五、Spring Boot + JPA/Hibernate 实现策略

Hibernate提供原生多租户支持，通过以下接口实现：

• MultiTenantConnectionProvider：按租户获取对应连接
• CurrentTenantIdentifierResolver：解析当前请求租户ID

@Component
public class SchemaPerTenantConnectionProvider implements MultiTenantConnectionProvider {

    @Autowired
    private DataSource dataSource;

    @Override
    public Connection getConnection(String tenantIdentifier) throws SQLException {
        Connection conn = dataSource.getConnection();
        conn.createStatement().execute("SET SCHEMA '" + tenantIdentifier + "'");
        return conn;
    }

    // 其他方法略...
}

实体类无需修改，只需在persistence.xml或Spring配置中启用：

hibernate.multiTenancy=SCHEMA

六、DDL变更批量同步方案

为解决Schema间DDL同步难题，建议采用自动化脚本+元数据驱动方式：

工具	用途	适用场景
Flyway + placeholder	支持${schema}占位符替换	每次迁移遍历所有租户执行
Liquibase + contexts	按租户分组执行变更集	复杂条件控制
自研Admin Service	调用JDBC批量执行DDL	高定制化需求
Kubernetes Job	定时批量升级Schema	云原生环境

-- Flyway示例 migration/V2__add_email_column.sql
ALTER TABLE ${schema}.users ADD COLUMN email VARCHAR(255);

七、安全性增强与最佳实践

为防止越权访问，应在网关层、服务层、DAO层实施三重防护：

1. API网关验证JWT中的tenant_id，并注入到Header
2. Controller层校验业务参数是否属于当前租户
3. DAO层通过拦截器确保所有SQL都带上Schema前缀
4. 定期审计日志，记录每个SQL执行的租户上下文
5. 数据库层面限制用户权限，禁止跨Schema查询
6. 使用Row-Level Security（如PostgreSQL RLS）作为兜底机制
7. 对敏感操作启用二次确认与审批流
8. 建立租户Schema元数据注册中心
9. 开发阶段使用Mock Schema进行隔离测试
10. 上线前进行渗透测试模拟跨租户攻击