Azure 受控 Redis 管理常見問題

本文提供如何管理 Azure 受控 Redis 的常見問題解答。

何時應該啟用非 TLS/SSL 連接埠來連線至 Redis？

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

生產環境的最佳作法有哪些？

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

StackExchange.Redis 最佳作法

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

組態和概念

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

效能測試

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

使用常見 Redis 命令時的一些考量為何？

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

如何效能評定和測試我快取的效能？

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

執行緒集區成長的重要詳細資料

CLR ThreadPool 有兩種類型的線程 - 背景工作 角色和 I/O 完成埠 （IOCP） 線程。

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

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

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

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

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

如果我們查看來自 StackExchange.Redis (組建 1.0.450 或更新版本) 的範例錯誤訊息，我們會看到其現在會列印 ThreadPool 統計資料。 請參閱本文稍後的IOCP和背景工作角色詳細數據。

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 或 WORKER 執行緒的成長發生節流，StackExchange.Redis 可能會發生逾時。

建議

我們建議客戶將IOCP和WORKER線程的最小組態值設定為大於預設值的值。 我們無法針對此值提供一刀切的指引，因為某個應用程式的正確值對於另一個應用程式來說可能太高或太低。 此設置還會影響複雜應用程式的其他部分的性能。 每位客戶都必須微調此設定，以符合其特定需求。 200 或 300 是好的起點，那麼請測試並視需要調整。

如何設定這項設定：

建議您在 .NET Framework 和 .NET Core 應用程式中使用 ThreadPool.SetMinThreads （...） 方法來以程式設計方式變更此設定。

例如，在 NET Framework 中，您會在 方法中Global.asax.csApplication_Start設定它：

```csharp
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);
}
```

如果您使用 .NET Core，請在 呼叫 Program.cs之前將它設定為 WebApplication.CreateBuilder()：

```csharp
const int minThreads = 200
              
ThreadPool.SetMinThreads(minThreads, minThreads);

var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```

備註

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

您也可以使用 minIoThreads 中的 minWorkerThreads組態專案下的 或 <processModel> 組Machine.config來指定最小線程設定。 Machine.config 通常位於 %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\。

不建議以這種方式設置最小線程數，因為這是系統範圍的設置。 如果您以這種方式設定，則必須重新啟動應用程式集區。

備註

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

使用 StackExchange.Redis 時啟用伺服器 GC 在用戶端上取得更多輸送量

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

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

連線相關的效能考量

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

如需每個層不同連線限制的詳細資訊，請參閱 Azure 受控 Redis 定價。

相關內容

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

本文提供如何管理 Azure 受控 Redis 的常見問題解答。

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

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

StackExchange.Redis 最佳作法

• 將 AbortConnect 設定為 false，然後讓 ConnectionMultiplexer 自動重新連線。
• 使用單一長時間存留的 ConnectionMultiplexer 執行個體，而不針對每個要求建立新的連線。
• Redis 在值越小時運作得最好，因此請考慮將較大的資料切分成多個金鑰。 在 Redis 討論中，100 kb 被視為大型。 如需詳細資訊，請參閱最佳做法開發。
• 設定 您的 ThreadPool 設定 ，以避免逾時。
• 使用至少 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 ThreadPool 有兩種類型的線程 - 背景工作 角色和 I/O 完成埠 （IOCP） 線程。

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

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

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

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

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

如果我們查看來自 StackExchange.Redis (組建 1.0.450 或更新版本) 的範例錯誤訊息，我們會看到其現在會列印 ThreadPool 統計資料。 請參閱本文稍後的IOCP和背景工作角色詳細數據。

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 或 WORKER 執行緒的成長發生節流，StackExchange.Redis 可能會發生逾時。

建議

我們建議客戶將IOCP和WORKER線程的最小組態值設定為大於預設值的值。 我們無法針對此值提供一刀切的指引，因為某個應用程式的正確值對於另一個應用程式來說可能太高或太低。 此設置還會影響複雜應用程式的其他部分的性能。 每位客戶都必須微調此設定，以符合其特定需求。 200 或 300 是好的起點，那麼請測試並視需要調整。

如何設定這項設定：

建議您在 .NET Framework 和 .NET Core 應用程式中使用 ThreadPool.SetMinThreads （...） 方法來以程式設計方式變更此設定。

例如，在 NET Framework 中，您會在 方法中Global.asax.csApplication_Start設定它：

```csharp
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);
}
```

如果您使用 .NET Core，請在 呼叫 Program.cs之前將它設定為 WebApplication.CreateBuilder()：

```csharp
const int minThreads = 200
              
ThreadPool.SetMinThreads(minThreads, minThreads);

var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```

備註

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

您也可以使用 minIoThreads 中的 minWorkerThreads組態專案下的 或 <processModel> 組Machine.config來指定最小線程設定。 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 定價。

相關內容

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