Azure 受控 Redis （預覽） 管理常見問題

建議在所有 Redis 使用案例中，使用 TLS 作為最佳做法。 在沒有 TLS 的情況下連線的選項會包含在回溯相容性用途中。

• StackExchange.Redis 最佳作法
• 組態和概念
• 效能測試

StackExchange.Redis 最佳作法

• 將 AbortConnect 設定為 false，然後讓 ConnectionMultiplexer 自動重新連線。
• 使用單一長時間存留的 ConnectionMultiplexer 執行個體，而不針對每個要求建立新的連線。
• Redis 在值越小時運作得最好，因此請考慮將較大的資料切分成多個金鑰。 在 Redis 討論中，100 kb 被視為大型。 如需詳細資訊，請參閱最佳做法開發。
• 設定您的 執行緒集區設定 以避免逾時。
• 使用至少 5 秒的預設 connectTimeout。 此間隔可讓 StackExchange.Redis 在發生網路短暫中斷的情況下，有足夠的時間重新建立連線。
• 請注意與您所執行之不同作業相關聯的效能成本。 例如， KEYS 命令是一種 O(n) 作業，應該盡量避免。 Redis.io 網站 有它支援的每項作業的時間複雜度詳細資訊。 選取每個命令以查看每個作業的複雜度。

組態和概念

• 請記住，Redis 是一種 記憶體內部 資料存放區。 如需詳細資訊，請參閱 針對 Azure 受控 Redis 中的數據遺失進行疑難解答，讓您知道可能發生數據遺失的情況。
• 開發系統，讓系統可以處理因修補和容錯移轉所造成的連線短暫中斷。

效能測試

• 如需在 Azure 受控 Redis 上執行自己的效能測試的基準檢驗和指示，請參閱 使用 Azure 受控 Redis 進行效能測試。

• 針對需要花很長時間才能完成特定 Redis 命令，除非您充分了解這些命令的結果，否則應避免使用這些命令。 例如，請勿在生產環境中執行 KEYS \(英文\) 命令。 視金鑰的數目而定，系統可能需要很長的時間才會傳回。 每個 Redis 分區都是單個線程，而且一次處理一個命令。 如果您在 KEYS 之後還發出其他命令，在 Redis 處理好 KEYS 命令之前，系統將不會處理這些命令。 Redis.io 網站 有它支援的每項作業的時間複雜度詳細資訊。 選取每個命令以查看每個作業的複雜度。
• 索引鍵大小 - 應該使用較小的索引鍵/值還是較大的索引鍵/值？ 這取決於案例。 如果您的案例需要較大的金鑰，您可以調整 ConnectionTimeout，然後重試值並調整重試邏輯。 從 Redis 伺服器的觀點，較小的值即表示有較佳的效能。
• 這些考量不表示您無法在 Redis 中儲存較大的值；您必須注意下列考量。 延遲較高。 如果您的其中一組資料較大，而另外一組較小，您可以使用多個 ConnectionMultiplexer 執行個體。 使用不同組合的逾時和重試值來設定每個值，如先前的 StackExchange.Redis 設定選項的作用為何小節所述。

• 啟用快取診斷，以監視您快取的健全狀況。 您可以在 Azure 入口網站中檢視度量，也可以使用您選擇的工具 下載並檢閱 它們。
• 如需在 Azure 受控 Redis 上執行自己的效能測試的基準檢驗和指示，請參閱 使用 Azure 受控 Redis 進行效能測試。

CLR 執行緒集區有兩種類型的執行緒：「背景工作」和「I/O 完成連接埠」(IOCP) 執行緒。

• 背景工作執行緒是用於處理 Task.Run(…) 或 ThreadPool.QueueUserWorkItem(…) 方法之類的作業。 需要在背景執行緒上開啟工作時，CLR 中的各種元件也會使用這些執行緒。
• 發生非同步 IO (例如從網路讀取) 時，會使用 IOCP 執行緒。

執行緒集區可視需要提供新背景工作執行緒或 I/O 完成執行緒 (而不需要任何節流)，直到它到達每個類型執行緒的「最低」設定。 根據預設，執行緒的數目下限設為系統上的處理器數目。

一旦現有 （忙碌） 線程數目達到線程的「最小」數目，ThreadPool 就會將新線程插入每 500 毫秒的線程速率節流。 一般而言，如果您的系統取得需要IOCP線程的工作高載，它會快速處理該工作。 不過，如果高載超過設定的「最低」設定，部分工作的處理會發生一些延遲，因為 ThreadPool 會等待下列兩種情況之一發生：

• 現有的執行緒變得可用來處理工作。
• 在過去 500 毫秒內沒有現有的執行緒變得可用，且會建立一個新的執行緒。

基本上，當忙碌執行緒數目超過「最低」執行緒數量時，在應用程式處理網路流量之前，您可能需要為 500 毫秒延遲支付費用。 此外，當現有的線程保持閑置超過 15 秒時，就會被清除，而且此成長和壓縮週期可以重複。

如果我們查看來自 StackExchange.Redis (組建 1.0.450 或更新版本) 的範例錯誤訊息，我們會看到其現在會列印 ThreadPool 統計資料。 請參閱下面的 IOCP 和 WORKER 詳細資料。

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

如上述範例所示，您可以看到 IOCP 執行緒有六個忙碌執行緒，而系統設定所允許的最低執行緒為四個。 在此情況下，用戶端會看到兩個 500 毫秒的延遲，因為 6 > 4。

建議

經由這項資訊，我們強烈建議客戶將 IOCP 和背景工作執行緒的「最低」組態值設定成大於預設值的數值。 我們無法針對此值提供一刀切的指引，因為某個應用程式的正確值對於另一個應用程式來說可能太高或太低。 此設定也會影響複雜應用程式其他部分的效能，因此每位客戶需要微調此設定來滿足其特定需求。 200 或 300 是好的起點，那麼請測試並視需要調整。

如何設定這項設定：

• 建議使用 global.asax.cs 中的 ThreadPool.SetMinThreads (...) 方法，以程式設計方式變更這項設定。 例如：

  private readonly int minThreads = 200;
  void Application_Start(object sender, EventArgs e)
  {
      // Code that runs on application startup
      AreaRegistration.RegisterAllAreas();
      RouteConfig.RegisterRoutes(RouteTable.Routes);
      BundleConfig.RegisterBundles(BundleTable.Bundles);
      ThreadPool.SetMinThreads(minThreads, minThreads);
  }
  

  注意

  此方法指定的值是全域設定，會影響整個 AppDomain。 例如，如果您有一部具有四個核心的計算機，而且想要在運行時間將minWorkerThreads和minIoThreads設為每個CPU 50，請使用 ThreadPool.SetMinThreads（200， 200）。

• 您也可以使用 中的組態專案Machine.config下的 <processModel> minIoThreads或minWorkerThreads組態設定來指定最小線程設定。 Machine.config 通常位於 %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\。 我們不建議以這種方式設定最低執行緒數，因為其為全系統設定。

  注意

  這個組態元素中指定的值是「每一核心」設定。 例如，如果您有一部具有四個核心的計算機，而且希望 您的minIoThreads 設定在執行時間是200，您會使用 <processModel minIoThreads="50"/>。

啟用伺服器 GC 可以最佳化用戶端，並在使用 StackExchange.Redis 時提供較佳的效能和輸送量。 如需有關伺服器 GC，以及如何加以啟用的詳細資訊，請參閱下列文件：

• 啟用伺服器 GC
• 記憶體回收的基本概念
• Garbage Collection and Performance (記憶體回收與效能)

不同的 SKU 對於用戶端連線、記憶體和頻寬可能會有不同的限制。 雖然每個快取大小都可允許以某個數目為「上限」的連線數，但是針對 Redis 所進行的每個連線都會有相關聯的額外負荷。 此類額外負荷的其中一個範例，是因 TLS/SSL 加密而產生的 CPU 與記憶體使用量。 所指定快取大小的連線數上限是假設快取負載情況為輕度。 如果從連線額外負荷載入加上用戶端作業的負載超過系統的容量，即使您未超過目前快取大小的連線限制，快取仍可能會遇到容量問題。

如需每個層不同連線限制的詳細資訊，請參閱 Azure 受控 Redis 定價。 如需有關連線及其他預設組態的詳細資訊，請參閱預設 Redis 伺服器組態。

下一步

瞭解其他 Azure 受控 Redis 常見問題。