多租户系统设计之数据存储隔离

一、多租户架构的理解

核心定义

多租户架构的核心定义包括两点，第一点是一个服务，或者更通俗地讲是一套代码，被多方客户共用，第二点是不同客户之间的数据在逻辑上是隔离的，即每方客户拥有自己独立的数据空间，并在这个独立的数据空间内完成自身的业务行为。

其中客户的群体需要根据这个服务的类型来区分，如 Saas 服务提供商的客户一般是不同的企业，而企业内部系统的客户则一般是不同的团队或者是不同的产品业务线。在系统设计层面，我们称每个客户为一个租户。

要点

多租户系统设计的要点就是租户隔离，刚刚从定义中，我们提到租户的数据在逻辑上是需要隔离的，即对不同租户来说，只能操作属于自身的数据，而不能越界操作其他租户的数据，即需要做好权限控制，所以这个层面的隔离，我们可以称为是业务隔离。

另一方面，对于系统设计而言，我们需要考虑如何对不同租户的数据存储进行隔离，来保证不同租户的数据安全性、数据存储容量可拓展、以及租户的日常访问的高性能。我们称这种隔离为物理上的隔离，或者说是数据存储隔离，这种隔离不是用户直接感知，但是对于整个多租户系统的稳定性和可拓展性非常重要。

以下我们将详细分析数据存储隔离的设计方案，因为业务隔离的设计在一定程度上依赖于数据存储隔离。

二、多租户系统的数据存储隔离

对任何事情来说，适合的才是最重要的，对系统设计同样如此：技术方案不是越高大上，所用的技术越前沿就越好，而是需要寻找一个最符合业务场景的技术方案。

对于多租户系统的数据隔离来说，我们需要从数据安全性（数据私密性、数据故障恢复）、数据存储容量可拓展和访问（租户访问性能）可拓展，三大方面来考虑，同时需要与成本来权衡。具体为需要根据租户的业务类型，如银行类业务对数据安全性要求非常高，整个系统的租户数量，单个租户的业务数据容量和访问容量来考虑。

从数据安全性、数据存储容量可拓展和访问可拓展递减，同时成本也递减的角度，一般有以下三种设计方案：

分库方案

这种方案很好理解，每个租户都拥有一个独立的数据库，核心设计要点是应用的部署方式。在应用部署层面，可以有两种方式：

第一种方式与传统的软件服务商为每个客户在其局域网独立部署一套系统类似，每个租户都独立部署一个系统，每个系统连接单独的数据库，并且拥有独立的访问域名，只是多租户系统一般是在云服务，而不是企业内部局域网来部署的。

这种方式的好处是真正做到不同租户的互不影响，即不管是系统部署还是数据存储、访问、以及数据故障的恢复都是独立的，所以隔离性，即数据安全性、数据存储容量和访问的可拓展性都是最好的，但是由于需要为每个租户独立部署一套系统，所以成本也是最高的。这种方式的另外一好处是更容易进行服务定制。

独立部署的案例分析：项目管理平台

我曾在的XX游戏公司的项目管理平台就是基于这种方案设计的：同一套项目管理系统代码，为每个游戏工作室独立部署一个实例，使用单独的数据库，独立的域名。这样的好处是不同工作室分开，互不影响，并且可以方便为土豪工作室定制需求。缺点就很明显了，除了硬件成本，运维成本之外，还需要为每个部署实例维护一套配置文件，增加了开发维护复杂度。

 

另外一种方式是不同租户共用一套服务集群，在系统应用层面或者说是代码层面来将不同租户的数据路由到不同的数据库，即不同的分库，这种一般基于分库分表中间件来实现。由于这种方式不需要为每个租户部署一套系统，所有租户共用一套系统，所以系统维护成本会降低，并且可以根据访问量来调整集群机器量。

分表方案

这种方式与独立存储方案中的方式二类似，也是不同租户共用一个服务集群，在系统代码层面来区分不同的租户的数据，不同之处在于路由到的是同一个数据库的不同表，即分表，所以在实现层面也是基于分库分表中间件来实现。

这种方案的成本相对于分库方案的更低，但是也拥有很好的数据故障恢复性，即如果某个租户数据出现问题，则修复对应的表即可。由于这种方案共享同一个数据库，所以所能存储的数据容量较小，比较适合业务量（存储容量，访问量）较小的租户场景。

基于数据行的租户唯一标识

这种方案是将所有租户的数据存储在一起，即同一个数据库，同一个表中存储不同的租户数据，然后通过数据行的某个列的值来区分不同的租户，即每行数据由（租户标识，数据库记录ID）来唯一标识。所以这种方案在物理上，并无隔离性可言。如果某个租户的数据出现问题则需要通过该标识来查找这些数据，所以数据恢复难度难度较大，同时在数据存储容量和访问性能方面，不同租户之间也会相互影响。

在系统的代码层面，在每个涉及到租户数据操作的SQL都需要带上这个唯一的租户标识，所以也更容易出现不同租户数据泄漏问题，对开发人员的要求较高。但是这种方案的数据存储成本最低，比较适合业务量很小的场景。