緩存管理常見問題解答

此文章提供有關如何管理 Azure Cache for Redis 之常見問題的解答。

這很重要

Azure Cache for Redis 宣布了所有 SKU 的淘汰時間表。 建議您儘快將現有的 Azure Cache for Redis 執行個體移至 Azure 受控 Redis 。

有關退役的更詳細資訊：

• Azure Cache for Redis 退休：注意事項及如何準備
• Azure Cache for Redis 停用常見問答

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

• 用於 redis-benchmark.exe 對 Redis 伺服器進行負載測試。 用於 redis-benchmark.exe 在編寫自己的性能測試之前瞭解可能的輸送量。
• 用於 redis-cli 使用 INFO 命令監視緩存。 有關下載 Redis 工具的說明，請參閱 如何運行 Redis 命令？
• 如果您在緩存實例上使用傳輸層安全性/安全套接字層 （TLS/SSL），請將該參數添加到您的 --tls Redis 工具命令中，或使用代理來 stunnel 啟用 TLS/SSL。
• Redis-benchmark 預設使用 Port 6379 。 -p如果您的快取使用 SSL/TLS 連接埠6380或 Enterprise tier 連接埠10000，請使用該參數覆蓋此設置。
• 如有必要，可以在運行負載測試之前 通過 Azure 門戶啟用非 TLS 埠 。
• 確保用於測試的用戶端虛擬機 （VM） 與 Azure Cache for Redis 實例位於同一區域。
• 確保您的用戶端 VM 至少具有與您正在測試的緩存一樣多的計算和頻寬功能。 為獲得最佳結果，請為用戶端使用 D 系列和 E 系列 VM。
• 如果您使用的是 Windows，請在用戶端電腦上啟用虛擬接收端縮放 （VRSS）。 有關詳細資訊，請參閱 Windows Server 2012 R2 中的虛擬接收端縮放。
• 啟用快取診斷，以便您可以 監控 緩存的運行狀況。 可以在 Azure 門戶中查看指標，還可以使用所選工具 下載和查看指標 。
• 如果您的負載導致高記憶體碎片，請縱向擴展到更大的緩存大小。

以下範例顯示如何使用 redis-benchmark.exe. 從與緩存位於同一區域的 VM 運行這些命令，以獲得準確的結果。

首先，使用 1k 有效負載測試管道請求 SET ：

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t SET -n 1000000 -d 1024 -P 50

運行 SET 測試后，使用 1k 有效負載運行管道請求 GET ：

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t GET -n 1000000 -d 1024 -P 50

使用 StackExchange.Redis 時，如何啟用伺服器 GC 以在用戶端上獲得更多輸送量？

啟用伺服器垃圾回收 （GC） 可以優化用戶端，並在使用 StackExchange.Redis 時提供更好的性能和輸送量。 如需有關伺服器 GC，以及如何加以啟用的詳細資訊，請參閱下列文件：

• <gcServer> 元素
• 垃圾回收的基礎知識
• 垃圾回收和性能

我是否應該啟用非 TLS/SSL 埠來連接到 Redis？

Redis 伺服器本身不支援傳輸層安全性 （TLS），但 Azure Cache for Redis 支援 TLS。 如果使用支援 TLS 的用戶端（如 StackExchange.Redis）連接到 Azure Cache for Redis，請使用 TLS。

注意

默認情況下，新的 Azure Redis 實例的非 TLS 埠處於禁用狀態。 如果您的用戶端不支援 TLS，請按照 訪問埠中的說明啟用非 TLS 連接埠。

如果快取使用 TLS，則必須使用 --tls Redis 工具的選項啟用 TLS，例如 redis-cli. 您還可以使用實用程式，例如 stunnel 按照 宣佈為 Redis 預覽版提供 ASP.NET 工作階段狀態提供程式 部落格文章中的說明將工具安全地連接到 TLS 連接埠。

有關下載 Redis 工具的說明，請參閱 如何運行 Redis 命令？

使用常見的 Redis 命令有哪些注意事項？

• 針對需要花很長時間才能完成特定 Redis 命令，除非您充分了解這些命令的結果，否則應避免使用這些命令。 例如，請勿在生產環境中執行 KEYS \(英文\) 命令。 視金鑰的數目而定，系統可能需要很長的時間才會傳回。 Redis 是一個單線程伺服器，一次處理一個命令。 如果您發出該 KEYS 命令，Redis 在完成命令處理 KEYS 之前不會處理後續命令。

  redis.io 網站具有它支援的每個作的時間複雜性詳細資訊。 選取每個命令以查看每個作業的複雜度。

• 使用的大小鍵取決於方案。 如果您的方案需要更大的鍵，您可以調整 ConnectionTimeout，然後重試值並調整重試邏輯。 從 Redis 伺服器的角度來看，較小的鍵值會提供更好的性能。

• 這些注意事項並不意味著您不能在 Redis 中存儲更大的值，但延遲更高。 如果您有一組大於另一組數據，則可以使用多個 ConnectionMultiplexer 實例，每個實例都配置了一組不同的超時和重試值。 有關更多資訊，請參閱 StackExchange.Redis 配置選項有什麼作用？

連接有哪些性能注意事項？

每個 Azure Cache for Redis 定價層對用戶端連接、記憶體和頻寬都有不同的限制。 雖然每種大小的 緩存最多允許 一定數量的連接，但與 Redis 的每個連接都涉及相關的開銷。 此類開銷的一個示例是由於 TLS/SSL 加密而導致的 CPU 和記憶體使用。

所指定快取大小的連線數上限是假設快取負載情況為輕度。 如果連接開銷的負載 加上 用戶端作的負載超過系統的容量，則即使您沒有超過當前緩存大小的連接限制，緩存也可能會遇到容量問題。

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

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

• 將 Standard 或 Premium 層用於生產系統。 基本套餐是一個單節點系統，沒有數據複製，也沒有服務等級協定 （SLA）。 此外，至少為 Production 使用 C1 快取。 C0 快取通常用於簡單的開發/測試案例。
• 請注意，Redis 是 記憶體中 數據存儲，在某些情況下可能會發生數據丟失。 有關詳細資訊，請參閱 排查 Azure Cache for Redis 中的數據丟失問題。
• 開發您的系統，使其能夠處理由 修補和故障轉移引起的連接故障。
• 使用高級層 Azure Redis 實例可獲得更好的網路延遲和輸送量，因為它們具有更好的 CPU 和網路硬體。

StackExchange.Redis 最佳作法

• 設置為 AbortConnect false，然後讓 自動 ConnectionMultiplexer 重新連接。
• 使用單一長時間存留的 ConnectionMultiplexer 執行個體，而不針對每個要求建立新的連線。
• Redis 在值越小時運作得最好，因此請考慮將較大的資料切分成多個金鑰。 例如，在 What is the ideal value size range for redis？（什麼是 redis 的理想值大小範圍？）中，100 kb 被視為較大。 有關更多資訊，請參閱 考慮更多鍵和更小的值。
• 設定您的 執行緒集區設定 以避免逾時。
• 至少使用預設值 connectTimeout 5 秒。 如果存在網路故障，此間隔為 StackExchange.Redis 提供了足夠的時間來重新建立連接。
• 請注意與您運行的不同作相關的性能成本。 例如， KEYS 命令是一種 O(n) 作業，應該盡量避免。 redis.io 網站包含有關它支援的每個作的時間複雜度的詳細資訊。 選取每個命令以查看每個作業的複雜度。

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

公共語言運行時 （CLR） ThreadPool 有兩種類型的線程：工作線程和 I/O 完成埠 （IOCP）。

• WORKER threads 用於處理 Task.Run(…)、 或 ThreadPool.QueueUserWorkItem(…) 方法等作。 當需要在後台線程上進行工作時，CLR 中的各種元件也會使用這些線程。
• IOCP 線程用於異步 I/O，例如從網路讀取時。

線程池按需提供新的工作線程或 I/O 完成線程，在達到 minimum 每種類型線程的設置之前，不會進行任何限制。 根據預設，執行緒的數目下限設為系統上的處理器數目。

一旦現有繁忙線程的數量達到線程數， minimum ThreadPool 就會限制每 500 毫秒向一個線程注入新線程的速率。

通常，如果您的系統獲得需要線程的 IOCP 突發工作，它會快速處理該工作。 但是，如果突發大於配置的 minimum 設置，則處理某些工作會有一些延遲，因為 ThreadPool 會等待以下兩種可能性之一：

• 現有的執行緒變得可用來處理工作。
• 在 500 毫秒內沒有現有線程變為空閒狀態，因此會創建一個新線程。

基本上，當線程數 Busy 大於 Min 線程數時，在應用程式處理網路流量之前，您會遇到 500 毫秒的延遲。 此外，空閒時間超過15秒的現有線程將被清理，並且這種增長和收縮的迴圈可以重複。

來自 StackExchange.Redis 內部版本 1.0.450 或更高版本的錯誤消息會列印 ThreadPool 統計資訊，如以下示例所示。

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 線程，有6個繁忙線程，並且系統配置為允許最少4個線程。 在這種情況下，用戶端可能會看到兩個 500 毫秒的延遲，因為 6 > 4.

注意

如果 或 IOCP 線程的增長WORKER受到限制，StackExchange.Redis 可能會達到超時。

最好將 和 IOCP threads 的最小配置值WORKER設置為大於預設值的值。 對於此值，沒有萬能的指導，因為一個應用程式的正確值對於另一個應用程式來說可能太高或太低。 此設置還會影響複雜應用程式的其他部分的性能。 您需要根據自己的特定需求微調此設置。 一個好的起點是 200 or 300。 然後根據需要進行測試和調整。

配置最小線程數設置

您可以使用 ThreadPool.SetMinThreads （...） 方法以程式設計方式更改此設置。

例如，在 NET Framework 中，在方法中以 Application_Start 設置此值：

    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，請在調用 WebApplication.CreateBuilder() 之前將值設定為：

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

注意

此方法指定的值是影響整個AppDomain的全域設置。 例如，如果您有一個四核 VM，並且希望在運行時將每個 CPU 設置為 minWorkerThreadsminIoThreads 50，請使用 ThreadPool.SetMinThreads(200, 200).

還可以使用 minIoThreads中 configuration 元素下的 minWorkerThreads or <processModel>來指定最小線程數設置。Machine.config 通常位於 %SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\。

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

注意

此方法指定的值是 每個內核 的設置。 例如，如果您有一台四核計算機，並且希望在運行時將 minIoThreads 設置為 200，請使用 <processModel minIoThreads="50">.

相關內容

• 請參閱其他 Azure Cache for Redis 常見問題解答。

此文章提供有關如何管理 Azure Cache for Redis 之常見問題的解答。

這很重要

Azure Cache for Redis 宣布了所有 SKU 的淘汰時間表。 建議您儘快將現有的 Azure Cache for Redis 執行個體移至 Azure 受控 Redis 。

有關退役的更詳細資訊：

• Azure Cache for Redis 退休：注意事項及如何準備
• Azure Cache for Redis 停用常見問答

• 用於 redis-benchmark.exe 對 Redis 伺服器進行負載測試。 用於 redis-benchmark.exe 在編寫自己的性能測試之前瞭解可能的輸送量。
• 用於 redis-cli 使用 INFO 命令監視緩存。 有關下載 Redis 工具的說明，請參閱 如何運行 Redis 命令？
• 如果您在緩存實例上使用傳輸層安全性/安全套接字層 （TLS/SSL），請將該參數添加到您的 --tls Redis 工具命令中，或使用代理來 stunnel 啟用 TLS/SSL。
• Redis-benchmark 預設使用 Port 6379 。 -p如果您的快取使用 SSL/TLS 連接埠6380或 Enterprise tier 連接埠10000，請使用該參數覆蓋此設置。
• 如有必要，可以在運行負載測試之前 通過 Azure 門戶啟用非 TLS 埠 。
• 確保用於測試的用戶端虛擬機 （VM） 與 Azure Cache for Redis 實例位於同一區域。
• 確保您的用戶端 VM 至少具有與您正在測試的緩存一樣多的計算和頻寬功能。 為獲得最佳結果，請為用戶端使用 D 系列和 E 系列 VM。
• 如果您使用的是 Windows，請在用戶端電腦上啟用虛擬接收端縮放 （VRSS）。 有關詳細資訊，請參閱 Windows Server 2012 R2 中的虛擬接收端縮放。
• 啟用快取診斷，以便您可以 監控 緩存的運行狀況。 可以在 Azure 門戶中查看指標，還可以使用所選工具 下載和查看指標 。
• 如果您的負載導致高記憶體碎片，請縱向擴展到更大的緩存大小。

以下範例顯示如何使用 redis-benchmark.exe. 從與緩存位於同一區域的 VM 運行這些命令，以獲得準確的結果。

首先，使用 1k 有效負載測試管道請求 SET ：

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t SET -n 1000000 -d 1024 -P 50

運行 SET 測試后，使用 1k 有效負載運行管道請求 GET ：

redis-benchmark.exe -h <yourcache>.redis.cache.windows.net -a <yourAccesskey> -t GET -n 1000000 -d 1024 -P 50

啟用伺服器垃圾回收 （GC） 可以優化用戶端，並在使用 StackExchange.Redis 時提供更好的性能和輸送量。 如需有關伺服器 GC，以及如何加以啟用的詳細資訊，請參閱下列文件：

• <gcServer> 元素
• 垃圾回收的基礎知識
• 垃圾回收和性能

Redis 伺服器本身不支援傳輸層安全性 （TLS），但 Azure Cache for Redis 支援 TLS。 如果使用支援 TLS 的用戶端（如 StackExchange.Redis）連接到 Azure Cache for Redis，請使用 TLS。

注意

默認情況下，新的 Azure Redis 實例的非 TLS 埠處於禁用狀態。 如果您的用戶端不支援 TLS，請按照 訪問埠中的說明啟用非 TLS 連接埠。

如果快取使用 TLS，則必須使用 --tls Redis 工具的選項啟用 TLS，例如 redis-cli. 您還可以使用實用程式，例如 stunnel 按照 宣佈為 Redis 預覽版提供 ASP.NET 工作階段狀態提供程式 部落格文章中的說明將工具安全地連接到 TLS 連接埠。

有關下載 Redis 工具的說明，請參閱 如何運行 Redis 命令？

• 針對需要花很長時間才能完成特定 Redis 命令，除非您充分了解這些命令的結果，否則應避免使用這些命令。 例如，請勿在生產環境中執行 KEYS \(英文\) 命令。 視金鑰的數目而定，系統可能需要很長的時間才會傳回。 Redis 是一個單線程伺服器，一次處理一個命令。 如果您發出該 KEYS 命令，Redis 在完成命令處理 KEYS 之前不會處理後續命令。

  redis.io 網站具有它支援的每個作的時間複雜性詳細資訊。 選取每個命令以查看每個作業的複雜度。

• 使用的大小鍵取決於方案。 如果您的方案需要更大的鍵，您可以調整 ConnectionTimeout，然後重試值並調整重試邏輯。 從 Redis 伺服器的角度來看，較小的鍵值會提供更好的性能。

• 這些注意事項並不意味著您不能在 Redis 中存儲更大的值，但延遲更高。 如果您有一組大於另一組數據，則可以使用多個 ConnectionMultiplexer 實例，每個實例都配置了一組不同的超時和重試值。 有關更多資訊，請參閱 StackExchange.Redis 配置選項有什麼作用？

每個 Azure Cache for Redis 定價層對用戶端連接、記憶體和頻寬都有不同的限制。 雖然每種大小的 緩存最多允許 一定數量的連接，但與 Redis 的每個連接都涉及相關的開銷。 此類開銷的一個示例是由於 TLS/SSL 加密而導致的 CPU 和記憶體使用。

所指定快取大小的連線數上限是假設快取負載情況為輕度。 如果連接開銷的負載 加上 用戶端作的負載超過系統的容量，則即使您沒有超過當前緩存大小的連接限制，緩存也可能會遇到容量問題。

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

• 將 Standard 或 Premium 層用於生產系統。 基本套餐是一個單節點系統，沒有數據複製，也沒有服務等級協定 （SLA）。 此外，至少為 Production 使用 C1 快取。 C0 快取通常用於簡單的開發/測試案例。
• 請注意，Redis 是 記憶體中 數據存儲，在某些情況下可能會發生數據丟失。 有關詳細資訊，請參閱 排查 Azure Cache for Redis 中的數據丟失問題。
• 開發您的系統，使其能夠處理由 修補和故障轉移引起的連接故障。
• 使用高級層 Azure Redis 實例可獲得更好的網路延遲和輸送量，因為它們具有更好的 CPU 和網路硬體。

StackExchange.Redis 最佳作法

• 設置為 AbortConnect false，然後讓 自動 ConnectionMultiplexer 重新連接。
• 使用單一長時間存留的 ConnectionMultiplexer 執行個體，而不針對每個要求建立新的連線。
• Redis 在值越小時運作得最好，因此請考慮將較大的資料切分成多個金鑰。 例如，在 What is the ideal value size range for redis？（什麼是 redis 的理想值大小範圍？）中，100 kb 被視為較大。 有關更多資訊，請參閱 考慮更多鍵和更小的值。
• 設定您的 執行緒集區設定 以避免逾時。
• 至少使用預設值 connectTimeout 5 秒。 如果存在網路故障，此間隔為 StackExchange.Redis 提供了足夠的時間來重新建立連接。
• 請注意與您運行的不同作相關的性能成本。 例如， KEYS 命令是一種 O(n) 作業，應該盡量避免。 redis.io 網站包含有關它支援的每個作的時間複雜度的詳細資訊。 選取每個命令以查看每個作業的複雜度。

公共語言運行時 （CLR） ThreadPool 有兩種類型的線程：工作線程和 I/O 完成埠 （IOCP）。

• WORKER threads 用於處理 Task.Run(…)、 或 ThreadPool.QueueUserWorkItem(…) 方法等作。 當需要在後台線程上進行工作時，CLR 中的各種元件也會使用這些線程。
• IOCP 線程用於異步 I/O，例如從網路讀取時。

線程池按需提供新的工作線程或 I/O 完成線程，在達到 minimum 每種類型線程的設置之前，不會進行任何限制。 根據預設，執行緒的數目下限設為系統上的處理器數目。

一旦現有繁忙線程的數量達到線程數， minimum ThreadPool 就會限制每 500 毫秒向一個線程注入新線程的速率。

通常，如果您的系統獲得需要線程的 IOCP 突發工作，它會快速處理該工作。 但是，如果突發大於配置的 minimum 設置，則處理某些工作會有一些延遲，因為 ThreadPool 會等待以下兩種可能性之一：

• 現有的執行緒變得可用來處理工作。
• 在 500 毫秒內沒有現有線程變為空閒狀態，因此會創建一個新線程。

基本上，當線程數 Busy 大於 Min 線程數時，在應用程式處理網路流量之前，您會遇到 500 毫秒的延遲。 此外，空閒時間超過15秒的現有線程將被清理，並且這種增長和收縮的迴圈可以重複。

來自 StackExchange.Redis 內部版本 1.0.450 或更高版本的錯誤消息會列印 ThreadPool 統計資訊，如以下示例所示。

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 線程，有6個繁忙線程，並且系統配置為允許最少4個線程。 在這種情況下，用戶端可能會看到兩個 500 毫秒的延遲，因為 6 > 4.

注意

如果 或 IOCP 線程的增長WORKER受到限制，StackExchange.Redis 可能會達到超時。

最好將 和 IOCP threads 的最小配置值WORKER設置為大於預設值的值。 對於此值，沒有萬能的指導，因為一個應用程式的正確值對於另一個應用程式來說可能太高或太低。 此設置還會影響複雜應用程式的其他部分的性能。 您需要根據自己的特定需求微調此設置。 一個好的起點是 200 or 300。 然後根據需要進行測試和調整。

配置最小線程數設置

您可以使用 ThreadPool.SetMinThreads （...） 方法以程式設計方式更改此設置。

例如，在 NET Framework 中，在方法中以 Application_Start 設置此值：

    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，請在調用 WebApplication.CreateBuilder() 之前將值設定為：

    const int minThreads = 200
                  
    ThreadPool.SetMinThreads(minThreads, minThreads);
    
    var builder = WebApplication.CreateBuilder(args);
    // rest of application setup

注意

此方法指定的值是影響整個AppDomain的全域設置。 例如，如果您有一個四核 VM，並且希望在運行時將每個 CPU 設置為 minWorkerThreadsminIoThreads 50，請使用 ThreadPool.SetMinThreads(200, 200).

還可以使用 minIoThreads中 configuration 元素下的 minWorkerThreads or <processModel>來指定最小線程數設置。Machine.config 通常位於 %SystemRoot%\Microsoft.NET\Framework\<versionNumber>\CONFIG\。

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

注意

此方法指定的值是 每個內核 的設置。 例如，如果您有一台四核計算機，並且希望在運行時將 minIoThreads 設置為 200，請使用 <processModel minIoThreads="50">.

相關內容

• 請參閱其他 Azure Cache for Redis 常見問題解答。