Azure 受控 Redis 會在 Redis 企業堆疊上執行，其在 Redis 社群版本中提供顯著優勢。 下列資訊提供 Azure 受控 Redis 架構方式的更詳細數據，包括對進階使用者有用的資訊。
與 Azure Cache for Redis 的比較
Azure Cache for Redis 的基本、標準和進階層是以 Redis 社群版本為基礎所建置。 此 Redis 社群版本有數個重大限制，包括單個線程。 這可大幅降低效能，並讓調整效率降低，因為服務不會充分利用更多 vCPU。 典型的 Azure Cache for Redis 實例會使用如下的架構：
請注意，使用兩個 VM--一個主要和一個複本。 這些 VM 也稱為「節點」。主要節點會保存主要的 Redis 程式，並接受所有寫入。 復寫會以異步方式對復本節點執行，以在維護、調整或非預期的失敗期間提供備份複本。 由於社群 Redis 的單一線程設計，每個節點都只能執行單一 Redis 伺服器進程。
Azure 受控 Redis 的架構改善
Azure 受控 Redis 會使用更進階的架構，如下所示：
有數個差異：
- 每個虛擬機 （或 “node”） 會平行執行多個 Redis 伺服器進程（稱為「分區」）。 多個分區可讓每個虛擬機上的 vCPU 更有效率地使用率，以及更高的效能。
- 並非所有的主要 Redis 分區都位於相同的 VM/節點上。 相反地，主要和複本分區會分散到這兩個節點。 因為主要分區使用比復本分區更多的 CPU 資源，因此此方法可讓更多主要分區平行執行。
- 每個節點都有 高效能的 Proxy 程式來管理分區、處理連線管理，以及觸發自我修復。
此架構可同時啟用更高的效能和進階功能，例如 主動式異地復寫
叢集
每個 Azure 受控 Redis 實例都在內部配置為使用叢集，適用於所有層級和 SKU。 Azure 受控 Redis 是以 Redis Enterprise 為基礎，其能夠針對每個節點使用多個分區。 這包括只設定為使用單一分區的較小實例。 叢集是將 Redis 實例中的數據分割成多個 Redis 進程的一種方式，也稱為「分區化」。Azure 受控 Redis 提供三個 叢集原則 ，可判斷 Redis 用戶端可用來連線到快取實例的通訊協定。
叢集原則
Azure 受控 Redis 提供三個叢集原則： OSS、 企業和非叢集 （預覽版）。 對於大部分的應用程式建議使用 OSS 叢集原則，因為它支援較高的最大輸送量，但每個版本都有其優缺點。
OSS 的叢集策略實作了與 Azure Cache for Redis 各層相同的 Redis 叢集 API。 Redis 叢集 API 可讓 Redis 用戶端直接連線到每個 Redis 節點上的分區，將延遲降到最低，並將網路輸送量優化，讓輸送量在分區和 vCPU 數目增加時以線性方式調整。 OSS 叢集原則通常會提供最佳的延遲和輸送量效能。 不過，OSS 叢集原則需要您的用戶端連結庫來支援 Redis 叢集 API。 目前，幾乎所有 Redis 用戶端都支援 Redis 叢集 API，但相容性可能是舊版用戶端版本或特製化連結庫的問題。
OSS 叢集原則無法與 RediSearch 模組搭配使用。
OSS 叢集通訊協定需要客戶端進行正確的分區連線。 初始連線是透過埠 10000。 個別節點的聯機是透過使用85XX範圍內的埠來完成的。 85xx 埠可能會隨著時間而變更，而且不應該硬式編碼到您的應用程式。 支援叢集的 Redis 用戶端會使用 CLUSTER NODES 命令來判斷主要和複本分區所使用的確切埠，併為您建立分區連線。
企業叢集原則是更簡單的設定，會使用單一端點來處理所有用戶端連線。 使用企業叢集原則時，會將所有要求路由傳送至單一 Redis 節點，而該節點後續將作為 Proxy，在內部將要求路由傳送至叢集中的正確節點。 這種方法的優點在於，讓 Azure 託管 Redis 對用戶看起來不具叢集特性。 這表示 Redis 用戶端連結庫不需要支援 Redis 叢集，以取得 Redis Enterprise 的一些效能優勢。 使用單一端點可提升回溯相容性，並讓連接更簡單。 缺點是，在計算使用率或網路輸送量中，單一節點 Proxy 可能會成為瓶頸。
企業叢集原則是唯一可與 RediSearch 模組搭配使用的叢集原則。 雖然企業叢集原則會讓 Azure 受控 Redis 實例在使用者看來是非叢集的，但多鍵命令仍有一些限制。
非叢集 （預覽） 叢集原則會將數據儲存在每個節點上，而不需要分區化。 它只適用於大小為 25 GB 且更小的快取。 使用非叢集（預覽版）群集策略的情境包括：
- 從未分片的 Redis 環境移轉時。 例如，Azure Cache for Redis 的基本、標準和進階型號的非分片拓撲。
- 廣泛執行跨分區命令並將數據分割成分片時，可能導致系統故障。 例如，MULTI 命令。
- 使用 Redis 作為訊息代理程式且不需要分區化時。
使用非集中式（預覽版）政策的考量如下：
- 這隻適用於小於或等於 25 GB 的 Azure 受控 Redis 層。
- 與其他叢集策略相比，其性能不佳，因為只有在快取已分片時，CPU 才能使用多線程處理 Redis Enterprise 軟體。
- 如果您想擴展 Azure 受控 Redis 快取，您必須先更改叢集策略。
- 如果您要從基本、標準或進階非叢集拓撲移動，請考慮使用 OSS 叢集來改善效能。 只有在應用程式不支援 OSS 或企業拓撲時，才應該使用非叢集組態。
相應放大或新增節點
核心 Redis Enterprise 軟體能夠相應增加（使用較大的 VM）或相應放大（藉由新增更多節點/VM）。 最後，任一調整動作都完成相同的動作-新增更多記憶體、更多 vCPU 和更多分區。 由於這種備援，Azure 受控 Redis 無法控制每個設定中使用的特定節點數目。 此實作詳細數據會為用戶抽象化，以避免混淆、複雜度和次佳設定。 相反地，每個 SKU 都是使用節點組態來設計，以最大化 vCPU 和記憶體。 Azure 受控 Redis 的某些 SKU 只使用兩個節點，有些則使用更多節點。
多鍵命令
由於 Azure 受控 Redis 實例是使用叢集設定所設計，因此您可能會在多個密鑰上操作的命令上看到 CROSSSLOT 例外狀況。 具體行為會隨著使用的叢集原則而不同。 如果您使用 OSS 叢集原則，多鍵命令會要求所有索引鍵都對應至相同的雜湊位置。
您也可能看到企業叢集原則出現 CROSSSLOT 錯誤。 企業叢集的位置間僅允許使用下列多鍵命令：DEL、MSET、MGET、EXISTS、UNLINK 和 TOUCH。
在主動-主動資料庫中，只能對位於相同位置的索引鍵執行多鍵寫入命令 (DEL、MSET、UNLINK)。 不過，在主動-主動資料庫中的位置間允許使用下列多鍵命令：MGET、EXISTS 和 TOUCH。 如需詳細資訊，請參閱資料庫叢集。
分區化設定
Azure 受控 Redis 的每個 SKU 都會設定為平行執行特定數目的 Redis 伺服器進程。 輸送量效能、分區數目和每個實例上可用的 vCPU 數目之間的關聯性很複雜。 新增分區通常會提高效能，因為 Redis 作業可以平行執行。 不過，如果分區無法執行命令，因為沒有可用的 vCPU 可執行命令，效能實際上可能會下降。 下表顯示每個 Azure 受控 Redis SKU 的分區化設定。 這些分區會對應到優化每個 vCPU 的使用方式，同時保留 Redis Enterprise Proxy、管理代理程式和影響效能的 OS 系統工作 vCPU 週期。
備註
Azure 託管 Redis 會透過調整每個 SKU 上使用的分片數目與 vCPU，隨時間優化效能。
這很重要
使用超過 120 GB 記憶體的所有記憶體內部層都處於公開預覽狀態，包括記憶體優化 M150 和更新版本;平衡 B150 和更新版本;和計算優化 X150 和更新版本。 所有這些層級和更高層級都處於公開預覽狀態。
所有 Flash 優化層都處於公開預覽狀態。
| 級別 | Flash Optimized （預覽） | 記憶體最佳化 | 平衡 | 計算最佳化 |
|---|---|---|---|---|
| 大小 (GB) | vCPU/主要分區 | vCPU/主要分區 | vCPU/主要分區 | vCPU/主要分區 |
| 0.5 | - | - | 2/1 | - |
| 1 | - | - | 2/1 | - |
| 3 | - | - | 2/2 | 4/2 |
| 6 | - | - | 2/2 | 4/2 |
| 12 | - | 2/2 | 4/2 | 8月6日 |
| 24 | - | 4/2 | 8月6日 | 12月16日 |
| 六十 | - | 8月6日 | 12月16日 | 32/24 |
| 120 | - | 12月16日 | 32/24 | 64/48 |
| 180 * | - | 24/24 | 48/48 | 96/96 |
| 240 * | 8月6日 | 32/24 | 64/48 | 128/96 |
| 360 * | - | 48/48 | 96/96 | 192/192 |
| 480 * | 12月16日 | 64/48 | 128/96 | 256/192 |
| 720 * | 24/24 | 96/96 | 192/192 | 384/384 |
| 960 * | 32/24 | 128/192 | 256/192 | - |
| 1440 * | 48/48 | 192/192 | - | - |
| 1920 * | 64/48 | 256/192 | - | - |
| 4500 * | 144/96 | - | - | - |
* 這些層處於公開預覽狀態。
在沒有啟用高可用性模式的情況下執行
不啟用高可用性 （HA） 模式即可執行。 這表示您的 Redis 實例未啟用複寫，而且無法存取可用性 SLA。 不建議在開發/測試案例之外的非HA模式中執行。 您無法在已建立的實例中停用高可用性。 不過，您可以在沒有高可用性的實例中啟用高可用性。 由於在沒有高可用性的情況下執行的實例會使用較少的 VM/節點，所以 vCPU 無法有效率地使用，因此效能可能會較低。
保留的記憶體
在每個 Azure 受控 Redis 實例上，大約 20% 的可用記憶體會保留為非快取作業的緩衝區，例如故障轉移期間的復寫和作用中的異地復寫緩衝區。 此緩衝區有助於改善快取效能，並防止記憶體耗盡。
縮小
Azure 托管 Redis 目前不支援縮減。 如需詳細資訊，請參閱 調整 Azure 受控 Redis 的限制。
Flash 優化層
Flash 優化層會同時使用 NVMe Flash 記憶體和 RAM。 由於 Flash 記憶體成本較低，因此使用 Flash 優化層可讓您以降低價格效率來取捨一些效能。
在 Flash Optimized 實例上，20% 的快取空間位於 RAM 上，而其他 80% 則使用 Flash 記憶體。 所有密鑰都會儲存在 RAM 上，而值可以儲存在 Flash 記憶體或 RAM 中。 Redis 軟體會以智慧方式判斷值的位置。 經常存取的經常 性值會儲存在 RAM 上，而 較不常使用的冷 值則會保留在 Flash 上。 在讀取或寫入數據之前，必須將它移至 RAM，成為 經常性 數據。
由於 Redis 會針對最佳效能優化，因此實例會先填滿可用的 RAM，再將專案新增至 Flash 記憶體。 填滿 RAM 首先對效能有一些影響：
- 以低記憶體使用量進行測試時，可能會發生更佳的效能和較低的延遲。 使用完整快取實例進行測試可能會降低效能，因為只有 RAM 用於記憶體使用量低的測試階段。
- 當您將更多數據寫入快取時，相較於快閃記憶體，RAM 中的數據比例會降低，通常也會降低延遲和輸送量效能。
適用於 Flash 優化層的工作負載
在 Flash Optimized 層上可能正常執行的工作負載通常具有下列特性：
- 讀取繁重，具有高比率的讀取命令來寫入命令。
- 存取著重於索引鍵的子集，這些索引鍵的使用頻率會比數據集的其餘部分更頻繁。
- 與索引鍵名稱相比，相對較大的值。 （因為索引鍵名稱一律會儲存在 RAM 中，因此大型值可能會成為記憶體成長的瓶頸。
不適合 Flash 優化層的工作負載
某些工作負載具有較不針對 Flash 優化層設計優化的存取特性：
- 寫入繁重的工作負載。
- 大部分數據集的隨機或統一數據存取模式。
- 具有相對較小的值大小之長索引鍵名稱。