共用方式為

部署

  • 發行項

連線復原能力和伺服器負載

開發用戶端應用程式時，請務必考慮連線復原能力和管理伺服器負載的相關最佳做法。

考慮更多的索引鍵和較小的值

Azure Cache for Redis 最適合使用較小的值。 若要將數據分散到多個索引鍵，請考慮將較大的數據區塊分割成較小的區塊。 如需理想值大小的詳細資訊，請參閱這篇文章。

大型要求或回應大小

大型的要求/回應可能會導致逾時。 例如，假設您在用戶端上設定的逾時值為 1 秒。 應用程式同時 (使用相同的實體網路連線) 要求兩個金鑰 (例如 'A' 和 'B')。 大部分用戶端都支援管道傳送要求，其中兩個要求 『A』 和 『B』 都會一個接一個地傳送，而不會等待其回應。 伺服器會以相同順序傳回回應。 如果回應 'A' 很大，其可能會用掉稍後要求的大部分逾時。

在下列範例中，'A' 和 'B' 要求會快速傳送至伺服器。 伺服器會開始快速傳送 'A' 和 'B' 回應。 由於資料傳輸時間，即使伺服器快速回應，'B' 回應必須等待 'A' 回應逾時。

|-------- 1 Second Timeout (A)----------|
|-Request A-|
     |-------- 1 Second Timeout (B) ----------|
     |-Request B-|
            |- Read Response A --------|
                                       |- Read Response B-| (**TIMEOUT**)

此要求/回應並不容易測量。 您可以檢測用戶端程式碼來追蹤大型要求和回應。

大型回應大小的解析會有所不同，但包括：

  • 將應用程式最佳化，以適用於大量的小型值，而不是少數幾個大型值。
  • 增加虛擬機的大小，以取得更高的頻寬功能
    • 用戶端或伺服器 VM 上的更多頻寬可減少較大回應的數據傳輸時間。
    • 將兩部機器上的目前網路使用量與目前 VM 大小的限制進行比較。 只在伺服器或用戶端上提高頻寬可能不夠。
  • 增加應用程式使用的連線物件數目。
    • 使用循環配置資源方法透過不同的連線物件提出要求。

金鑰散發

如果您打算使用 Redis 叢集，請先閱讀 Redis 叢集最佳做法與金鑰。

使用管線傳送

嘗試選擇支援 Redis 管線傳送的 Redis 用戶端。 管線傳送有助於有效地使用網路，並儘可能獲得最佳輸送量。

避免高成本的作業

某些 Redis 作業 (例如 KEYS 命令)，成本很高，因此應該避免。 如需關於長時間執行命令的一些考量，請參閱長時間執行命令。

選擇適當的階層

針對生產系統使用標準、進階、企業或企業 Flash 層。 請不要在生產環境中使用基本層。 基本層是單一節點系統，沒有資料複寫也沒有 SLA。 此外，請至少使用 C1 快取。 C0 快取僅適用於簡單的開發/測試情節，因為：

  • 其共用 CPU 核心
  • 使用很少的記憶體
  • 容易發生「擾鄰」問題

我們建議進行效能測試，以選擇正確的階層並驗證連線設定。 如需詳細資訊，請參閱效能計數器。

與快取位於相同區域的用戶端

將您的快取執行個體和應用程式定位在相同的區域中。 連線到不同區域中的快取會大幅增加延遲，並減少可靠性。

雖然您可以從 Azure 外部連線，但不建議這麼做，尤其是在使用 Redis 作為快取時。 如果您使用 Redis 伺服器只是索引鍵/值存放區，延遲可能不是主要考慮。

依賴主機名稱而非公用 IP 位址

指派給快取的公用 IP 位址可能會由於調整作業或後端改善而變更。 我們建議依賴主機名稱，而不是明確的公用 IP 位址。 以下是各種階層的建議表單：

層 表單​​
基本、標準、進階 <cachename>.redis.cache.windows.net
Enterprise，Enterprise Flash <DNS name>.<Azure region>.redisenterprise.cache.azure.net.

選擇適當的 Redis 版本

建立快取時使用的預設 Redis 版本可能會隨時間而變更。 當有新版本的開放原始碼 Redis 發行時，Azure Cache for Redis 可能會採用新版本。 如果您需要特定 Redis 版本用於您的應用程式，建議您在建立快取時明確選擇 Redis 版本。

使用 TLS 加密

Azure Cache for Redis 預設需要 TLS 加密通訊。 目前支援 TLS 1.0、1.1 和 1.2 版。 不過，整個產業即將棄用 TLS 1.0 和 1.1，因此請儘可能使用 TLS 1.2。

如果您的用戶端程式庫或工具不支援 TLS，則可以透過 Azure 入口網站或管理 API啟用未加密的連線。 若無法進行加密連線，建議您將快取和用戶端應用程式放入虛擬網路。 如需虛擬網路快取情節中使用哪些連接埠的詳細資訊，請參閱此資料表。

Azure TLS 憑證變更

Microsoft 正在更新 Azure 服務，以使用來自一組不同憑證授權單位 (CA) 的 TLS 伺服器憑證。 這項變更會在 2020 年 8 月 13 日到 2020 年 10 月 26 日 (預估日期) 分段推出。 由於目前 CA 憑證不是其中一個 CA/瀏覽器論壇基準需求，因此 Azure 將要進行此變更。 此問題已於 2020 年 7 月 1 日回報，並適用於全世界多個熱門公開金鑰基礎結構 (PKI) 提供者。 Azure 服務今日所使用的大部分 TLS 憑證都來自 Baltimore CyberTrust Root PKI。 Azure Cache for Redis 服務會繼續鏈結至 Baltimore CyberTrust Root。 不過，從 2020 年 10 月 12 日開始，新的中繼憑證授權單位 (ICA) 會發行其 TLS 伺服器憑證。

注意

這項變更僅限於公用 Azure 區域中的服務。 其會排除主權 (例如，中國) 或政府雲端。

這項變更是否會對我造成影響？

大部分的 Azure Cache for Redis 客戶都不會受到變更的影響。 如果應用程式明確指定可接受的憑證清單，即稱為 憑證釘選的做法，可能會受到影響。 如果其釘選到中繼憑證或分葉憑證，而不是 Baltimore CyberTrust Root，您應該立即採取動作來變更憑證設定。

Azure Cache for Redis 不支援 OCSP 裝訂。

下表提供所要滾動憑證的相關資訊。 根據應用程式使用的憑證，您可能需要更新該憑證，以防止失去 Azure Cache for Redis 執行個體的連線。

CA 類型 目前 滾動後 (2020 年 10 月 12 日 12) 動作
根目錄 指紋：d4de20d05e66fc53fe1a50882c78db2852cae474

到期日：2025 年 5 月 12 日星期一下午 4:59:00

主體名稱：
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = Baltimore
C = IE		 不會變更 無
中繼 指紋：
CN = Microsoft IT TLS CA 1
指紋：417e225037fbfaa4f95761d5ae729e1aea7e3a42

CN = Microsoft IT TLS CA 2
指紋：54d9d20239080c32316ed9ff980a48988f4adf2d

CN = Microsoft IT TLS CA 4
指紋：8a38755d0996823fe8fa3116a277ce446eac4e99

CN = Microsoft IT TLS CA 5
指紋：Ad898ac73df333eb60ac1f5fc6c4b2219ddb79b7

到期日：2024 年 5 月 20 日星期五上午 5:52:38

主體名稱：
OU = Microsoft IT
O = Microsoft Corporation
L = 雷德蒙德
S = 華盛頓州
C = 美國
 指紋：
CN = Microsoft RSA TLS CA 01
指紋：703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
指紋：b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

到期日：2024 年 10 月 8 日上午 12:00:00；

主體名稱：
O = Microsoft Corporation
C = 美國
 必要

我應該採取哪些動作？

如果您的應用程式使用作業系統憑證存放區或釘選 Baltimore 根等，則不需要採取任何動作。

如果您的應用程式釘選任何中繼或分葉 TLS 憑證，建議您釘選下列根：

憑證 指紋
Baltimore 根 CA d4de20d05e66fc53fe1a50882c78db2852cae474
Microsoft RSA Root Certificate Authority 2017 73a5e64a3bff8316ff0edccc618a906e4eae4d74
Digicert Global Root G2 df3c24f9bfd666761b268073fe06d1cc8d4f82a4

提示

預期中繼憑證和分葉憑證都會經常變更。 建議不要依賴這些憑證。 改為將您的應用程式釘選到根憑證，因為其較不頻繁地滾動。

若要繼續釘選中繼憑證，請將下列憑證新增至釘選的中繼憑證清單，其中包含更多憑證以將未來的變更降至最低：

CA 的一般名稱 指紋
Microsoft RSA TLS CA 01 703d7a8f0ebf55aaa59f98eaf4a206004eb2516a
Microsoft RSA TLS CA 02 b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75
Microsoft Azure TLS Issuing CA 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS Issuing CA 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS Issuing CA 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS Issuing CA 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

如果您的應用程式驗證程式碼中的憑證，您必須修改該憑證，以辨識新釘選憑證的屬性，例如，簽發者、指紋。 這個額外的驗證應該涵蓋所有釘選的憑證，以在未來提供更多證明。

用戶端程式庫特定的指引

如需詳細資訊，請參閱用戶端程式庫。

下一步