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