Azure Cache for Redis 通常用來提升解決方案的效能、減少資料庫或其他數據層元件的負載，以及減少您在計算節點上儲存的狀態量。 在本文中，我們會說明 Azure Cache for Redis 的一些功能，這些功能對多租用戶解決方案很有用，然後在您規劃如何使用 Azure Cache for Redis 時，提供可協助您的指引連結。
隔離模型
使用使用 Azure Cache for Redis 的多租用戶系統時，您必須決定您想要使用的隔離等級。 Azure Cache for Redis 支持數個隔離模型。
下表摘要說明 Azure Cache for Redis 的主要租用隔離模型之間的差異：
| 考量事項 | 共用快取、共享資料庫 | 共用快取和資料庫、訪問控制清單 | 共用快取，租戶專屬資料庫 | 每個租戶的快取 |
|---|---|---|---|---|
| 資料隔離 | 低。 使用 Redis 資料結構或鍵前置詞來識別每個租戶的資料。 | 高。 數據會根據關鍵詞前綴進行隔離 | 低。 資料會分開，但未提供安全隔離 | 高 |
| 效能隔離 | 低。 所有租用戶共用相同的計算資源 | 低。 所有租用戶共用相同的計算資源 | 低。 所有租用戶共用相同的計算資源 | 高 |
| 部署複雜度 | 低 | 中低 | 中等 | 中高 |
| 操作複雜度 | 低 | 中低 | 低 | 中高 |
| 資源成本 | 低 | 低 | 低 | 高 |
| 案例範例 | 具有共享應用層的多租戶大型解決方案 | 具有存取快取之不同應用程式識別的大型多租用戶解決方案 | 將單一租戶應用程式移轉以支持多租戶模式 | 每個租戶的個別應用程式實例 |
共用快取實例和共享資料庫
您可以考慮使用單一 Redis 資料庫來部署單一快取，並使用它來儲存所有租使用者的快取數據。 當您擁有所有租用戶共用的單一應用程式實例時，通常會使用此方法。
當您遵循此方法時，應用程式只負責將租用戶數據分開。 您可以使用鍵前綴來區分不同租戶的數據，但您的應用程式必須謹慎地只存取它正在使用的租戶數據。 或者，您可以考慮針對每個租用戶的數據使用 Redis 數據結構，例如 集合 或 哈希。 每個方法都支援大量的金鑰，因此可以調整為許多租使用者。 不過，您必須管理應用程式內的授權，而不是在快取中管理。
當您在租用戶之間共用快取實例和資料庫時，請考慮所有租用戶共用快取的相同基礎計算資源。 因此，這種方法可能會容易受到 嘈雜的鄰居問題的影響。 請確定您遵循 Azure Cache for Redis 的最佳做法，以充分利用快取的資源，並降低任何嘈雜的鄰近影響。 最佳做法包括：
此外，請考慮監視快取的資源，例如 CPU 和記憶體。 如果您觀察到資源壓力，請考慮下列緩和措施：
- 將快取 SKU 或階層升級至資源更高的層級。
- 將快取數據分片，以擴展到多個快取。 其中一個選項是依租用戶分片，有些租用戶使用快取 A，有些租用戶則使用快取 B。或者，您可以依子系統分片，其中解決方案的一部分會將所有租用戶的數據快取至快取 A，另一部分則快取至快取 B。
具有訪問控制清單的共用快取和資料庫
如果您的應用層使用不同的身分識別來存取每個租戶的快取，請使用 Redis 存取控制清單。 訪問控制清單可讓您將租用戶資訊的存取限制為特定身分識別。 您可以根據金鑰名稱或前置詞來識別可由身份存取的數據。 當您針對每個租使用者有不同的應用程式實例，或者如果您有使用多個身分識別的共用應用程式，根據租用戶內容存取下游服務時，這個方法可能很適合。
與先前的隔離模型類似，共用快取和資料庫表示您需要採取預防措施，以避免 Noisy Neighbor 問題。
每個租用戶的資料庫共用快取實例
您可能考慮的另一種方法是部署單一快取實例，並在 實例內部署租使用者特定的 Redis 資料庫。 此方法提供每個租用戶數據的某種程度的邏輯隔離，但不會提供任何效能隔離或保護，以防止吵雜的鄰居。
這種方法對於移轉案例可能很有用。 例如，假設您將一個原本不支援多租戶的單一租戶應用程式進行現代化改造，並在所有請求中包含租戶上下文，逐漸將其轉換為支持多租戶的應用程式。 您可以使用單一共享快取來提高成本效益，且不需要更新應用程式的邏輯來使用租戶密鑰前綴或租戶專屬數據結構。
Azure Cache for Redis 會對可在單一快取上建立的資料庫數目施加限制。 實作此方法之前，請考慮您預期成長的租用戶數目。
此外，此方法不會為數據的安全性隔離提供任何優點。 在 Azure Cache for Redis 中，驗證和授權會在快取實例層級執行。
備註
Azure Cache for Redis 支援特定層上的多個資料庫，而且當您使用叢集實例時，它不支援多個資料庫。
每個租使用者的快取實例
您可以考慮為每個租使用者部署個別的 Azure Cache for Redis 實例。 您可以在單一 Azure 訂用帳戶內部署的快取數目沒有限制。 此方法提供最強層級的數據和效能隔離。
不過，每個快取都會以個別的 Azure 資源計費，因此當您的租戶數量大量增加時，可能會產生更多成本。 此外，這種方法通常無法有效利用每個快取的資源，因為每個 Azure Cache for Redis 實例通常能支援大量的請求。 如果您有嚴格的數據或效能隔離需求，最好只考慮此隔離方法。
支援多重租戶的 Azure Cache for Redis 功能
存取控制清單
Azure Cache for Redis 提供強大的 角色型訪問控制系統，可讓您建立完整的數據存取原則，以強制執行驗證和授權規則。 這些規則可以在不同的粒度層級指定，包括允許使用者存取遵循特定模式的快取索引鍵。 藉由使用密鑰模式，您可以在多個租用戶之間共用單一快取實例和資料庫，每個租使用者都有自己的用戶帳戶。 Azure Cache for Redis 會強制執行租戶隔離，以確保使用者只能存取自己遵循指定模式的密鑰集。
例如，假設您有名為 Fabrikam 的租使用者。 您的應用層應該只能存取與 Fabrikam 相關的快取資料，而不能存取其他租戶的資料。 您可以定義自訂存取原則，允許讀取和設定開頭 Fabrikam為 的所有快取索引鍵：
+@read +set ~Fabrikam*
接著，您可以將原則指派給 Fabrikam 應用程式實例所使用的Microsoft Entra 身分識別。 設定快取之後，Fabrikam 使用者可以存取名為 FabrikamData1 和 FabrikamUserDetails的金鑰，但無法 ContosoData1存取 。
主動式地理複寫
許多多租戶解決方案需要進行地理分布。 您可能會共用全域分散式應用層，您的應用程式實例會讀取和寫入附近的快取，以維持可接受的效能。 Azure Cache for Redis 的企業層支援在 主動-主動配置中，跨區域連結多個快取。
貢獻者們
本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。
主要作者：
- John Downs |首席軟體工程師
- Will Velida | Azure FastTrack 客戶工程師 2
其他貢獻者：
- Carl Dacosta |Azure Cache for Redis 的主要軟體工程管理員
- Kyle Teegarden |Azure Cache for Redis 資深項目經理
- 阿森·弗拉基米爾斯基 | Azure FastTrack 首席客戶工程師
若要查看非公開的 LinkedIn 個人檔案，請登入 LinkedIn。
後續步驟
檢閱 多租戶環境下的儲存和數據策略。