今天聊一个老生常谈但每次都绕不开的问题——

多租户系统，如何做数据隔离 + 资源配额控制？

为什么要关注？
因为如果搞不定这两点：

• 租户数据互相串了，分分钟“社死”；

• 资源配额没人管，几个大客户就能把整个系统拖垮。

这篇文章我会用实战思路，带你拆解：

• 三种数据隔离方案对比（数据库级别 / 表级别 / 行级别）

• 动态数据源、表名拦截、租户 ID 注入的实现细节

• 资源配额模型、拦截器限流、Redis 原子控制

• 最佳适用场景选择

直接干货，程序员必看。

-01-

一个系统，服务多个客户（租户），但大家的数据和资源都要“各过各的”。

• 数据隔离：保证 A 公司看不到 B 公司的数据。

• 资源配额：保证小客户不被“挤死”，大客户不拖垮系统。

-02-

实现要点：

• 数据库级别：动态数据源切换，租户上下文保存 tenantId。

• 表级别：MyBatis 插件拦截 SQL，动态拼接表名前缀。

• 行级别：拦截器自动注入 tenantId，查询自动加条件。

总结：安全敏感选 数据库级，折中就用 表级，追求规模扩展就 行级。

-03-

数据隔离只是“防串”，配额控制才是“防拖垮”。

配额模型

• 存储空间

• API 调用次数

• 并发用户数

• …（可扩展）

控制手段

• 拦截器：请求进来先判断 quota 用完没，用完就限流。

• Redis 分布式计数器：Lua 脚本保证并发下的原子操作。

• 配额模型表：存 tenantId -> quota/used，方便统计和告警。

最佳实践

• 分层控制：应用层 + 基础设施层双保险。

• 预警升级：快用完时提示客户升级套餐。

• 监控告警：避免异常租户疯狂消耗资源。

权限与认证

• JWT / Token：解析后提取 tenantId，放入上下文。

• Spring Security：基于 tenantId 做权限校验。

这样才能保证“只能看自己家的数据”。