对于很多用户来说，一直希望 TiDB 能提供多租户的能力，也就是大家只想部署一个 TiDB 集群，然后将所有的租户业务放在这个 TiDB 集群上面运行。但其实我们并没有原生提供多租户的支持。即使在云上面，TiDB cloud 虽然有多租户的支持，但也仍然是一个租户一个独立的 TiDB 集群，这些集群都是通过 Kubernates 来管理的。那么，为啥我们不做呢，我想可能有如下的理由：
- 不要把鸡蛋放在一个篮子里面，我相信这句话大家都知道，无论 TiDB 有多么健壮，但如果只有一个集群，真出现了问题，很有可能所有业务都会受到影响。
- 隔离问题，在 TiDB 内部做不同租户的资源隔离其实算非常困难的，无论是对于 CPU，Mem 还有 I/O 的使用，其实都很难做到精细化的控制。很可能一个租户的大的查询请求就影响了其他的租户业务。所以我们更倾向于在外部用现阶段成熟的方案来做资源隔离。
- 升级问题，因为只有一个集群，所以如果我们给某个租户开发了一个功能，要不要整个集群进行升级？虽然 TiDB 可以不停机升级，但在升级的时候总是会对业务有轻微的影响，我们不得不去考量。
- 租户功能冲突，譬如某个租户为了更好的性能需要开启某个功能，但这个功能其实另外的租户不需要，那么我们到底要不要开启？
可以看到，单个 TiDB 实现多租户其实并没有我们想象中那么美好。虽然有一些数据库厂商说自己能支持多租户，但我们还是决定先不提供这个功能。刚好，最近看到了一篇 Paper 《Millions of Tiny Databases》，来自于 Amazon 团队，他们也有类似的考量。
在这篇论文里面，Amazon 团队构建了一个叫做 Physalia 的系统，当网络分区等故障出现的时候，Physalia 能尽量减少这些故障对整个系统的影响。它的设计其实挺简单，一个 Physalia 可以认为是一个 Colony，每个 Colony 里面有多个 Cells，每个 Cell 有多个 Clients。Cell 是 Physalia 降低故障半径的主要工具。
这里可以类比 TiDB，我们可以认为 Physalia 是一个 K8s 集群，每一个 Cell 是一个 TiDB 集群，而 Client 则是不同租户。Cell 里面 Clients 越多，那么当这个 Cell 出问题的时候影响的 Clients 就越多，反之则越少。原理其实很简单，下面是 Physalia 实际部署之后的效果，绿线右边就是部署之后，整个系统的错误率：
可以看到，使用 Physalia 之后，错误率减少了很多。这篇 Paper 其实比较清晰易懂，大家可以自己去看看。
上面只是提到了我们对于一些多租户的想法，但如果有用户真的想要 TiDB 提供多租户的功能，开几个脑洞先：
- 在 TiDB 这层提供简单的租户 Quota 控制，这个其实在之前的 TiDB hackathon 就有团队做了这个功能，因为 TiDB 每个请求都能知道查了多少 key 这些指标，所以我们可以在 TiDB 做一个简单的 Quota 控制，算一个粗糙版本多租户吧。
- 更加方便的多 TiDB 集群管理机制，我们可以在 K8s 上面支持，这个也是现在在云上 TiDB DBaaS 在做的事情。只要有 K8s，on-premise 支持也很容易。其实很多用户不想多套 TiDB 集群，一方面是担心多套 TiDB 的成本，另外就是担心运维复杂，但这些都是后面我们重点解决的问题，所以我相信这个仍然会是我们的演进方向。
- 用户可能为了方便，会开始将所有租户的数据放到一个 TiDB 集群，如果发现某个租户需要做更多的隔离了，通过 TiDB 工具快速的将数据迁移到另外一个 TiDB 集群进行管理。不过实话，我觉得如果能方便的运维多 TiDB 集群了，其实也没啥必要做这个了。
上面只是一些脑洞，我也非常欢迎社区的同学能给我们提 Proposal，共同来讨论多租户问题。
