部署

  • 發行項

連線 復原和伺服器負載

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

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

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 版本。

企業層的特定指引

由於 Enterprise 和 Enterprise Flash 層是以 Redis Enterprise 而非開放原始碼 Redis 為基礎所建置，因此開發最佳做法有一些差異。 如需詳細資訊，請參閱 Enterprise 和 Enterprise Flash 層的最佳做法。

使用 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 日分階段推出（估計）。 Azure 正在進行這項變更，因為 目前的 CA 憑證不是其中一個 CA/瀏覽器論壇基準需求。 此問題於 2020 年 7 月 1 日報告，並適用於全球多個熱門的公鑰基礎結構 （PKI） 提供者。 Azure 服務目前使用的大部分 TLS 憑證都來自 Baltimore CyberTrust Root PKI。 Azure Cache for Redis 服務會繼續鏈結至 Baltimore CyberTrust Root。 不過，從 2020 年 10 月 12 日起，其 TLS 伺服器證書將由新的中繼證書頒發機構單位 （ICA） 發行。

注意

這項變更僅限於公用 Azure 區域中的服務。 它不包括主權（例如中國）或政府雲端。

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

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

Azure Cache for Redis 不支援 OCSP 裝訂。

下表提供正在復原之憑證的相關信息。 視您的應用程式使用何種憑證而定，您可能需要更新它，以避免失去 Azure Cache for Redis 實例的連線能力。

CA 類型 目前 張貼滾動 （2020 年 10 月 12 日） 動作
根目錄 指紋：d4de20d05e66fc53fe1a50882c78db2852cae474

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

主體名稱：
CN = Baltimore CyberTrust Root
OU = CyberTrust
O = 巴爾的摩
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 = Washington
C = US
 指紋：
CN = Microsoft RSA TLS CA 01
指紋：703d7a8f0ebf55aaa59f98eaf4a206004eb2516a

CN = Microsoft RSA TLS CA 02
指紋：b0c2d2d13cdd56cdaa6ab6e2c04440be4a429c75

到期日：2024 年 10 月 8 日星期二上午 12：00：00;

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

我應該採取哪些動作？

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

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

[MSSQLSERVER 的通訊協定內容] 指紋
巴爾的摩根 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 發行 CA 01 2f2877c5d778c31e0f29c7e371df5471bd673173
Microsoft Azure TLS 發行 CA 02 e7eea674ca718e3befd90858e09f8372ad0ae2aa
Microsoft Azure TLS 發行 CA 05 6c3af02e7f269aa73afd0eff2a88a4a1f04ed1e5
Microsoft Azure TLS 發行 CA 06 30e01761ab97e59a06b41ef20af6f2de7ef4f7b0

如果您的應用程式在程式代碼中驗證憑證，您必須修改它，以辨識---的屬性，例如，新釘選憑證的簽發者、指紋---。 此額外驗證應涵蓋所有已釘選的憑證，以取得更未來的證明。

用戶端連結庫特定指引

如需詳細資訊，請參閱 客戶端連結庫。

下一步