2. 租户隔离模型：分类、对比与选择策略
在多租户 SaaS 架构中，租户隔离模型决定了不同租户的数据在存储层的物理或逻辑分离程度。选择正确的隔离模型，直接影响系统的安全性、运维成本、扩展能力和资源利用率。本章从数据库级、Schema 级、表级三种主流模型出发，逐一分析其实现原理、优缺点，并给出可落地的选择策略。
2.1 隔离模型分类
根据数据在数据库实例、数据库对象和表结构层面的隔离粒度，可将租户隔离模型分为以下三类：
- 数据库级隔离（Database per Tenant）：每个租户独占一个独立的数据库实例或逻辑数据库。数据完全物理隔离，租户间无任何数据交叉风险。
- Schema 级隔离（Schema per Tenant）：共享同一个数据库实例，但每个租户拥有独立的 Schema（命名空间）。Schema 内包含该租户专属的表、视图、存储过程等对象。
- 表级隔离（Shared Table / Discriminator Column）：所有租户共享同一组表，通过租户标识列（tenant_id）区分数据行。这是最细粒度的共享模式。
术语说明： 部分数据库（如 PostgreSQL）将 Schema 视为命名空间，而 MySQL 中“数据库”与“Schema”概念等价。本文以通用架构视角区分：数据库级指独立实例或独立库，Schema 级指同一实例下的独立命名空间。
2.2 各模型优缺点对比
下表从安全性、扩展性、运维成本、资源利用率、跨租户查询能力等关键维度，对三种模型进行系统化对比：
| 对比维度 | 数据库级隔离 | Schema 级隔离 | 表级隔离 |
|---|---|---|---|
| 数据安全性 | 最高（物理隔离） | 高（逻辑隔离） | 中（依赖应用层过滤） |
| 租户扩展上限 | 受数据库实例资源限制 | 受单实例 Schema 数量限制 | 几乎无上限（行级扩展） |
| 资源利用率 | 低（每个租户预留资源） | 中（共享实例缓存） | 高（共享所有资源） |
| 运维复杂度 | 高（备份/恢复/迁移逐个处理） | 中（Schema 级管理） | 低（统一运维） |
| 跨租户查询 | 困难（跨实例查询） | 较困难（跨 Schema 查询） | 容易（同一表内过滤） |
| 应用代码侵入 | 低（数据源路由） | 中（Schema 切换） | 高（所有 SQL 需加 tenant_id） |
| 备份与恢复粒度 | 租户级精细 | 租户级精细 | 全局粗粒度 |
| 典型适用场景 | 金融、医疗、合规敏感行业 | 中型企业、SaaS 平台初期 | 超大规模、低成本 SaaS |
关键权衡： 安全性越高，资源利用率和运维效率越低；共享程度越高，应用层隔离责任越重。没有绝对最优模型，只有最适合业务阶段的选择。
2.3 选择策略与决策流程
选择租户隔离模型时，建议按以下优先级依次评估：
- 合规与安全要求：如果目标行业存在强制数据物理隔离法规（如 GDPR、HIPAA、金融监管），优先选择数据库级隔离。
- 租户规模与增长预期：预计租户数少于 500 且单租户数据量大，可选数据库级；租户数在 500~5000 之间，Schema 级是平衡点；租户数超过 10000 且数据量小，表级隔离更经济。
- 运维团队能力：团队规模小、希望降低运维负担，优先考虑表级或 Schema 级；团队成熟且有自动化运维工具，可承受数据库级的管理成本。
- 多租户功能需求：需要频繁进行跨租户统计分析、全局报表，表级隔离最方便；需要为每个租户提供独立备份/恢复能力，数据库级或 Schema 级更合适。
- 成本预算：数据库级需要更多计算和存储资源，成本最高；表级共享资源，单位租户成本最低。
2.4 混合模型与演进策略
实际生产环境中，许多 SaaS 平台采用混合模型来应对不同租户的差异化需求：
- 分层隔离：对高安全需求的大租户使用数据库级隔离，对中小租户使用 Schema 级或表级隔离。
- 按产品模块隔离：核心业务数据使用 Schema 级隔离，日志、分析等非敏感数据使用表级隔离。
- 渐进式演进：初创期使用表级隔离快速上线，中期迁移到 Schema 级，后期对头部租户提供数据库级升级选项。
演进陷阱： 从表级隔离向 Schema 级或数据库级迁移时，数据拆分和路由改造成本极高。建议在架构设计初期预留隔离模型切换的抽象层（如多数据源路由接口），避免后期大规模重构。
2.5 小结
租户隔离模型的选择本质是安全、成本、效率的三角权衡。数据库级隔离提供最强安全保障但资源消耗最大；表级隔离实现最高资源利用率但将隔离责任完全交给应用层；Schema 级隔离是多数 SaaS 平台的折中首选。实际决策时，应结合合规要求、租户规模、运维能力和业务演进路径，选择当前阶段最匹配的模型，并为未来升级保留扩展空间。