Azure 受控 Redis （預覽） 架構
Azure 受控 Redis （預覽版） 會在 Redis 企業堆疊上執行，其在 Redis 社群版本中提供顯著優勢。 下列資訊提供 Azure 受控 Redis 架構方式的更詳細數據，包括對進階使用者有用的資訊。
重要
Azure 受控 Redis 目前為預覽狀態。 請參閱 Microsoft Azure 預覽版增補使用規定，以了解適用於 Azure 功能 (搶鮮版 (Beta)、預覽版，或尚未正式發行的版本) 的法律條款。
與 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 程式來管理分區、處理連線管理，以及觸發自我修復。
此架構可同時啟用更高的效能和進階功能，例如 主動式異地復寫
叢集
由於 Redis Enterprise 能夠針對每個節點使用多個分區，因此每個 Azure 受控 Redis 實例都會在內部設定為跨所有層和 SKU 使用叢集。 這包括只設定為使用單一分區的較小實例。 叢集是將 Redis 實例中的數據分割成多個 Redis 進程的一種方式，也稱為「分區化」。Azure 受控 Redis 提供兩 個叢集原則 ，可判斷 Redis 用戶端可用來連線到快取實例的通訊協定。
叢集原則
Azure 受控 Redis 提供兩個叢集原則選擇：OSS 和企業。 對於大部分的應用程式建議使用 OSS 叢集原則，因為它支援較高的最大輸送量，但每個版本都有其優缺點。
OSS 叢集原則會實作與社群版 Redis 相同的 Redis 叢集 API。 Redis 叢集 API 可讓 Redis 用戶端直接連線到每個 Redis 節點上的分區，將延遲降到最低，並將網路輸送量優化，讓輸送量在分區和 vCPU 數目增加時以線性方式調整。 OSS 叢集原則通常會提供最佳的延遲和輸送量效能。 不過，OSS 叢集原則需要您的用戶端連結庫來支援 Redis 叢集 API。 目前，幾乎所有 Redis 用戶端都支援 Redis 叢集 API，但相容性可能是舊版用戶端版本或特製化連結庫的問題。 OSS 叢集原則也無法與 RediSearch 模組搭配使用。
企業叢集原則是更簡單的設定，會使用單一端點來處理所有用戶端連線。 使用企業叢集原則時，會將所有要求路由傳送至單一 Redis 節點，而該節點後續將作為 Proxy，在內部將要求路由傳送至叢集中的正確節點。 這種方法的優點是，它讓 Azure 受控 Redis 看起來對用戶來說不是叢集。 這表示 Redis 用戶端連結庫不需要支援 Redis 叢集，即可取得 Redis Enterprise 的一些效能優勢，提升回溯相容性，並讓連線更簡單。 缺點是，在計算使用率或網路輸送量中，單一節點 Proxy 可能會成為瓶頸。 企業叢集原則是唯一可與 RediSearch 模組搭配使用的叢集原則。 雖然企業叢集原則會讓 Azure 受控 Redis 實例對用戶來說似乎沒有叢集，但多鍵命令仍有一些限制。
相應放大或新增節點
核心 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 數目可能會隨著時間而變更。
| 階層 | Flash 最佳化 | 記憶體最佳化 | 平衡 | 計算最佳化 |
|---|---|---|---|---|
| 大小 (GB) | vCPU/主要分區 | vCPU/主要分區 | vCPU/主要分區 | vCPU/主要分區 |
| 0.5 | - | - | 2/1 | - |
| 1 | - | - | 2/1 | - |
| 3 | - | - | 2/1 | 4/2 |
| 6 | - | - | 2/1 | 4/2 |
| 12 | - | 2/1 | 4/2 | 8/6 |
| 24 | - | 4/2 | 8/6 | 16/12 |
| 60 | - | 8/6 | 16/12 | 32/24 |
| 120 | - | 16/12 | 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 | 16/12 | 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 優化層設計優化的存取特性：
- 寫入繁重的工作負載。
- 大部分數據集的隨機或統一數據存取模式。
- 具有相對較小的值大小之長索引鍵名稱。