對於很多用戶來說，一直希望 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，共同來討論多租戶問題。