多租户SaaS系统的架构设计中,数据隔离始终是一个核心挑战。它不仅影响系统安全性、可扩展性,还直接关系到成本控制。本文基于真实项目——Taoify跨境电商独立站的实践经验,系统梳理多租户数据隔离的主流方案与落地实施细节。
一、多租户数据隔离方案选型
设想一下,数千个店铺(租户)共享同一套应用代码,但数据必须严格隔离——这是所有SaaS平台面临的基本矛盾。常见的解决方案主要有以下三种。
方案一:独立数据库。每个租户独占一个数据库,隔离性最强、安全性最高,但成本也最高——每个租户需配置独立的连接池和备份策略。该方案适用于有定制化需求、预算充足的大客户。
方案二:独立Schema。在同一个MySQL实例中,每个租户拥有独立的Schema(数据库)。成本和安全性介于前两者之间,是中等规模租户的常见选择。
方案三:共享表。所有租户数据存放在同一张表中,通过tenant_id字段区分。成本最低,但风险也最大——查询时若遗漏tenant_id条件,数据将发生混淆。适用于免费版或流量较小的轻量租户。
在Taoify项目中,我们采用了混合策略:免费版租户使用共享表以降低入门门槛;付费版租户分配独立Schema,平衡性能与隔离性;企业级大客户则直接采用独立数据库,实现最高级别的数据保护。
二、租户上下文传递实现(共享表方案)
首先来看共享表的场景。要实现自动化的租户数据隔离,关键是让系统各处都能感知到“当前请求属于哪个租户”。具体实现可以分为三个步骤。
第一步:定义租户上下文持有者。通过ThreadLocal实现线程级别的数据隔离。
public class TenantContext {
private static final ThreadLocal currentTenant = new ThreadLocal<>();
public static void setTenantId(String tenantId) { currentTenant.set(tenantId); }
public static String getTenantId() { return currentTenant.get(); }
public static void clear() { currentTenant.remove(); }
}
第二步:编写拦截器,从请求头中提取租户ID。在Spring Boot框架中,借助HandlerInterceptor完成提取操作。
@Component
public class TenantInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
String tenantId = request.getHeader("X-Tenant-Id");
if (StringUtils.isBlank(tenantId)) {
tenantId = "default";
}
TenantContext.setTenantId(tenantId);
return true;
}
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
TenantContext.clear();
}
}
第三步:MyBatis拦截器自动注入tenant_id查询条件。这是最关键的一步,确保所有SQL查询都自动携带租户隔离条件。
@Intercepts({@Signature(type = StatementHandler.class, method = "prepare", args = {Connection.class, Integer.class})})
public class TenantSqlInterceptor implements Interceptor {
@Override
public Object intercept(Invocation invocation) throws Throwable {
StatementHandler statementHandler = (StatementHandler) invocation.getTarget();
BoundSql boundSql = statementHandler.getBoundSql();
String sql = boundSql.getSql();
String tenantId = TenantContext.getTenantId();
if (StringUtils.isNotBlank(tenantId) && !sql.contains("tenant_id")) {
// 智能识别表名并注入条件
String newSql = injectTenantCondition(sql, tenantId);
// 通过反射修改BoundSql
Field field = boundSql.getClass().getDeclaredField("sql");
field.setAccessible(true);
field.set(boundSql, newSql);
}
return invocation.proceed();
}
}
通过以上三个组件,在共享表模式下即可实现自动、无感的租户数据隔离。
三、动态数据源切换(独立Schema方案)
对于使用独立Schema的付费租户,面临的挑战有所不同。需要在运行时动态切换至不同的Schema,关键组件是AbstractRoutingDataSource。
public class DynamicDataSource extends AbstractRoutingDataSource {
@Override
protected Object determineCurrentLookupKey() {
String tenantId = TenantContext.getTenantId();
// 根据租户ID映射到对应的Schema数据源
return DataSourceRegistry.getDataSourceKey(tenantId);
}
}
在配置文件中预先定义多个数据源,由DynamicDataSource在运行时按需切换。该方案思路清晰、零侵入,每个租户的Schema如同独立小院,互不干扰。
四、部署在阿里云的最佳实践
回到部署层面。Taoify的后端主数据库采用阿里云RDS MySQL。在多租户实践中,以下几个操作非常实用:
首先,开启RDS的SQL洞察功能,可监控每个租户的SQL执行情况,对于排查性能瓶颈和定位数据异常非常有效。其次,针对大租户,可考虑使用RDS的只读实例分离读写压力,避免单点瓶颈。最后,如需跨多个Schema或数据库进行查询,阿里云DMS(数据管理服务)提供便捷的跨库查询功能,一条SQL即可完成。

