企業和企業 Flash 層的最佳做法為何
以下是使用 Azure Cache for Redis 的 Enterprise 和 Enterprise Flash 層時的最佳作法。
區域備援
強烈建議您在區域備援設定中部署新的快取。 區域備援可確保 Redis 企業版節點會分散到三個可用性區域，以提升數據中心層級中斷的備援。 使用區域備援會增加可用性。 如需詳細資訊，請參閱 在線服務的服務等級協定（SLA）。
區域備援對於企業層很重要，因為您的快取實例一律會使用至少三個節點。 兩個節點是數據節點，可保存您的數據，以及仲裁 節點。 增加容量會以偶數遞增的方式調整數據節點數目。
另外還有另一個節點稱為仲裁節點。 此節點會監視數據節點，並在發生故障轉移時自動選取新的主要節點。 區域備援可確保節點平均分散到三個可用性區域，將仲裁遺失的可能性降至最低。 客戶不會支付仲裁節點的費用，而且使用區域備援的費用不會超過 區域區域頻寬費用。
調整大小
在 Azure Cache for Redis 的 Enterprise 和 Enterprise Flash 層中，建議將相應增加作為相應放大的優先順序。優先增加，因為企業層是以 Redis Enterprise 為基礎所建置，因此能夠在較大的 VM 中使用更多 CPU 核心。
相反地，基本、標準和 進階版 層是相反的建議，其建置在開放原始碼 Redis 上。 在這些層中，在大部分情況下，建議將相應放大放在相應增加的優先順序。
分區化和 CPU 使用率
在 Azure Cache for Redis 的基本、標準和 進階版 層中，判斷使用的虛擬 CPU 數目很簡單。 每個 Redis 節點都會在專用 VM 上執行。 Redis 伺服器進程是單個線程，在每個主要和每個復本節點上使用一個 vCPU。 VM 上的其他 vCPU 仍會用於其他活動，例如不同工作的工作流程協調、健康情況監視和 TLS 負載等。
當您使用叢集時，效果是將數據分散到多個節點，每個節點各有一個分區。 藉由增加分區數目，您會根據叢集中的分區數目，以線性方式增加您使用的 vCPU 數目。
另一方面，Redis Enterprise 可以針對 Redis 實例本身使用多個 vCPU。 換句話說，Azure Cache for Redis 的所有層都可以針對背景和監視工作使用多個 vCPU，但只有 Enterprise 和 Enterprise Flash 層能夠針對 Redis 分區的每個 VM 使用多個 vCPU。 下表顯示用於每個 SKU 和容量 （也就是向外延展） 組態的有效 vCPU 數目。
數據表會顯示主要分區所使用的 vCPU 數目，而不是複本分區。 分區不會將一對一對應到 vCPU 數目。 數據表只會說明 vCPU，而非分區。 某些組態會使用比可用的 vCPU 更多的分區，以提升某些使用案例中的效能。
E5
| Capacity | 有效的 vCPU |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| Capacity | 有效的 vCPU |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| Capacity | 有效的 vCPU |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| Capacity | 有效的 vCPU |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| Capacity | 有效的 vCPU |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| Capacity | 有效的 vCPU |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| Capacity | 有效的 vCPU |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| Capacity | 有效的 vCPU |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| Capacity | 有效的 vCPU |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| Capacity | 有效的 vCPU |
|---|---|
| 3 | 30 |
| 9 | 90 |
企業上的叢集
企業和企業 Flash 層本質上是叢集的，與基本、標準和 進階版 層相反。 實作取決於選取的叢集原則。 企業層針對叢集原則提供兩個選項：OSS 和企業。 建議針對大部分的應用程式使用 OSS 叢集原則，因為它支援更高的輸送量，但每個版本都有優點和缺點。
OSS 叢集原則會實作與開放原始碼 Redis 相同的 Redis 叢集 API。 Redis 叢集 API 可讓 Redis 用戶端直接連線到每個 Redis 節點，將延遲降到最低，並將網路輸送量優化。 因此，當擴充具有更多節點的叢集時，會取得近乎線性的延展性。 OSS 叢集原則通常提供最佳的延遲和輸送量效能，但需要您的用戶端連結庫來支援 Redis 叢集。 OSS 叢集原則也無法與 RediSearch 模組搭配使用。
企業 叢集原則 是一種更簡單的設定，可針對所有用戶端連線使用單一端點。 使用企業叢集原則會將所有要求路由傳送至單一 Redis 節點，然後做為 Proxy，並在內部將要求路由傳送至叢集中的正確節點。 這種方法的優點是 Redis 用戶端連結庫不需要支援 Redis 叢集，才能利用多個節點。 缺點是，在計算使用率或網路輸送量中，單一節點 Proxy 可能是瓶頸。 企業叢集原則是唯一可與 RediSearch 模組搭配使用的叢集原則。
多鍵命令
因為企業層使用叢集設定，因此您可能會在多個密鑰上操作的命令上看到 CROSSSLOT 例外狀況。 行為會根據所使用的叢集原則而有所不同。 如果您使用 OSS 叢集原則，多金鑰命令會要求所有金鑰都對應至 相同的哈希位置。
您可能也會看到 CROSSSLOT 企業叢集原則的錯誤。 只有下列多鍵命令可以跨具有企業叢集的插槽使用： DEL、 MSET、、 MGET、 EXISTS、 UNLINK和 TOUCH。
在 Active-Active 資料庫中，多金鑰寫入命令 （DEL、 MSETUNLINK、 ） 只能在位於相同位置的金鑰上執行。 不過，在 Active-Active 資料庫中的位置允許下列多鍵命令： MGET、 EXISTS和 TOUCH。 如需詳細資訊，請參閱 資料庫叢集。
企業 Flash 最佳做法
企業 Flash 層會同時使用 NVMe Flash 記憶體和 RAM。 由於 Flash 記憶體成本較低，因此使用企業 Flash 層可讓您以降低價格效率來取捨一些效能。
在企業 Flash 實例上，20% 的快取空間位於 RAM 上，而其他 80% 則使用 Flash 記憶體。 所有密鑰都會儲存在 RAM 上，而值可以儲存在 Flash 記憶體或 RAM 中。 值的位置是由 Redis 軟體以智慧方式決定。 存取的「經常性」值會儲存在 RAM 上，而較不常使用的「冷」值則會保留在 Flash 上。 在讀取或寫入數據之前，數據必須移至 RAM，成為「熱門」數據。
由於 Redis 會選擇獲得最佳效能，因此實例會先填滿可用的 RAM，再將專案新增至 Flash 記憶體。 這對效能有一些影響：
- 使用低記憶體使用量進行測試時，效能和延遲可能會明顯優於完整快取實例，因為只會使用 RAM。
- 當您將更多數據寫入快取時，相較於快閃記憶體，RAM 中的數據比例會降低，通常也會降低延遲和輸送量效能。
適用於企業 Flash 層的工作負載
在企業 Flash 層上可能執行良好的工作負載通常具有下列特性：
- 讀取繁重，具有高比率的讀取命令來寫入命令。
- 存取著重於索引鍵的子集，其使用頻率會比數據集的其餘部分更頻繁。
- 與索引鍵名稱相比，相對較大的值。 （由於密鑰名稱一律儲存在 RAM 中，這可能會成為記憶體成長的瓶頸。
不適合企業 Flash 層的工作負載
某些工作負載具有較不針對 Flash 層設計優化的存取特性：
- 寫入繁重的工作負載。
- 大部分數據集的隨機或統一數據存取父系。
- 具有相對較小的值大小之長索引鍵名稱。
使用主動式異地復寫處理區域關閉案例
主動式異地復寫是一項功能強大的功能，可在使用 Azure Cache for Redis 的企業層時大幅提升可用性。 不過，如果發生區域性中斷，您應該採取步驟來準備快取。
例如，請考慮下列秘訣：
- 事先識別異地復寫群組中要切換至的區域是否關閉的其他快取。
- 請確定已設定防火牆，讓任何應用程式和用戶端都可以存取已識別的備份快取。
- 異地復寫群組中的每個快取都有自己的存取密鑰。 決定當以備份快取為目標時，應用程式如何切換至不同的存取密鑰。
- 如果異地復寫群組中的快取關閉，則異地復寫群組中的所有快取中都會開始建置元數據。 在寫入可再次同步至所有快取之前，無法捨棄元數據。 您可以強制取消連結已關閉的快取，以防止元數據建置。 請考慮監視快取中的可用記憶體，並在有記憶體壓力時取消連結，特別是針對大量寫入工作負載。
也可以使用 斷路器模式。 使用 模式，自動將流量從發生區域中斷的快取重新導向，並導向至相同異地復寫群組中的備份快取。 使用 azure 服務，例如 Azure 流量管理員 或 Azure Load Balancer 來啟用重新導向。
數據持續性與數據備份
企業和企業快閃層中的數據持續性功能設計為在快取關閉時自動提供數據的快速恢復點。 藉由將 RDB 或 AOF 檔案儲存在掛接至快取實例的受控磁碟，就可以快速復原。 用戶無法存取磁碟上的持續性檔案。
許多客戶想要使用持續性來定期備份其快取上的數據。 我們不建議您以這種方式使用數據持續性。 請改用匯入 /匯出 功能。 您可以將 RDB 格式的快取資料複本直接匯出到您選擇的記憶體帳戶，並視需要觸發數據匯出。 您可以從入口網站或使用 CLI、PowerShell 或 SDK 工具觸發匯出。