SaaS 多租户背景
很多平台类应用或系统（如电商 CRM 平台、仓库订单平台等等），它们的服务模型是围绕用户维度（这里的用户维度可以是一个卖家或品牌，可以是一个仓库等）展开的。因此，这类型的平台业务，为了支持业务系统的水平扩展性，业务的数据库通常是按用户维度进行水平切分。
可是，当平台类应用的一些用户慢慢成长为大用户（比如大品牌、大卖家、大仓库等）后，这些大用户由于其数据量或流量明显要比其它用户多得多，容易导致以下的现象：
▶︎ 大用户所在分片会成为业务系统的热点，占用大量的数据库资源，其服务质量容易因资源受限导致不稳定；
▶︎ 其它小用户容易受到大用户资源消耗的影响，服务质量也受到影响。
最后就整个平台的业务系统的热点频现，数据库访问不稳定，业务服务受影响。
SaaS 多租户模型作为一种应用的架构，常用来解决业务的上述问题。在 SaaS 多租户模型中，业务系统会需要服务多个用户，每个用户（或每批用户）可以被视为一个租户。
这些不同的租户在业务系统内会使用共同的基础设施及其平台进行运行，但来自不同租户的数据仍将被独立隔离，因此，通常租户拥有自己物理资源来单独存储与管理数据。所以，SaaS 多租户解决业务系统稳定性问题以及租户资源弹性定制的核心思路，就是租户间的资源隔离及数据隔离。
在实际的不同应用场景下，常见的 SaaS 多租户方案有两种：
▶︎ Schema 级 SaaS 多租户
Schema 级 SaaS 多租户，是指一个租户对应一个包含多个 Table 定义的 Schema（或一个 Database，在 MySQL, Schema 概念等同 Database）， 不同租户的 Schema 会分布在不同的机器上（如下图 1 所示），实现资源隔离，该方案适用于不同租户需要使用独立 Schema 运行的场景；
▶︎ Partition 级 SaaS 多租户
Partition 级 SaaS 多租户，是指一个租户会对应一个 Table 的一个或多个的分区（或是一个 Table 的一部分 rows)，不同租户的 Parittion 会分布在不同的机器上（如上图 2 所示），以实现资源隔离，该方案比较适用于不同租户需要使用统一 Schema 运行的场景。
从隔离程度来看， Schema 级 SaaS 多租户比 Partition 级 SaaS 多租户要隔离得更彻底，但前者因为要维护众多的 Schema，会比后者会带来更高的运维成本及查询分析成本。
不过，Partition 级 SaaS 多租户通常要依赖中间件分库分表或分布式数据库分区功能（不然单机数据库无法做到资源隔离）才能运作，而 Schema 级 SaaS 多租户则不需要，用户自己搭建几个单机 MySQL 也可以运作起来，准入门槛更低。
业务的问题
业务多租户场景
只说应用架构可能有些抽象，为了方便读者更容易地理解 SaaS 多租户是如何帮助业务解决问题， 本文将以一个真实的案例来进行阐述。
正马软件的班牛平台是国内领先的提供电商全周期客户服务的卖家订单管理平台（以下简称 B 公司）。它的业务系统需要维护多个不同品牌的众多卖家。通常一个品牌会有多个卖家（比如，一个品牌可能会开通多个线上店铺），所以，品牌与卖家是一对多的关系。
目前，B 公司的订单管理平台管理着超过 50T 的订单数据，日 QPS 近 3W+，不同品牌的订单量差异会比较大（大品牌的订单可能是小品牌的订单量的近百倍或更高）。一些大品牌除了订单量比其它品牌的大很多之外，还会使用更高级的付费 VIP 服务：比如，要求订单数据独占资源与数据隔离、允许独立地统计分析自己品牌的订单数据等。
B 公司为了解决不同品牌的数据的资源使用及其服务差异，就会对它的卖家按品牌划分（相当于一个品牌是一个租户）：
大品牌诉求：
订单量大（如订单数据存储的大小超过 1T 或 2T），数据存储量大；
独占一组的存储资源、有独立访问分析数据的需求；
该品牌的所有商家都必须同一组的存储资源；
大品牌的大卖家 150+，后边还会陆续增加；
小品牌诉求：
订单表小，商家数目大（6W+卖家）；
共用一组存储资源；
要求所有卖家数据在存储上均衡分布。
现在的核心问题是，B 公司的订单管理平台的数据库应该如何设计，才能满足上述众多不同品牌及其大卖家对于不同资源使用与数据隔离的诉求？
普通中间件方案及其问题
对于上述的业务场景，B 公司若不使用分布式数据库，而是简单通过单机 MySQL 及一些开源的分库分表中间件，自己搭建一套 SaaS 多租户方案（比如将品牌及其卖家切分为租户），进行租户的资源隔离。表面上，这貌似可行；但实际上，业务会因此要面临更多更为棘手的问题。
首先是跨机分布式事务问题。绝大多数的分库分表中间件无法提供强一致分布式事务能力，或者只能提供基于最终一致性的事务补偿方案，这意味着业务需要做很多额外的应用改造成本，才能尽量来避免跨机事务导致业务出现报错。
然后是 Schema 一致性问题。基于中间件分库分表，无论是采用 Schema 级多租户及是 Partition 级多租户，B 公司的订单平台都要面临自己维护各个租户的 Schema 或 Table 的元数据一致性。比如，MySQL 的建删表、加减列、加减索引等常见的 DDL 操作，中间件的方案无显然法保证平台所有租户的表能同时生效，一旦执行中断，必须靠人工介入来订正，人力成本高。
接着是租户的数据迁移问题。基于 SaaS 多租户方案，B 公司若要给一个大品牌分配新的独立资源，这自然免不了将租户数据从原来机器到新机器的数据迁移。这个数据迁移操作只能依赖额外的同步工具构建同步链路才能完成，这中间切割过程甚至还需要业务停机。这意味，业务执行添加一个新租户这一基本操作，也会带来非常高昂的运维成本。
综合上述的分析，B 公司直接基于单机 MySQL 及一些中间件的 SaaS 多租户方案，并不是一个成本低廉的方案。
SaaS 多租户 PolarDB 分布式版方案
事实上，在阿里云瑶池旗下的云原生数据库 PolarDB 分布式版 2.0(PolarDB for Xscale，简称 PolarDB-X) 中，B 公司已经可以通过结合非模板化二级分区与 Locality 两项能力，来很好的解决其上述业务所面临的问题。为了方便读者更易理解，以下先简单介绍下 PolarDB 分布式版 2.0 的非模板化二级分区与 Locality 两项的功能。
非模板化二级分区
PolarDB 分布式版 从 5.4.17 开始支持使用二级分区创建分区表。与其它分布式数据库所有不同，PolarDB 分布式版的二级分区除了语法能完全兼容原生 MySQL 二级分区语法外，还额外扩展很多的二级分区的能力，比如：支持用户定义非模板化二级分区（原生 MySQL 只支持模板化二级分区）。
所谓的非模板化二级分区，就是各个一级分区之下的二级分的分区数目及其边界值定义允许不一致，如下所示：
/* 一级分区 LIST COLUMNS + 二级分区HASH分区 的非模板化组合分区 */CREATE TABLE t_order /* 订单表 */ ( id bigint not null auto_increment, sellerId bigint not null, buyerId bigint not null, primary key(id)) PARTITION BY LIST(sellerId/*卖家ID*/) /* */SUBPARTITION BY HASH(sellerId) ( PARTITION pa VALUES IN (108，109) SUBPARTITIONS 1 /* 一级分区 pa 之下有1个哈希分区, 保存大品牌 a 所有卖家数据 */, PARTITION pb VALUES IN (208，209) SUBPARTITIONS 1 /* 一级分区 pb 之下有1个哈希分区, 保存大品牌 b 所有卖家数据 */, PARTITION pc VALUES IN (308，309，310) SUBPARTITIONS 2 /* 一级分区 pc 之下有2个哈希分区, 保存大品牌 c 所有卖家数据 */, PARTITION pDefault VALUES IN (DEFAULT) SUBPARTITIONS 64 /* 一级分区 pDefault 之下有64个哈希分区, 众多小品牌的卖家数据 */);
基于上述的 LIST+HASH 非模板化二级分区，它能给应用直接带来的的效果是：
-
对于大品牌的卖家（相当一个租户），可以将数据路由到单独的一组分区；
-
对于中小品牌，可以将数据按哈希算法自动均衡到多个不同分区，从而避免访问热点。
当大品牌与中小品牌的商家数据按 LIST 分区实现了分区级的隔离后，那实现大品牌与中小品牌的存储资源的物理隔离也就自然而言的事了。在 PolarDB 分布式版 2.0 中，用户可以借助 Locality 的能力，很容易地实现不同分区之间的资源隔离。
LOCALITY 资源绑定
PolarDB 分布式版支持通过 LOCALITY 关键字来指定数据库分区的实际存储资源位置（PolarDB 分布式版中存储资源由多个数据节点（DN 节点）组成，可以通过 DN 的 ID 进行位置分配），以实现数据隔离或数据的均匀分布。它的具体语法如下所示：
ALTER TABLE #tableName MODIFY (SUB)PARTITION #(sub)partName SET LOCALITY='dn=dn1[, dn2,...]'
例如，B 公司可以使用以下的 SQL 命令将 t_order 中的大品牌 pa 的数据全部单独挪到一个存储节点 dn4 ：
ALTER TABLE t_order MODIFY PARTITION pa SET LOCALITY='dn=dn4'
在实际使用中，用户可以通过 SHOW STORAGE 查询 PolarDB-X 的所有 DN 节点实例 ID 列表，例如：
mysql> show storage;+----------------------------+----------------+------------+-----------+----------+-------------+--------+-----------+------------+--------+| STORAGE_INST_ID | LEADER_NODE | IS_HEALTHY | INST_KIND | DB_COUNT | GROUP_COUNT | STATUS | DELETABLE | DELAY | ACTIVE |+----------------------------+----------------+------------+-----------+----------+-------------+--------+-----------+------------+--------+| polardbx-storage-0-master | 10.0.x.1:3306 | true | MASTER | 41 | 66 | 0 | false | null | null || polardbx-storage-1-master | 10.0.x.1:3307 | true | MASTER | 41 | 53 | 0 | true | null | null || ...... | ...... | true | META_DB | 2 | 2 | 0 | false | null | null |+----------------------------+----------------+------------+-----------+----------+-------------+--------+-----------+------------+--------+
设计 SaaS 多租户方案
回到之前 B 公司的例子，B 公司的核心需求是要实现大品牌与中小品牌的卖家数据及其存储资源的隔离。那么，B 公司可以在上述的二级分区的分区表的基础上，通过再给每个一级分区增加对应的 LOCALITY 定义，以指定一级分区及其所有二级分区所允许使用的存储资源，那么业务就可以在建表阶段直接实现 SaaS 层多租户（即品牌方）存储资源的隔离，如下所示：
/* 一级分区：list columns，二级分区：key 的非模板化组合分区 */CREATE TABLE t_orders /* 订单表 */ ( id bigint not null auto_increment, sellerId bigint not null, buyerId bigint not null, primary key(id)) PARTITION BY LIST(sellerId /* 卖家ID */ ) SUBPARTITION BY HASH(sellerId) ( PARTITION pa VALUES IN (108，109,....) LOCALITY='dn=dn16' /* 大品牌 pa 独占一个DN dn4 */ SUBPARTITIONS 1, PARTITION pb VALUES IN (208，209,....) LOCALITY='dn=dn17' /* 大品牌 pb 独占一个DN dn5 */ SUBPARTITIONS 1 , PARTITION pc VALUES IN (308，309，310,...) LOCALITY='dn=dn18,dn19' /* 大品牌 pc 独占两个DN: dn6 与 dn7 */ SUBPARTITIONS 2, PARTITION pDefault VALUES IN (DEFAULT) /* 一级分区 pDefault 占用 dn0 ~ dn15 共16个DN, 中小品牌共享 */ LOCALITY='dn=dn0,dn1,...,dn2,dn15' SUBPARTITIONS 64 );
如上图所示，通过 Locality 对各个一级分区的 DN 节点资源的绑定，pa、pb、pc 这 3 个大品牌的租户被分别配了 DN16、DN17 与 DN18~DN19 3 组的节点资源，而中小卖家池的 pDefault 分区则被绑定了 16 个 DN 节点。
SaaS 多租户运维管理
当二级分区及 Locality 能力解决了 B 公司对于不同品牌的多租户资源隔离后， 那马上需要面临的问题自然是：用户将如何有效便捷地管理这些多租户？答案是 PolarDB 分布式版 2.0 的分区管理能力。
PolarDB 分布式版 2.0 对于分区表提供了一系列完备的灵活强大的分区管理命令（如下图所示），让用户能够仅仅通过简单 SQL 命令，就可以实现在多租户场景下的不同运维变更的诉求。
接下来我们还是通过 B 公司的例子，来单独介绍基于分区管理支持 SaaS 多租户场景下的常见的运维变更。
场景一：基于修改 LIST 分区实现给租户添加新的卖家
以 B 公司为例，B 公司的一个租户对应的是一个品牌方，一个品牌在 B 公司的平台通常会有多个卖家。因此，当品牌方开了新的商铺时，就需要将新的卖家 ID 加入到这个品牌方对应的租户资源之下。
借助 PolarDB-X 的 MODIFY PARTITION ADD/DROP VALUES 的功能，可以方便地给 LIST 分区添加新的卖家 ID，如下所示：
/* 给品牌 pb 增加新的卖家 205 */ALTER TABLE t_orders MODIFY PARTITION pb ADD VALUES (205);
在这个 DDL 的执行中，PolarDB 分布式版会自动地从 LIST 的 DEFAULT 分区（如果有显式定义 DEFAULT 分区的话）抽取 sellerId=205 的所有数据，并迁移到 pb 分区中，DDL 全过程 Online ，业务应用几乎无感知。
场景二：基于增加 LIST 分区实现给添加新租户并分配新的存储资源
诸如 B 公司这类订单管理平台，平台上的各品牌的卖家通常会经历从无到有，从小卖家发展成大卖家的过程。因此，当一个品牌的小卖家发展成一个大卖家时，该品牌就可能会让 B 公司将它的卖家从中小品牌的卖家池（比如 DEFAULT 分区）中抽取了出来，使之成为独立租户的 VIP，并为之分配单独的存储资源。
借助 PolarDB 分布式版的 ADD/DROP PARTITION 及其 Locality 的功能，B 公司可以很便捷地在线地完成上述场景的变更操作。例如，B 公司想将新的大品牌 pe 的大卖家 301 从 DEFAULT 分区中抽取出来，并使之独占新的存储资源 new_dn ，如下所示：
/* 1.B公司在管控购买新的 CN/DN 的节点资源... *//* 2.增加新的大卖家，创建新分区并放置到特定的DN节点 */ALTER TABLE t_orders ADD PARTITION ( /* pDefault 分区里再抽取出新的大卖家 301 , 并命名为 pe, 并将其数据放置新节点 new_dn */ PARTITION pe VALUES IN (301) LOCALITY='dn=new_dn' SUBPARTITIONS 1,);
与 MODIFY PARTITION 类似，这些 ADD/DROP PARTITION 的变更操作也属于 Online DDL， 这中间的数据迁移操作对业务应用近乎透明。
场景三：基于分区级 Locality 支持租户内二级分区数据的重均衡
PolarDB 分布式版的 LIST + KEY 非模板化二级分区，在多租户场景下，能给用户提供一个重要的特性，就是它允许不同的租户的二级哈希分区数目不一样。这样意味着，不同的租户允许通过定义不同的二级分区数目，可以使用不同数量的存储资源。
例如，B 公司的 t_orders 表的 LIST 分区定义中，大品牌 pc 的一级 LIST 分区之下的二级分区数目是 2，并同时独占了 2 个 DN 节点来存储订单数据（即 pc 分区的每个 DN 节点都分配一个二级分区）。此外，还有它的中小品牌的卖家所共享的 DEFAULT 分区之下有 64 个二级分区，并且还独占 dn0 ~ dn15 共 16 个 DN 节点（如下所示）：
PARTITION pDefault VALUES IN (DEFAULT) /* 一级分区 pDefault 占用 dn0 ~ dn3 共16个DN, 中小品牌共享 */ LOCALITY='dn=dn0,dn1,...,dn2,dn15' SUBPARTITIONS 64
可是，DEFAULT 分区里的众多中小卖家也可能存在一些热点（比如，20%的头部卖家可能占订单数量 80%），这些热点卖家如果分布不合理，也可能会导致 DEFAULT 内部的 16 个 DN 节点间负载不均衡。
因此，B 公司需要面临的问题是：该如何管理这 64 个二级分区的众多中小卖家的订单数据，才能相对均衡地分布到这 16 个 DN 节点，并保证系统整体的负载均衡呢？这就是需要使用 PolarDB 分布式版的分区级 Rebalance 能力。
PolarDB 分布式版的分区级 Rebalance 功能允许用户对一个一级分区内部的多个二级分区，按一级分区的 Locality 进行自动的物理分片调度，使这些二级分区在 Locality 所定义的 DN 节点上保持均衡分布。用户只需要执行一条 SQL 命令（如下所示）, 即可完成上述的均衡变更：
REBLANCE TABLE t_orders PARTITIONS=pDefault;
场景四：基于分区选择及视图功能支持租户的数据查询及数据安全
PolarDB 分布式版的分区表及 Locality 的 SaaS 级多租户能力，对于诸如 B 公司这类订单管理平台，除了能满足其对品方的数据隔离与资源隔离的诉求外，还可以为业务提供更多的数据查询的能力。
比如，B 公司平台上的大品牌，偶尔还需要使用诸如独立查询及分析自己的订单数据等的 VIP 服务。这些品牌方会通过 B 公司所提供一些 Web SQL 工具来直接查询分析自己的订单数据（比如查询重要客户的订单数目等）。
可是，B 公司作为平台性的系统，它需要保证不同租户间的数据安全及其隔离：即租户查询订单数据只能看到自己的数据，无法看到其它租户的任何数据。
那么，基于 PolarDB 分布式版的分区表，B 公司是如何解决不同租户的数据隔离的问题呢？答案是借助分区选择与视图定义。
比如，B 公司如果想授权它的租户 pb 单独查询及分析它自己的订单数据，它的 Web SQL 工具将会自动化地使用类似以下的 SQL 命令提前在 PolarDB 分布式版上为该租户 pb 创建出对应的只读视图 t_order_pb_view ：
CREATE VIEW t_order_pb_view AS SELECT * FROM t_orders PARTITION（pb) /* t_orders 表的数据只会返回 pb分区以及下所有二级分区 */ ;
然后，平台再通过对租户 pb 账号信息进行自动化的相关授权操作后，租户 pb 在其所提供的 Web SQL 工具里登录后将只允许看到 t_order_pb_view 这个只读视图。
那么，假如租户要执行诸如下边所示的这类的统计订单总数的视图查询：
/* 大租户 pb 查询订单数据的SQL：统计订单数目 */SELECT COUNT(1) FROM t_order_pb_view;
PolarDB 分布式版将自动地把视图 t_order_pb_view 替换为对应的子查询：
/* 大租户 pb 查询订单数据的SQL：统计订单数目 */SELECT COUNT(1) FROM ( SELECT * FROM t_orders PARTITION（pb)) as t_order_pb_view;
如此一来，基于分区选择语法的限定，视图 t_order_pb_view 将只允许返回 pb 分区的数据。这样租户 pb 无法查询到其它租户的卖家订单数据，从而达到数据隔离的效果。
实践总结
PolarDB 分布式版分区表及其配套的灵活的管理语法，在不同的业务场景下，可以包装出各种业务模型。比如，本文所介绍的基于非模板化二级分区 + Locality 能力的所构建的 SaaS 多租户就是其中的经典用法之一。
事实上，本文所提及的真实案例的 B 公司的商家订单管理系统已经基于上述的 PolarDB 分布式版 2.0 的 SaaS 多租户方案成功上线（其应用架构如下图所示），目前它所提供的平台负责管理着超过 50T 的订单数据。
但是，B 公司的案例显然是一个能够复制并推而广之的案例。比如，它的租户维度--品牌，可以很容易联想到其它的业务维度并可以构建类似的实践，比如：各大仓库物流单管理、直播平台各直播室的观众送礼物的数据管理、各大城市交通监控数据管理、各大省份气象监控数据收集，等等。
简单总结一下最佳实践，若业务场景存在：
▶︎ 需要对数据按某个维度（如地域、仓库、商家或品牌等）进行水平切分，划分多个业务单元；
▶︎ 还需要为切分后的业务单元进行不同的资源配置及数据的物理隔离；
涉及到以上几点的用户都可以参考使用本文 SaaS 多租户方案进行数据库设计。
标签：租户,分区,SaaS,品牌,卖家,PolarDB From： https://www.cnblogs.com/aliyunyaochidatabase/p/17972619