租戶可以理解爲部署在雲端的客戶，通常出現在2B的企業中，比如現在學校的一卡通管理，通常是一個公司來做的，學校本地不需要做任何部署，而這個公司又是服務了很多個學校，那麼學校對於公司來說就是一個租戶。
SaaS多租戶架構一共有三種
1. 獨立數據庫
這是第一種方案，即一個租戶一個數據庫，這種方案的用戶數據隔離級別最高，安全性最好，但成本較高。
優點：
爲不同的租戶提供獨立的數據庫，有助於簡化數據模型的擴展設計，滿足不同租戶的獨特需求；如果出現故障，恢復數據比較簡單。
缺點：
增多了數據庫的安裝數量，隨之帶來維護成本和購置成本的增加。
這種方案與傳統的一個客戶、一套數據、一套部署類似，差別只在於軟件統一部署在運營商那裏。如果面對的是銀行、醫院等需要非常高數據隔離級別的租戶，可以選擇這種模式，提高租用的定價。如果定價較低，產品走低價路線，這種方案一般對運營商來說是無法承受的。
2. 共享數據庫，隔離數據架構
這是第二種方案，即多個或所有租戶共享Database，但是每個租戶一個Schema（也可叫做一個user）。
優點：
爲安全性要求較高的租戶提供了一定程度的邏輯數據隔離，並不是完全隔離；每個數據庫可支持更多的租戶數量。
缺點：
如果出現故障，數據恢復比較困難，因爲恢復數據庫將牽涉到其他租戶的數據；
如果需要跨租戶統計數據，存在一定困難。
3. 共享數據庫，共享數據架構
這是第三種方案，即租戶共享同一個Database、同一個Schema，但在表中增加TenantID多租戶的數據字段。這是共享程度最高、隔離級別最低的模式。
對比
優點：
三種方案比較，第三種方案的維護和購置成本最低，允許每個數據庫支持的租戶數量最多。
缺點：
隔離級別最低，安全性最低，需要在設計開發時加大對安全的開發量；
數據備份和恢復最困難，需要逐表逐條備份和還原。
如果希望以最少的服務器爲最多的租戶提供服務，並且租戶接受犧牲隔離級別換取降低成本，這種方案最適合。
ps 我們屬於第二種架構。
參考
https://blog.csdn.net/yown/article/details/51288549