背景

简介

Saas下多租户模式相对于单租户模式的典型区别在于单租户模式一般通过硬件来进行物理上的隔离，每个租户购买自己的数据库实例；而多租户模式下各租户同在一个实例下共享计算/存储资源，需要考虑数据安全层面的隔离和性能层面的隔离。 MySQL本身对多租户并无特别的原生支持。在MySQL下实现多租户的手段一般可以分为三种方式：

• 独立数据库：一个租户一个数据库 ，物理意义上的数据隔离，类似单租户模式
• 共享数据库+独立Schema：所有租户共享Database，但是每个租户一个Schema，逻辑上进行了数据隔离
• 共享数据库+共享Schema+共享数据表：通过在表中增加TenantID多租户的数据字段来区分不同租户 三种方式数据独立性逐渐降低，共享度上升，但均无法实现性能资源上的隔离。

PolarDB MySQL 单实例多租户模式可以使得多个租户在同一实例下共享计算/存储资源，同时保证各租户下的数据隔离，保证租户仅能访问到自己的数据，以及各租户下的资源隔离，确保租户间不会出现资源争抢，保障业务稳定运行。

PolarDB MySQL 单实例多租户模式方案解决了以下一些客户业务痛点：

1. Saas多租户业务场景需要为每个租户创建不同库/表，业务代码需要针对每个租户进行适配。
2. 关键业务在其他业务突发流量时无法保证资源分配，导致关键业务处理能力受到影响

专有名词解释

1. 租户：租户(Tenant)为实现单实例多租户模式所提出的概念，租户的层级结构在一个数据库实例之下，在DB与user之上。租户又可以分为系统租户与普通租户： a. 系统租户是为了适配原有模式下user的使用，原有数据库实例中的user默认属于系统租户，也可以成为系统用户。当通过系统租户下的user连接数据库时，可以访问所有租户下的DB（如果有对应权限）。 b. 普通租户需要在系统租户下进行创建。普通租户下的DB与user都是完全隔离的，无法互相访问，并且普通租户无法访问至系统租户下的DB。
2. 逻辑 DB name：各租户下的DB是完全隔离的，因此不同租户下可以存在相同名字的DB。如上图中tenant A B中都含有名为DB_1的DB。普通租户感知到的DB即为逻辑DB name。
3. 物理 DB name：即使各租户下可以存在同名DB，但在同一数据库实例下DB的存储肯定不能是相同的名称，因此在数据库实例上真正存储的DB name 为物理DB name。例如Tenant A下的DB_1，在实例上物理存储的name 为DB_1@A， DB_1@A即为对应的物理DB name。
4. 逻辑、物理user name：与逻辑、物理DB name 类似，逻辑、物理user name分别为普通租户感知到的user name以及真正存储在实例上的物理user name

整体架构设计

数据隔离

PolarDB 单实例多租户模式提供了数据隔离的能力。在多租户模式下，客户可以在同一个PolarDB 实例中创建多个租户，不同租户间的数据互不可见，并且在不同租户间可以创建同名DB/同名user。例如在上图中，Tenant A 中有 name 为DB_1的 database 以及 name为user_1 的 user，在多租户模式下，Tenant B 仍然可以创建DB_1 以及 user_1，这在原生MySQL中是不被允许的。这种数据隔离能力，能够解决部分Sass客户需要为不同租户维护不同业务代码的痛点。

资源隔离

PolarDB 单实例多租户模式提供了资源隔离的能力。在多租户模式下，客户可以创建多个resource_config 用来对租户进行资源限制，当租户绑定一个resource config 后，此租户使用的资源将会保证处于resource config的范围内。同时，后台线程会不断检测各租户间的负载情况，持续调度资源，来防止资源浪费。这种资源隔离能力，能够保证客户主要业务在其他业务流量突增时的稳定。