3. 租户隔离设计模式：SaaS 租户隔离的三种模式
在 SaaS 多租户架构中，租户隔离是保障数据安全与性能隔离的核心设计决策。根据数据存储与访问的粒度，业界主流采用三种隔离模式：数据库隔离、Schema 隔离 与 共享表 + 行级隔离。每种模式在安全性、运维成本、资源利用率和扩展性上存在显著差异。
3.1 三种隔离模式概述
下表从核心定义、隔离粒度、典型场景三个维度对三种模式进行对比：
| 模式 | 隔离粒度 | 核心定义 | 典型场景 |
|---|---|---|---|
| 数据库隔离 | 物理/逻辑数据库 | 每个租户拥有独立的数据库实例或逻辑库，数据完全物理隔离 | 金融、医疗等强合规行业；大型企业级租户 |
| Schema 隔离 | 数据库内的 Schema | 所有租户共享同一个数据库实例，但每个租户拥有独立的 Schema（命名空间） | 中型 SaaS 平台；需要一定隔离性但希望控制硬件成本 |
| 共享表 + 行级隔离 | 数据行 | 所有租户共享同一组表，通过租户 ID（tenant_id）字段区分数据归属 | 轻量级 SaaS；对成本极度敏感、租户数量巨大的场景 |
架构决策提示： 三种模式并非互斥。在实际生产环境中，常采用混合策略：对高安全需求的租户使用数据库隔离，对普通租户使用 Schema 或共享表模式，以实现安全与成本的平衡。
3.2 模式一：数据库隔离
每个租户拥有独立的数据库实例或逻辑库。应用层通过数据源路由（如 AbstractRoutingDataSource）将请求分发到对应租户的数据库。
- 优势： 数据隔离性最强，一个租户的故障或性能问题不会影响其他租户；备份与恢复独立；支持为不同租户定制数据库参数。
- 劣势： 硬件与运维成本最高；连接数随租户数量线性增长；跨租户查询（如全局统计）需要聚合多个数据源。
- 适用场景： 银行、保险、医疗等强监管行业；租户数量少（通常 < 100）但每个租户数据量大。
3.3 模式二：Schema 隔离
所有租户共享同一个数据库实例，但每个租户拥有独立的 Schema（如 PostgreSQL 的 Schema、MySQL 的 Database）。应用层在连接时指定目标 Schema。
- 优势： 相比数据库隔离，硬件成本更低；仍具备较好的逻辑隔离性；支持为不同租户独立升级表结构。
- 劣势： 数据库实例成为单点瓶颈；连接数依然较高；跨 Schema 查询性能较差。
- 适用场景： 中型 SaaS 平台（租户数 100~1000）；需要一定隔离性但预算有限。
3.4 模式三：共享表 + 行级隔离
所有租户共享同一组物理表，通过 tenant_id 列区分数据行。应用层在每次 SQL 查询中自动注入 WHERE tenant_id = ? 条件。
- 优势： 硬件与运维成本最低；数据库连接数固定；跨租户查询（如全局报表）最方便；租户数量可扩展至数万甚至更多。
- 劣势： 隔离性最弱，
tenant_id过滤遗漏将导致数据泄露；单表数据量过大时性能下降；所有租户共享同一表结构，无法独立定制。 - 适用场景： 轻量级 SaaS（如协作工具、小型 CRM）；租户数量巨大且数据量较小的场景。
3.5 三种模式综合对比
以下表格从 7 个关键维度对三种模式进行量化对比：
| 对比维度 | 数据库隔离 | Schema 隔离 | 共享表 + 行级隔离 |
|---|---|---|---|
| 数据安全性 | 最高（物理隔离） | 高（逻辑隔离） | 低（依赖代码正确性） |
| 硬件成本 | 高 | 中 | 低 |
| 运维复杂度 | 高（多实例管理） | 中（Schema 管理） | 低（单实例管理） |
| 扩展性（租户数） | 差（< 100） | 中（100~1000） | 好（> 10000） |
| 跨租户查询 | 困难（需聚合） | 较困难 | 容易（单表查询） |
| 表结构定制 | 支持 | 支持 | 不支持 |
| 滚动升级影响 | 低（可逐个升级） | 中（需处理 Schema 兼容） | 高（需确保行级过滤不中断） |
故障排查关联： 在滚动升级场景中，共享表 + 行级隔离模式最容易出现 租户数据交叉泄露 或 行级过滤失效 的问题。升级过程中若
tenant_id 过滤逻辑被错误修改或遗漏，将导致租户 A 看到租户 B 的数据。这是本课程后续章节重点排查的故障类型之一。
3.6 三种隔离模式的架构对比图
下图从数据存储视角展示三种隔离模式的架构差异：
3.7 滚动升级场景下的隔离模式影响
在《基于资源模型的租户隔离蓝图》滚动升级过程中，不同隔离模式对升级策略的影响差异显著：
- 数据库隔离： 可逐个升级租户数据库，升级风险最低。但需要维护多个数据库的版本一致性，升级编排复杂。
- Schema 隔离： 升级时需确保 Schema 变更的向前兼容，避免旧版本应用访问新 Schema 结构出错。
- 共享表 + 行级隔离： 升级风险最高。表结构变更会影响所有租户，且行级过滤逻辑的微小错误可能导致大规模数据泄露。升级期间需配合 蓝绿部署 或 灰度发布 策略。