您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

Azure Redis 缓存常见问题Azure Redis Cache FAQ

了解常见问题的答案,以及有关 Azure Redis 缓存的模式和最佳实践。Learn the answers to common questions, patterns, and best practices for Azure Redis Cache.

如果未在此处找到相关问题怎么办?What if my question isn't answered here?

如果未在此处找到相关问题,请联系我们获取帮助。If your question isn't listed here, let us know and we'll help you find an answer.

  • 可在此常见问题解答末尾的评论处发布问题,并与 Azure 缓存团队和其他社区成员就本文进行讨论。You can post a question in the comments at the end of this FAQ and engage with the Azure Cache team and other community members about this article.
  • 若希望更多的人看到问题,可以将问题发布在 Azure Cache MSDN Forum(Azure 缓存 MSDN 论坛)并与 Azure 缓存团队和社区的其他成员讨论。To reach a wider audience, you can post a question on the Azure Cache MSDN Forum and engage with the Azure Cache team and other members of the community.
  • 如果想要发出功能请求,可将请求和意见提交到 Azure Redis Cache User Voice(Azure Redis 缓存用户之声)。If you want to make a feature request, you can submit your requests and ideas to Azure Redis Cache User Voice.
  • 还可通过 Azure 缓存外部反馈向我们发送电子邮件。You can also send an email to us at Azure Cache External Feedback.

Azure Redis 缓存基础知识Azure Redis Cache basics

本部分中的常见问题解答介绍了 Azure Redis 缓存的一些基础知识。The FAQs in this section cover some of the basics of Azure Redis Cache.

下面的常见问题解答介绍了有关 Azure Redis 缓存的基本概念和问题,并在另一个常见问题解答部分列出了相应回答。The following FAQs cover basic concepts and questions about Azure Redis Cache and are answered in one of the other FAQ sections.

规划常见问题Planning FAQs

开发常见问题Development FAQs

安全常见问题Security FAQs

生产常见问题Production FAQs

监视和故障排除常见问题Monitoring and troubleshooting FAQs

本部分中的常见问题包括常见的监视和故障排除问题。The FAQs in this section cover common monitoring and troubleshooting questions. 有关 Azure Redis 缓存实例监视和故障排除的详细信息,请参阅 How to monitor Azure Redis Cache(如何监视 Azure Redis 缓存)以及 How to troubleshoot Azure Redis Cache(如何排查 Azure Redis 缓存问题)。For more information about monitoring and troubleshooting your Azure Redis Cache instances, see How to monitor Azure Redis Cache and How to troubleshoot Azure Redis Cache.

有关之前缓存产品的常见问题Prior Cache offering FAQs

什么是 Azure Redis 缓存?What is Azure Redis Cache?

Azure Redis 缓存基于流行的开放源代码 Redis 缓存Azure Redis Cache is based on the popular open-source Redis cache. 这使用户可以访问安全、专用的 Redis 缓存,该缓存由 Microsoft 托管并可从 Azure 内的任何应用程序进行访问。It gives you access to a secure, dedicated Redis cache, managed by Microsoft, and accessible from any application within Azure. 有关更详细的概述,请参阅 Azure.com 上的 Azure Redis 缓存产品页。For a more detailed overview, see the Azure Redis Cache product page on Azure.com.

使用 Azure Redis 缓存?How can I get started with Azure Redis Cache?

有几种使用 Azure Redis 缓存的方法。There are several ways you can get started with Azure Redis Cache.

如果还没有 Azure 帐户,则可以:If you don't already have an Azure account, you can:

应使用哪种 Redis 缓存产品和大小?What Redis Cache offering and size should I use?

每个 Azure Redis 缓存产品/服务提供不同级别的大小带宽高可用性SLA 选项。Each Azure Redis Cache offering provides different levels of size, bandwidth, high availability, and SLA options.

以下是有关选择缓存产品的注意事项。The following are considerations for choosing a Cache offering.

  • 内存:基本级别和标准级别提供 250 MB - 53 GB。Memory: The Basic and Standard tiers offer 250 MB – 53 GB. 高级层最多提供 530 GB。The Premium tier offers up to 530 GB. 有关详细信息,请参阅 Azure Redis 缓存定价For more information, see Azure Redis Cache Pricing.
  • 网络性能:如果工作负荷需要较高的吞吐量,则可使用高级层,该层可提供比标准层或基本层更高的带宽。Network Performance: If you have a workload that requires high throughput, the Premium tier offers more bandwidth compared to Standard or Basic. 另外,因为基础 VM 托管着缓存,所以,在每个级别中,缓存大小越大,则带宽越高。Also within each tier, larger size caches have more bandwidth because of the underlying VM that hosts the cache. 有关详细信息,请参阅下表See the following table for more information.
  • 吞吐量:高级级别提供的可用吞吐量最大。Throughput: The Premium tier offers the maximum available throughput. 如果缓存服务器或客户端达到带宽限制,则客户端上可能出现超时。If the cache server or client reaches the bandwidth limits, you may receive timeouts on the client side. 有关详细信息,请参阅下表。For more information, see the following table.
  • 高可用性/SLA:Azure Redis 缓存保证标准/高级缓存在至少 99.9% 的时间内都可用。High Availability/SLA: Azure Redis Cache guarantees that a Standard/Premium cache is available at least 99.9% of the time. 若要了解有关 SLA 的详细信息,请参阅 Azure Redis 缓存定价To learn more about our SLA, see Azure Redis Cache Pricing. SLA 仅涉及与缓存终结点的连接。The SLA only covers connectivity to the Cache endpoints. SLA 不涉及对数据丢失的防护。The SLA does not cover protection from data loss. 我们建议使用高级级别中的 Redis 数据暂留功能来增加灵活性,防止数据丢失。We recommend using the Redis data persistence feature in the Premium tier to increase resiliency against data loss.
  • Redis 数据持久性:高级级别允许将缓存数据暂留在 Azure 存储帐户中。Redis Data Persistence: The Premium tier allows you to persist the cache data in an Azure Storage account. 在基本/标准缓存中,所有数据都只存储在内存中。In a Basic/Standard cache, all the data is stored only in memory. 如果底层基础结构出现问题,可能会导致数据丢失。If there are underlying infrastructure issues there can be potential data loss. 我们建议使用高级级别中的 Redis 数据暂留功能来增加灵活性,防止数据丢失。We recommend using the Redis data persistence feature in the Premium tier to increase resiliency against data loss. Azure Redis 缓存提供可在 Redis 暂留中使用的 RDB 和 AOF(即将推出)选项。Azure Redis Cache offers RDB and AOF (coming soon) options in Redis persistence. 有关详细信息,请参阅如何为高级 Azure Redis 缓存配置持久性For more information, see How to configure persistence for a Premium Azure Redis Cache.
  • Redis 缓存:要创建大于 53 GB 的缓存,或要将数据通过分片的方式分散到多个 Redis 节点中,可以使用在高级级别中包含的 Redis 群集功能。Redis Cluster: To create caches larger than 53 GB, or to shard data across multiple Redis nodes, you can use Redis clustering, which is available in the Premium tier. 每个节点都包含一个主/副缓存对,目的是提高可用性。Each node consists of a primary/replica cache pair for high availability. 有关详细信息,请参阅 如何为高级 Azure Redis 缓存配置群集功能For more information, see How to configure clustering for a Premium Azure Redis Cache.
  • 增强的安全性和独立性:Azure 虚拟网络 (VNET) 部署为 Azure Redis 缓存提供增强的安全性和隔离性,并提供子网、访问控制策略和进一步限制访问的其他功能。Enhanced security and network isolation: Azure Virtual Network (VNET) deployment provides enhanced security and isolation for your Azure Redis Cache, as well as subnets, access control policies, and other features to further restrict access. 有关详细信息,请参阅 如何为高级 Azure Redis 缓存配置虚拟网络支持For more information, see How to configure Virtual Network support for a Premium Azure Redis Cache.
  • 配置 Redis:在标准级别和高级级别,都可以针对 Keyspace 通知来配置 Redis。Configure Redis: In both the Standard and Premium tiers, you can configure Redis for Keyspace notifications.
  • 客户端连接的最大数量:高级级别提供的可以连接到 Redis 的客户端数量是最大的,缓存大小越大,连接数量越大。Maximum number of client connections: The Premium tier offers the maximum number of clients that can connect to Redis, with a higher number of connections for larger sized caches. 群集不会增加可用于群集缓存的连接数。Clustering does not increase the number of connections available for a clustered cache. 有关详细信息,请参阅 Azure Redis 缓存定价For more information, see Azure Redis Cache pricing.
  • 专用 Redis 服务器核心:高级级别的所有缓存大小都有针对 Redis 的专用核心。Dedicated Core for Redis Server: In the Premium tier, all cache sizes have a dedicated core for Redis. 在基本层/标准层,C1 大小及以上有针对 Redis 服务器的专用核心。In the Basic/Standard tiers, the C1 size and above have a dedicated core for Redis server.
  • Redis 是单线程的,因此与仅使用两个内核相比,使用两个以上的内核并没有额外的优势,但大型 VM 通常提供比小型 VM 更高的带宽。Redis is single-threaded so having more than two cores does not provide additional benefit over having just two cores, but larger VM sizes typically have more bandwidth than smaller sizes. 如果缓存服务器或客户端达到带宽限制,则客户端上会出现超时。If the cache server or client reaches the bandwidth limits, then you receive timeouts on the client side.
  • 性能改进:高级层中的缓存部署在处理器速度更快的硬件上,可提供比基本层或标准层更好的性能。Performance improvements: Caches in the Premium tier are deployed on hardware that has faster processors, giving better performance compared to the Basic or Standard tier. 高级级别缓存的吞吐量更高,延迟更低。Premium tier Caches have higher throughput and lower latencies.

Azure Redis 缓存性能Azure Redis Cache performance

下表显示了在 Iaas VM 中使用 redis-benchmark.exe 针对 Azure Redis 缓存终结点测试各种大小的标准缓存和高级缓存时,所观测到的最大带宽值。The following table shows the maximum bandwidth values observed while testing various sizes of Standard and Premium caches using redis-benchmark.exe from an Iaas VM against the Azure Redis Cache endpoint. 对于 SSL 吞吐量,将 redis 基准用于 stunnel 以连接到 Azure Redis 缓存终结点。For SSL throughput, redis-benchmark is used with stunnel to connect to the Azure Redis Cache endpoint.


这些值是没有保证的,并且不存在针对这些数字的 SLA,但它们反映了典型的情况。These values are not guaranteed and there is no SLA for these numbers, but should be typical. 应该对自己的应用程序进行负载测试,以确定适合应用程序的缓存大小。You should load test your own application to determine the right cache size for your application. 因为我们会定期发布更新结果,这些数字可能会更改。These numbers might change as we post newer results periodically.

我们可以根据此表得出以下结论。From this table, we can draw the following conclusions:

  • 在缓存大小相同的情况下,高级层中的缓存吞吐量要高于标准层中的缓存吞吐量。Throughput for the caches that are the same size is higher in the Premium tier as compared to the Standard tier. 例如,使用 6 GB 缓存,P1 的吞吐量为 180,000 RPS,而 C3 的吞吐量为 100,000。For example, with a 6 GB Cache, throughput of P1 is 180,000 RPS as compared to 100,000 for C3.
  • 启用 Redis 群集功能时,增加群集中分片(节点)的数量会导致吞吐量线性提高。With Redis clustering, throughput increases linearly as you increase the number of shards (nodes) in the cluster. 例如,若创建一个包含 10 个分片的 P4 群集,则可用吞吐量为 400,000 *10 = 每秒 400 万个请求。For example, if you create a P4 cluster of 10 shards, then the available throughput is 400,000 *10 = 4 Million RPS.
  • 如果增加密钥大小,则高级层的吞吐量要高于标准层。Throughput for bigger key sizes is higher in the Premium tier as compared to the Standard Tier.
定价层Pricing tier 大小Size CPU 核心数CPU cores 可用带宽Available bandwidth 1 KB 值大小1 KB value size 1 KB 值大小1 KB value size
标准缓存大小Standard cache sizes 兆位/秒(Mb/秒)/兆字节/秒(MB/秒)Megabits per sec (Mb/s) / Megabytes per sec (MB/s) 非 SSL 请求数/秒 (RPS)Requests per second (RPS) Non-SSL SSL 请求数/秒 (RPS)Requests per second (RPS) SSL
C0C0 250 MB250 MB 共享Shared 100/12.5100 / 12.5 15,00015,000 7,5007,500
C1C1 1 GB1 GB 11 500/62.5500 / 62.5 38,00038,000 20,72020,720
C2C2 2.5 GB2.5 GB 22 500/62.5500 / 62.5 41,00041,000 37,00037,000
C3C3 6 GB6 GB 44 1000/1251000 / 125 100,000100,000 90,00090,000
C4C4 13 GB13 GB 22 500/62.5500 / 62.5 60,00060,000 55,00055,000
C5C5 26 GB26 GB 44 1,000 / 1251,000 / 125 102,000102,000 93,00093,000
C6C6 53 GB53 GB 88 2,000 / 2502,000 / 250 126,000126,000 120,000120,000
高级缓存大小Premium cache sizes 每个分片的 CPU 核心数CPU cores per shard 兆位/秒(Mb/秒)/兆字节/秒(MB/秒)Megabits per sec (Mb/s) / Megabytes per sec (MB/s) 每分片非 SSL 请求数/秒 (RPS)Requests per second (RPS) Non-SSL, per shard 每分片 SSL 请求数/秒 (RPS)Requests per second (RPS) SSL, per shard
P1P1 6 GB6 GB 22 1,500 / 187.51,500 / 187.5 180,000180,000 172,000172,000
P2P2 13 GB13 GB 44 3,000 / 3753,000 / 375 350,000350,000 341,000341,000
P3P3 26 GB26 GB 44 3,000 / 3753,000 / 375 350,000350,000 341,000341,000
P4P4 53 GB53 GB 88 6,000 / 7506,000 / 750 400,000400,000 373,000373,000

有关设置 stunnel 或下载 Redis 工具(例如 redis-benchmark.exe)的说明,请参阅如何运行 Redis 命令?部分。For instructions on setting up stunnel or downloading the Redis tools such as redis-benchmark.exe, see the How can I run Redis commands? section.

我应该将缓存放在哪个区域?In what region should I locate my cache?

为了获得最佳性能并最大程度地降低延迟,请在缓存客户端应用程序所在的区域放置 Azure Redis 缓存。For best performance and lowest latency, locate your Azure Redis Cache in the same region as your cache client application.

Azure Redis 缓存如何计费?How am I billed for Azure Redis Cache?

此处提供了 Azure Redis 缓存定价。Azure Redis Cache pricing is here. 定价页列出了每小时费率。The pricing page lists pricing as an hourly rate. 缓存按分钟计费,从创建缓存时开始,到删除缓存时为止。Caches are billed on a per-minute basis from the time that the cache is created until the time that a cache is deleted. 没有提供用于停止或暂停缓存的计费选项。There is no option for stopping or pausing the billing of a cache.

是否可通过 Azure 政府云、Azure 中国云或 Microsoft Azure Germany 使用 Azure Redis 缓存?Can I use Azure Redis Cache with Azure Government Cloud, Azure China Cloud, or Microsoft Azure Germany?

可以,可通过 Azure 政府云、Azure 中国云或 Microsoft Azure Germany 使用 Azure Redis 缓存。Yes, Azure Redis Cache is available in Azure Government Cloud, Azure China Cloud, and Microsoft Azure Germany. 与 Azure 公有云相比,这些云中用于访问和管理 Azure Redis 缓存的 URL 有所不同。The URLs for accessing and managing Azure Redis Cache are different in these clouds compared with Azure Public Cloud.

Cloud Redis 的 Dns 后缀Dns Suffix for Redis
公共Public *.redis.cache.windows.net*.redis.cache.windows.net
美国政府US Gov *.redis.cache.usgovcloudapi.net*.redis.cache.usgovcloudapi.net
德国Germany *.redis.cache.cloudapi.de*.redis.cache.cloudapi.de
中国China *.redis.cache.chinacloudapi.cn*.redis.cache.chinacloudapi.cn

若要深入了解通过其他云使用 Azure Redis 缓存的注意事项,请参阅以下链接。For more information on considerations when using Azure Redis Cache with other clouds, see the following links.

有关通过 PowerShell 在 Azure 政府云、Azure 中国云和 Microsoft Azure Germany 中使用 Azure Redis 缓存的信息,请参阅如何连接到其他云 - Azure Redis 缓存 PowerShellFor information on using Azure Redis Cache with PowerShell in Azure Government Cloud, Azure China Cloud, and Microsoft Azure Germany, see How to connect to other clouds - Azure Redis Cache PowerShell.

StackExchange.Redis 配置选项有什么作用?What do the StackExchange.Redis configuration options do?

StackExchange.Redis 有很多选项。StackExchange.Redis has many options. 本部分介绍一些常用设置。This section talks about some of the common settings. 有关 StackExchange.Redis 选项的详细详细,请参阅 StackExchange.Redis configuration(StackExchange.Redis 配置)。For more detailed information about StackExchange.Redis options, see StackExchange.Redis configuration.

配置选项ConfigurationOptions DescriptionDescription 建议Recommendation
AbortOnConnectFailAbortOnConnectFail 如果设置为 true,则发生网络故障后不会重新建立连接。When set to true, the connection will not reconnect after a network failure. 设置为 false,让 StackExchange.Redis 自动重新连接。Set to false and let StackExchange.Redis reconnect automatically.
ConnectRetryConnectRetry 初始连接期间重试连接的次数。The number of times to repeat connection attempts during initial connect. 请参阅下面的注释寻求指导。See the following notes for guidance.
ConnectTimeoutConnectTimeout 连接操作的超时,以毫秒为单位。Timeout in ms for connect operations. 请参阅下面的注释寻求指导。See the following notes for guidance.

通常情况下,使用客户端的默认值便已足够。Usually the default values of the client are sufficient. 可以根据工作负荷微调选项。You can fine-tune the options based on your workload.

  • 重试Retries
    • 对于 ConnectRetry 和 ConnectTimeout,一般指导原则是快速失败并重试。For ConnectRetry and ConnectTimeout, the general guidance is to fail fast and retry again. 此指导取决于工作负载,以及客户端发出 Redis 命令和接收响应平均花费的时间。This guidance is based on your workload and how much time on average it takes for your client to issue a Redis command and receive a response.
    • 让 StackExchange.Redis 自动重新连接,而不是检查连接状态,然后由自己重新连接。Let StackExchange.Redis automatically reconnect instead of checking connection status and reconnecting yourself. 避免使用 ConnectionMultiplexer.IsConnected 属性Avoid using the ConnectionMultiplexer.IsConnected property.
    • 雪球效应 - 有时,可能会遇到这样的问题:不断地重试解决,但重试不断累积而永远无法恢复。Snowballing - sometimes you may run into an issue where you are retrying and the retries snowball and never recovers. 如果发生雪球效应,应该根据 Microsoft 模式和实践小组发布的一般重试指导原则中所述,考虑使用指数退让重试算法。If snowballing occurs, you should consider using an exponential backoff retry algorithm as described in Retry general guidance published by the Microsoft Patterns & Practices group.
  • 超时值Timeout values
    • 根据工作负载相应地设置值。Consider your workload and set the values accordingly. 如果要存储较大值,应将超时设置为较大值。If you are storing large values, set the timeout to a higher value.
    • AbortOnConnectFail 设置为 false,让 StackExchange.Redis 重新连接。Set AbortOnConnectFail to false and let StackExchange.Redis reconnect for you.
    • 使用应用程序的单个 ConnectionMultiplexer 实例。Use a single ConnectionMultiplexer instance for the application. 可以使用 LazyConnection 创建 Connection 属性返回的单个实例,如使用 ConnectionMultiplexer 类连接到缓存中所示。You can use a LazyConnection to create a single instance that is returned by a Connection property, as shown in Connect to the cache using the ConnectionMultiplexer class.
    • ConnectionMultiplexer.ClientName 属性设置为应用程序实例的唯一名称以进行诊断。Set the ConnectionMultiplexer.ClientName property to an app instance unique name for diagnostic purposes.
    • 对自定义工作负载使用多个 ConnectionMultiplexer 实例。Use multiple ConnectionMultiplexer instances for custom workloads.
      • 如果应用程序中的负载不同,可以遵循此模型。You can follow this model if you have varying load in your application. 例如:For example:
      • 可以使用一个多路复用器来处理大键。You can have one multiplexer for dealing with large keys.
      • 可以使用一个多路复用器来处理小键。You can have one multiplexer for dealing with small keys.
      • 可为连接超时设置不同的值,并为使用的每个 ConnectionMultiplexer 设置重试逻辑。You can set different values for connection timeouts and retry logic for each ConnectionMultiplexer that you use.
      • 在每个多路复用器上设置 ClientName 属性以帮助进行诊断。Set the ClientName property on each multiplexer to help with diagnostics.
      • 此指导可以更好地改进每个 ConnectionMultiplexer 的延迟。This guidance may lead to more streamlined latency per ConnectionMultiplexer.

可以使用哪些 Redis 缓存客户端?What Redis cache clients can I use?

Redis 的一大优势是有许多客户端,支持许多不同的开发语言。One of the great things about Redis is that there are many clients supporting many different development languages. 如需客户端的当前列表,请参阅 Redis 客户端For a current list of clients, see Redis clients. 若需涵盖多种不同语言和客户端的教程,请参阅如何使用 Azure Redis 缓存,并单击文章顶部语言切换器中的所需语言。For tutorials that cover several different languages and clients, see How to use Azure Redis Cache and click the desired language from the language switcher at the top of the article.

使用 Azure 门户检索主机名、端口和访问密钥Retrieve host name, ports, and access keys by using the Azure portal

连接到某个 Azure Redis 缓存实例时,缓存客户端需要该缓存的主机名、端口和密钥。When connecting to an Azure Redis Cache instance, cache clients need the host name, ports, and a key for the cache. 在某些客户端中,这些项的名称可能略有不同。Some clients might refer to these items by slightly different names. 可以在 Azure 门户中检索此信息。You can retrieve this information in the Azure portal.

检索访问密钥和主机名的步骤To retrieve the access keys and host name

  1. 若要使用 Azure 门户检索访问密钥,请浏览到缓存,然后选择“访问密钥”。To retrieve the access keys by using the Azure portal, browse to your cache and select Access keys.

    Azure Redis 缓存密钥

  2. 若要检索主机名和端口,请选择“属性”。To retrieve the host name and ports, select Properties.

    Azure Redis 缓存属性

Azure Redis 缓存是否有本地模拟器?Is there a local emulator for Azure Redis Cache?

Azure Redis 缓存没有本地模拟器,但可以在本地计算机上从 Redis 命令行工具运行 MSOpenTech 版本的 redis-server.exe 并连接到它,以获得与本地缓存模拟器相似的体验,如以下示例所示:There is no local emulator for Azure Redis Cache, but you can run the MSOpenTech version of redis-server.exe from the Redis command-line tools on your local machine and connect to it to get a similar experience to a local cache emulator, as shown in the following example:

private static Lazy<ConnectionMultiplexer>
      lazyConnection = new Lazy<ConnectionMultiplexer>
    (() =>
        // Connect to a locally running instance of Redis to simulate a local cache emulator experience.
        return ConnectionMultiplexer.Connect("");

    public static ConnectionMultiplexer Connection
            return lazyConnection.Value;

如果需要,可以选择配置 redis.conf 文件,以更好地匹配联机 Azure Redis 缓存的默认缓存设置You can optionally configure a redis.conf file to more closely match the default cache settings for your online Azure Redis Cache if desired.

如何运行 Redis 命令?How can I run Redis commands?

可以使用 Redis 命令中列出的任何命令,但 Azure Redis 缓存中不支持的 Redis 命令所列的命令除外。You can use any of the commands listed at Redis commands except for the commands listed at Redis commands not supported in Azure Redis Cache. 可以使用多个选项来运行 Redis 命令。You have several options to run Redis commands.

  • 如果采用标准或高级缓存,可以使用 Redis 控制台运行 Redis 命令。If you have a Standard or Premium cache, you can run Redis commands using the Redis Console. Redis 控制台提供了一种在 Azure 门户中安全地运行 Redis 命令的方式。The Redis console provides a secure way to run Redis commands in the Azure portal.
  • 还可以使用 Redis 命令行工具。You can also use the Redis command-line tools. 若要使用它们,请执行以下步骤:To use them, perform the following steps:
  • 下载 Redis 命令行工具Download the Redis command-line tools.
  • 使用 redis-cli.exe 连接到缓存。Connect to the cache using redis-cli.exe. 使用 -h 开关传入缓存终结点,使用 -a 传入密钥,如以下示例中所示:Pass in the cache endpoint using the -h switch and the key using -a as shown in the following example:
  • redis-cli -h <redis cache name>.redis.cache.windows.net -a <key>


Redis 命令行工具对 SSL 端口不起作用,但是,可以根据适用于 Redis 预览版的 ASP.NET 会话状态提供程序通告中的说明,使用 stunnel 等实用程序安全地将这些工具连接到 SSL。The Redis command-line tools do not work with the SSL port, but you can use a utility such as stunnel to securely connect the tools to the SSL port by following the directions in the Announcing ASP.NET Session State Provider for Redis Preview Release blog post.

Azure Redis 缓存为何不像某些其他 Azure 服务一样提供 MSDN 类库参考?Why doesn't Azure Redis Cache have an MSDN class library reference like some of the other Azure services?

Microsoft Azure Redis 缓存基于流行的开放源代码 Redis 缓存,可以通过适用于许多编程语言的各种 Redis 客户端进行访问。Microsoft Azure Redis Cache is based on the popular open source Redis Cache and can be accessed by a wide variety of Redis clients for many programming languages. 每个客户端有自身的 API,用于通过 Redis 命令调用 Redis 缓存实例。Each client has its own API that makes calls to the Redis cache instance using Redis commands.

由于客户端各不相同,因此 MSDN 上未提供统一的类参考,并且每个客户端都在维护其自身的参考文档。Because each client is different, there is not one centralized class reference on MSDN, and each client maintains its own reference documentation. 除了参考文档以外,还可以参阅多个教程,这些教程介绍了如何通过不同的语言和缓存客户端来开始使用 Azure Redis 缓存。In addition to the reference documentation, there are several tutorials showing how to get started with Azure Redis Cache using different languages and cache clients. 要访问这些教程,请参阅如何使用 Azure Redis 缓存,并单击文章顶部语言切换器中的所需语言。To access these tutorials, see How to use Azure Redis Cache and click the desired language from the language switcher at the top of the article.

是否可将 Azure Redis 缓存用作 PHP 会话缓存?Can I use Azure Redis Cache as a PHP session cache?

可以。若要使用 Azure Redis 缓存作为 PHP 会话缓存,请在 session.save_path 中指定 Azure Redis 缓存实例的连接字符串。Yes, to use Azure Redis Cache as a PHP session cache, specify the connection string to your Azure Redis Cache instance in session.save_path.


使用 Azure Redis 缓存作为 PHP 会话缓存时,必须对用于连接到缓存的安全密钥进行 URL 编码,如以下示例所示:When using Azure Redis Cache as a PHP session cache, you must URL encode the security key used to connect to the cache, as shown in the following example:

session.save_path = "tcp://mycache.redis.cache.windows.net:6379?auth=<url encoded primary or secondary key here>";

如果未对密钥进行 URL 编码,可能会收到包含如下消息的异常:Failed to parse session.save_pathIf the key is not URL encoded, you may receive an exception with a message like: Failed to parse session.save_path

有关在 PhpRedis 客户端中使用 Redis 缓存作为 PHP 会话缓存的详细信息,请参阅 PHP Session handler(PHP 会话处理程序)。For more information about using Redis Cache as a PHP session cache with the PhpRedis client, see PHP Session handler.

什么是 Redis 数据库?What are Redis databases?

Redis 数据库就是同一 Redis 实例中的数据的逻辑隔离。Redis Databases are just a logical separation of data within the same Redis instance. 缓存内存在所有数据库之间共享,给定数据库的实际内存消耗取决于该数据库中存储的键/值。The cache memory is shared between all the databases and actual memory consumption of a given database depends on the keys/values stored in that database. 例如,C6 缓存具有 53 GB 的内存。For example a C6 cache has 53 GB of memory. 可以选择将全部 53 GB 放置在一个数据库中,也可以将其分配到多个数据库中。You can choose to put all 53 GB into one database or you can split it up between multiple databases.


使用启用了群集功能的高级 Azure Redis 缓存时,仅数据库 0 可用。When using a Premium Azure Redis Cache with clustering enabled, only database 0 is available. 此限制是固有的 Redis 限制,并不特定于 Azure Redis 缓存。This limitation is an intrinsic Redis limitation and is not specific to Azure Redis Cache. 有关详细信息,请参阅使用群集功能时,是否需要对客户端应用程序进行更改?For more information, see Do I need to make any changes to my client application to use clustering?

何时应启用非 SSL 端口来连接 Redis?When should I enable the non-SSL port for connecting to Redis?

Redis 服务器本身不支持 SSL,但 Azure Redis 缓存可提供此支持。Redis server does not natively support SSL, but Azure Redis Cache does. 如果要连接到 Azure Redis 缓存并且客户端支持 SSL(如 StackExchange.Redis),则你应使用 SSL。If you are connecting to Azure Redis Cache and your client supports SSL, like StackExchange.Redis, then you should use SSL.


默认情况下,为新的 Azure Redis 缓存实例禁用了非 SSL 端口。The non-SSL port is disabled by default for new Azure Redis Cache instances. 如果客户端不支持 SSL,则必须根据在 Azure Redis 缓存中配置缓存一文中的访问端口部分中的说明启用非 SSL 端口。If your client does not support SSL, then you must enable the non-SSL port by following the directions in the Access ports section of the Configure a cache in Azure Redis Cache article.

redis-cli 等 Redis 工具对 SSL 端口不起作用,但是,可以根据适用于 Redis 预览版的 ASP.NET 会话状态提供程序通告中的说明,使用 stunnel 等实用程序安全地将这些工具连接到 SSL。Redis tools such as redis-cli do not work with the SSL port, but you can use a utility such as stunnel to securely connect the tools to the SSL port by following the directions in the Announcing ASP.NET Session State Provider for Redis Preview Release blog post.

有关下载 Redis 工具的说明,请参阅如何运行 Redis 命令?部分。For instructions on downloading the Redis tools, see the How can I run Redis commands? section.

生产的一些最佳做法是什么?What are some production best practices?

StackExchange.Redis 的最佳做法StackExchange.Redis best practices

  • AbortConnect 设置为 false,然后使 ConnectionMultiplexer 自动重新连接。Set AbortConnect to false, then let the ConnectionMultiplexer reconnect automatically. 请参阅此处了解详细信息See here for details.
  • 重复使用 ConnectionMultiplexer - 不要为每个请求创建一个新的 ConnectionMultiplexe。Reuse the ConnectionMultiplexer - do not create a new one for each request. 建议使用此处所示Lazy<ConnectionMultiplexer> 模式。The Lazy<ConnectionMultiplexer> pattern shown here is recommended.
  • 具有较小值的 Redis 工作性能最佳,因此请考虑将较大数据分成多个密钥。Redis works best with smaller values, so consider chopping up bigger data into multiple keys. 本次讨论的 Redis 为 100 kb,属于大型数据。In this Redis discussion, 100kb is considered large. 阅读此文章以了解较大值可能引起的问题示例。Read this article for an example problem that can be caused by large values.
  • 配置 ThreadPool 设置,以免超时。Configure your ThreadPool settings to avoid timeouts.
  • 将默认 connectTimeout 至少设置为 5 秒。Use at least the default connectTimeout of 5 seconds. 出现网络故障时,此间隔可以给 StackExchange.Redis 留出足够的时间来重新建立连接。This interval would give StackExchange.Redis sufficient time to re-establish the connection, in case of a network blip.
  • 请注意与正在运行的不同操作相关的性能成本。Be aware of the performance costs associated with different operations you are running. 例如,KEYS 命令是 O(n) 操作,应当避免。For instance, the KEYS command is an O(n) operation and should be avoided. redis.io 站点具有关于其支持的每个操作的时间复杂性的详细信息。The redis.io site has details around the time complexity for each operation that it supports. 单击每个命令以查看每个操作的复杂程度。Click each command to see the complexity for each operation.

配置和概念Configuration and concepts

  • 为生产系统使用标准层或高级层。Use Standard or Premium Tier for Production systems. 基本层是没有数据复制和没有 SLA 的单个节点系统。The Basic Tier is a single node system with no data replication and no SLA. 此外,使用至少一个 C1 缓存。Also, use at least a C1 cache. C0 缓存通常用于简单的开发/测试方案。C0 caches are typically used for simple dev/test scenarios.
  • 请记住,Redis 是内存中数据存储区。Remember that Redis is an In-Memory data store. 阅读此文章,了解可能出现数据丢失的情况。Read this article so that you are aware of scenarios where data loss can occur.
  • 开发系统以便处理由于修补和故障转移引起的连接故障。Develop your system such that it can handle connection blips due to patching and failover.

性能测试Performance testing

  • 使用 redis-benchmark.exe 启动以在编写性能测试前感受可能的吞吐量。Start by using redis-benchmark.exe to get a feel for possible throughput before writing your own perf tests. 因为 redis-benchmark 不支持 SSL,因此,在运行测试之前必须通过 Azure 门户启用非 SSL 端口Because redis-benchmark does not support SSL, you must enable the Non-SSL port through the Azure portal before you run the test. 例如,请参阅如何制定基准和测试缓存的性能?For examples, see How can I benchmark and test the performance of my cache?
  • 用于测试的客户端 VM 应与 Redis 缓存实例位于同一区域。The client VM used for testing should be in the same region as your Redis cache instance.
  • 建议为客户端使用 Dv2 VM 系列,因为它们具有更好的硬件,应当可以提供最佳的结果。We recommend using Dv2 VM Series for your client as they have better hardware and should give the best results.
  • 请确保选择的客户端 VM 至少与正在测试的缓存拥有相同的计算和带宽容量。Make sure your client VM you choose has at least as much computing and bandwidth capability as the cache you are testing.
  • 如果是在 Windows 设备上操作,请在客户端计算机上启用 VRSS。Enable VRSS on the client machine if you are on Windows. 请参阅此处了解详细信息See here for details.
  • 高级层 Redis 实例具有更好的网络延迟和吞吐量,因为它们是在 CPU 和网络两方面都更好的硬件上运行的。Premium tier Redis instances have better network latency and throughput because they are running on better hardware for both CPU and Network.

使用常见 Redis 命令时要注意哪些问题?What are some of the considerations when using common Redis commands?

  • 对于某些需要较长时间才能完成的 Redis 命令,在未了解这些命令造成的影响的情况下,不应运行这些命令。You should not run certain Redis commands which take a long time to complete, without understanding the impact of these commands.
    • 例如,不要在生产环境中运行 KEYS 命令,因为它可能需要很长时间才能返回,具体时间取决于键数。For example, do not run the KEYS command in production as it could take a long time to return depending on the number of keys. Redis 是单线程服务器,每次只能处理一个命令。Redis is a single-threaded server and it processes commands one at a time. 如果在 KEYS 后面发出了其他命令,则这些命令只会在处理完 KEYS 命令后才会得到处理。If you have other commands issued after KEYS, they will not be processed until Redis processes the KEYS command. redis.io 站点具有关于其支持的每个操作的时间复杂性的详细信息。The redis.io site has details around the time complexity for each operation that it supports. 单击每个命令以查看每个操作的复杂程度。Click each command to see the complexity for each operation.
  • 键大小 - 应使用小键/值还是大键/值?Key sizes - should I use small key/values or large key/values? 通常这取决于具体方案。In general, it depends on the scenario. 如果方案需要较大的键,则可以调整 ConnectionTimeout 和重试值,并调整重试逻辑。If your scenario requires larger keys, you can adjust the ConnectionTimeout and retry values and adjust your retry logic. 从 Redis 服务器的角度来看,值越小,性能就越好。From a Redis server perspective, smaller values are observed to have better performance.
  • 这些注意事项并不意味着无法 Redis 中存储较大值;必须注意以下几点。These considerations don't mean that you can't store larger values in Redis; you must be aware of the following considerations. 延迟会提高。Latencies will be higher. 如果采用一个较大的数据集和一个较小的数据集,则可以使用多个 ConnectionMultiplexer 实例,并根据 StackExchange.Redis 配置选项有什么作用部分中所述,为每个实例配置一组不同的超时和重试值。If you have one set of data that is larger and one that is smaller, you can use multiple ConnectionMultiplexer instances, each configured with a different set of timeout and retry values, as described in the previous What do the StackExchange.Redis configuration options do section.

如何制定基准和测试缓存的性能?How can I benchmark and test the performance of my cache?

  • 启用缓存诊断,以便可以监视缓存的运行状况。Enable cache diagnostics so you can monitor the health of your cache. 可以在 Azure 门户中查看度量值,也可以使用所选的工具下载和查看这些度量值。You can view the metrics in the Azure portal and you can also download and review them using the tools of your choice.
  • 可以使用 redis-benchmark.exe 对 Redis 服务器进行负载测试。You can use redis-benchmark.exe to load test your Redis server.
  • 确保负载测试客户端和 Redis 缓存位于同一区域。Ensure that the load testing client and the Redis cache are in the same region.
  • 使用 redis-cli.exe,并使用 INFO 命令监视缓存。Use redis-cli.exe and monitor the cache using the INFO command.
  • 如果负载导致出现大量内存碎片,则应该增加到更大的缓存大小。If your load is causing high memory fragmentation, you should scale up to a larger cache size.
  • 有关下载 Redis 工具的说明,请参阅如何运行 Redis 命令?部分。For instructions on downloading the Redis tools, see the How can I run Redis commands? section.

下面的命令提供了有关如何使用 redis-benchmark.exe 的示例。The following commands provide an example of using redis-benchmark.exe. 为获得准确的结果,请从与缓存位于同一区域的 VM 运行这些命令。For accurate results, run these commands from a VM in the same region as your cache.

  • 使用 1 k 有效负载测试管道 SET 请求Test Pipelined SET requests using a 1k payload

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

  • 使用 1 k 有效负载测试管道 GET 请求。Test Pipelined GET requests using a 1k payload. 注意:首先运行上面显示的 SET 测试以填充缓存NOTE: Run the SET test shown above first to populate cache

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

有关线程池增长的重要详细信息Important details about ThreadPool growth

CLR 线程池具有两种类型的线程 —“辅助角色”和“I/O 完成端口”(又称为 IOCP)线程。The CLR ThreadPool has two types of threads - "Worker" and "I/O Completion Port" (aka IOCP) threads.

  • 对于诸如处理 Task.Run(…)ThreadPool.QueueUserWorkItem(…) 方法这类事务,请使用辅助角色线程。Worker threads are used for things like processing the Task.Run(…), or ThreadPool.QueueUserWorkItem(…) methods. 需要在后台线程上进行工作时,CLR 中的各种组件也会使用这些线程。These threads are also used by various components in the CLR when work needs to happen on a background thread.
  • 进行异步 IO(例如从网络进行读取)时,使用 IOCP 线程。IOCP threads are used when asynchronous IO happens (e.g. reading from the network).

线程池按需提供新的辅助角色线程或 I/O 完成线程(没有任何限制),直到它达到每种线程类型的“最小值”设置。The thread pool provides new worker threads or I/O completion threads on demand (without any throttling) until it reaches the "Minimum" setting for each type of thread. 默认情况下,最小线程数设置为系统上的处理器数。By default, the minimum number of threads is set to the number of processors on a system.

一旦现有(忙碌)线程数达到“最小”线程数,线程池便会将插入新线程的速率限制为每 500 毫秒一个线程。Once the number of existing (busy) threads hits the "minimum" number of threads, the ThreadPool will throttle the rate at which it injects new threads to one thread per 500 milliseconds. 通常,如果系统中出现需要 IOCP 线程的突发工作,则它会非常快速地处理该工作。Typically, if your system gets a burst of work needing an IOCP thread, it will process that work very quickly. 但是,如果突发工作多于配置的“最小值”设置,则在处理某些工作时会出现一定的延迟,因为线程池会等待发生以下两种情况之一。However, if the burst of work is more than the configured "Minimum" setting, there will be some delay in processing some of the work as the ThreadPool waits for one of two things to happen.

  1. 一个现有线程释放,以便处理工作。An existing thread becomes free to process the work.
  2. 在 500 毫秒内没有任何现有线程释放,因此会创建一个新线程。No existing thread becomes free for 500ms, so a new thread is created.

基本上,这意味着忙碌线程数大于最小线程数,在应用程序处理网络流量之前可能需要付出 500 毫秒延迟。Basically, it means that when the number of Busy threads is greater than Min threads, you are likely paying a 500ms delay before network traffic is processed by the application. 此外请务必注意,当现有线程保持空闲状态的时间超过 15 秒(基于我记得的内容)时,会清理它,并且这种增长和收缩的循环可能会重复。Also, it is important to note that when an existing thread stays idle for longer than 15 seconds (based on what I remember), it will be cleaned up and this cycle of growth and shrinkage can repeat.

如果我们考虑一个来自 StackExchange.Redis(内部版本 1.0.450 或更高版本)的示例错误消息,会看到它现在会打印线程池统计信息(请参阅下面的 IOCP 和辅助角色详细信息)。If we look at an example error message from StackExchange.Redis (build 1.0.450 or later), you will see that it now prints ThreadPool statistics (see IOCP and WORKER details below).

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 个线程。In the previous example, you can see that for IOCP thread there are 6 busy threads and the system is configured to allow 4 minimum threads. 在这种情况下,客户端可能会遇到两个 500 毫秒延迟,因为 6 > 4。In this case, the client would have likely seen two 500 ms delays because 6 > 4.

请注意,如果 IOCP 或辅助角色线程受到限制,则 StackExchange.Redis 可以会超时。Note that StackExchange.Redis can hit timeouts if growth of either IOCP or WORKER threads gets throttled.


考虑到此信息,我们强烈建议客户将 IOCP 和辅助角色线程的最小配置值设置为大于默认值。Given this information, we strongly recommend that customers set the minimum configuration value for IOCP and WORKER threads to something larger than the default value. 我们无法提供有关此值应是多少的通用指导,因为一个应用程序的合适值对于另一个应用程序会太高/低。We can't give one-size-fits-all guidance on what this value should be because the right value for one application will be too high/low for another application. 此设置还可能会影响复杂应用程序其他部分的性能,因此每个客户需要按照其特定需求来微调此设置。This setting can also impact the performance of other parts of complicated applications, so each customer needs to fine-tune this setting to their specific needs. 开始时设置为 200 或 300 会比较好,随后可进行测试并根据需要进行调整。A good starting place is 200 or 300, then test and tweak as needed.

如何配置此设置:How to configure this setting:

  • 在 ASP.NET 中,可在 web.config 中的 <processModel> 配置元素下使用“minIoThreads”或“minWorkerThreads”配置设置。如果在 Azure 网站内部运行,则此设置不会通过配置选项进行公开。In ASP.NET, use the "minIoThreads" or "minWorkerThreads" configuration setting under the <processModel> configuration element in web.config. If you are running inside of Azure WebSites, this setting is not exposed through the configuration options. 但是,应该仍然能够通过 global.asax.cs 中的 Application_Start 方法以编程方式配置此设置置(请参阅下文)。However, you should still be able to configure this setting programmatically (see below) from your Application_Start method in global.asax.cs.


    此配置元素中指定的值是按核心设置。The value specified in this configuration element is a per-core setting. 例如,如果使用 4 核计算机,并且希望 minIOThreads 设置在运行时为 200,则使用 <processModel minIoThreads="50"/>For example, if you have a 4 core machine and want your minIOThreads setting to be 200 at runtime, you would use <processModel minIoThreads="50"/>.

  • 在 ASP.NET 以及 Azure WebSites global.asax 外部,使用 ThreadPool.SetMinThreads (...)API。Outside ASP.NET, and Azure WebSites global.asax, use the ThreadPool.SetMinThreads (...) API.


    此 API 指定的值是全局设置,将影响整个 AppDomain。The value specified by this API is a global setting, affecting the whole AppDomain. 如果已有 4 核计算机,并想要在运行时将 minWorkerThreads 和 minIOThreads 设置为 50(每个 CPU),可使用 ThreadPool.SetMinThreads (200, 200)。If you have a 4 core machine, and want to set minWorkerThreads and minIOThreads to 50 per CPU during run-time, you would use ThreadPool.SetMinThreads (200, 200).

启用服务器 GC,以便在使用 StackExchange.Redis 时在客户端上获取更多吞吐量Enable server GC to get more throughput on the client when using StackExchange.Redis

启用服务器 GC 可以在使用 StackExchange.Redis 时优化客户端并提供更好的性能和吞吐量。Enabling server GC can optimize the client and provide better performance and throughput when using StackExchange.Redis. 有关服务器 GC 以及如何启用它的详细信息,请参阅以下文章:For more information on server GC and how to enable it, see the following articles:

围绕连接的性能注意事项Performance considerations around connections

每个定价层都有不同的客户端连接、内存和带宽的限制。Each pricing tier has different limits for client connections, memory, and bandwidth. 虽然每个缓存大小最多允许一定数量的连接,但与 Redis 的每个连接都具有其关联的开销。While each size of cache allows up to a certain number of connections, each connection to Redis has overhead associated with it. 此类开销的一个示例是,由于 TLS/SSL 加密而导致的 CPU 和内存使用。An example of such overhead would be CPU and memory usage as a result of TLS/SSL encryption. 给定缓存大小的最大连接限制假定轻负载缓存。The maximum connection limit for a given cache size assumes a lightly loaded cache. 如果连接开销的负载客户端操作的负载超出了系统容量,那么即使未超出当前缓存大小的连接限制,缓存也可能会遇到容量问题。If load from connection overhead plus load from client operations exceeds capacity for the system, the cache can experience capacity issues even if you have not exceeded the connection limit for the current cache size.

有关每个层的不同连接限制的详细信息,请参阅 Azure Redis 缓存定价For more information about the different connections limits for each tier, see Azure Redis Cache pricing. 有关连接和其他默认配置的详细信息,请参阅默认 Redis 服务器配置For more information about connections and other default configurations, see Default Redis server configuration.

如何监视缓存的运行状况和性能?How do I monitor the health and performance of my cache?

可以在 Azure 门户中监视 Microsoft Azure Redis 缓存实例。Microsoft Azure Redis Cache instances can be monitored in the Azure portal. 可以查看度量值、将度量值图表固定到启动面板、自定义监视图表的日期和时间范围、在图表中添加和删除度量值,以及设置符合特定条件时发出的警报。You can view metrics, pin metrics charts to the Startboard, customize the date and time range of monitoring charts, add and remove metrics from the charts, and set alerts when certain conditions are met. 有关详细信息,请参阅 Monitor Azure Redis Cache(监视 Azure Redis 缓存)。For more information, see Monitor Azure Redis Cache.

Redis 缓存资源菜单中还包含了用于对缓存进行监视和故障排除的几个工具。The Redis Cache Resource menu also contains several tools for monitoring and troubleshooting your caches.

  • “诊断并解决问题”提供常见问题的相关信息,以及解决问题的策略。Diagnose and solve problems provides information about common issues and strategies for resolving them.
  • “资源运行状况”会监视资源,并告知资源是否按预期运行。Resource health watches your resource and tells you if it's running as expected. 有关 Azure 资源运行状况服务的详细信息,请参阅 Azure 资源运行状况概述For more information about the Azure Resource health service, see Azure Resource health overview.
  • “新建支持请求”提供用于建立缓存支持请求的选项。New support request provides options to open a support request for your cache.

借助这些工具,可以监视 Azure Redis 缓存实例的运行状况,以及管理缓存应用程序。These tools enable you to monitor the health of your Azure Redis Cache instances and help you manage your caching applications. 有关详细信息,请参阅如何配置 Azure Redis 缓存的“支持和故障排除设置”部分。For more information, see the "Support & troubleshooting settings" section of How to configure Azure Redis Cache.

为何会出现超时?Why am I seeing timeouts?

超时发生在用来与 Redis 通信的客户端中。Timeouts happen in the client that you use to talk to Redis. 将某个命令发送到 Redis 服务器后,该命令会排队,Redis 服务器最终会提取该命令并执行它。When a command is sent to the Redis server, the command is queued up and Redis server eventually picks up the command and executes it. 但是,客户端在此过程中可能会超时,在这种情况下,会在调用端引发异常。However the client can time out during this process and if it does an exception is raised on the calling side. 有关排查超时问题的详细信息,请参阅客户端故障排除StackExchange.Redis 超时异常For more information on troubleshooting timeout issues, see Client-side troubleshooting and StackExchange.Redis timeout exceptions.

客户端为何与缓存断开连接?Why was my client disconnected from the cache?

下面是缓存断开连接的一些常见原因。The following are some common reason for a cache disconnect.

  • 客户端的原因Client-side causes
    • 已重新部署客户端应用程序。The client application was redeployed.
    • 客户端应用程序执行了缩放操作。The client application performed a scaling operation.
      • 对于云服务或 Web 应用,原因可能在于自动缩放。In the case of Cloud Services or Web Apps, this may be due to auto-scaling.
    • 客户端上的网络层已更改。The networking layer on the client side changed.
    • 客户端中或客户端与服务器之间的网络节点中发生暂时性错误。Transient errors occurred in the client or in the network nodes between the client and the server.
    • 已达到带宽阈值限制。The bandwidth threshold limits were reached.
    • 占用大量 CPU 的操作花费了太长时间才完成。CPU bound operations took too long to complete.
  • 服务器端的原因Server-side causes
    • 在标准缓存产品上,Azure Redis 缓存服务启动了从主节点到辅助节点的故障转移。On the standard cache offering, the Azure Redis Cache service initiated a fail-over from the primary node to the secondary node.
    • Azure 正在修补已部署缓存的实例Azure was patching the instance where the cache was deployed
      • 原因可能是 Redis 服务器更新或常规 VM 维护。This can be for Redis server updates or general VM maintenance.

哪种 Azure 缓存产品适合我?Which Azure Cache offering is right for me?


按照去年的 公告,已于 2016 年 11 月 30 日停用 Azure 托管缓存服务和 Azure 角色中缓存服务。As per last year's announcement, Azure Managed Cache Service and Azure In-Role Cache service have been retired on November 30, 2016. 我们建议使用 Azure Redis 缓存Our recommendation is to use Azure Redis Cache. 有关迁移的信息,请参阅从托管缓存服务迁移到 Azure Redis 缓存For information on migrating, see Migrate from Managed Cache Service to Azure Redis Cache.

Azure Redis 缓存Azure Redis Cache

Azure Redis 缓存已正式发布,最大大小为 53 GB,且其可用性 SLA 为 99.9%。Azure Redis Cache is Generally Available in sizes up to 53 GB and has an availability SLA of 99.9%. 全新 高级层 提供的最大大小为 530 GB,且支持群集、VNET 和暂留,并附带 99.9% SLA。The new premium tier offers sizes up to 530 GB and support for clustering, VNET, and persistence, with a 99.9% SLA.

Azure Redis 缓存使客户能够使用 Microsoft 管理的安全专用 Redis 缓存。Azure Redis Cache gives customers the ability to use a secure, dedicated Redis cache, managed by Microsoft. 有了此产品,可以利用 Redis 提供的丰富功能集和生态系统,并可以从 Microsoft 获得可靠的托管和监控。With this offer, you get to leverage the rich feature set and ecosystem provided by Redis, and reliable hosting and monitoring from Microsoft.

与仅处理键/值对的传统缓存不同,Redis 因其高性能的数据类型而受欢迎。Unlike traditional caches which deal only with key-value pairs, Redis is popular for its highly performant data types. Redis 还支持对这些类型运行原子操作,如在字符串后面追加内容;递增哈希中的值;推送到列表;计算交集、并集和差集,或者获取排序集中排名最高的成员。Redis also supports running atomic operations on these types, like appending to a string; incrementing the value in a hash; pushing to a list; computing set intersection, union and difference; or getting the member with highest ranking in a sorted set. 其他功能包括支持事务、发布/订阅、Lua 脚本、具有有限生存时间的键和配置设置,使 Redis 在行为上更类似于传统缓存。Other features include support for transactions, pub/sub, Lua scripting, keys with a limited time-to-live, and configuration settings to make Redis behave more like a traditional cache.

Redis 取得成功的另一个重要方面是围绕它构建了健康而充满活力的开放源生态系统。Another key aspect to Redis success is the healthy, vibrant open source ecosystem built around it. 这反映在可通过多种语言使用各种不同的 Redis 客户端。This is reflected in the diverse set of Redis clients available across multiple languages. 此生态系统和广泛的客户端使得 Azure Redis 缓存几乎可供在 Azure 内生成的任何工作负荷使用。This ecosystem and wide range of clients allow Azure Redis Cache to be used by nearly any workload you would build inside of Azure.

有关如何开始使用 Azure Redis 缓存的详细信息,请参阅如何使用 Azure Redis 缓存Azure Redis 缓存文档For more information about getting started with Azure Redis Cache, see How to Use Azure Redis Cache and Azure Redis Cache documentation.

托管缓存服务Managed Cache service

已于 2016 年 11 月 30 日停用托管缓存服务。Managed Cache service was retired November 30, 2016.

若要查看存档文档,请参阅已存档托管缓存服务文档To view archived documentation, see Archived Managed Cache Service Documentation.

角色中缓存In-Role Cache

已于 2016 年 11 月 30 日停用角色中缓存。In-Role Cache was retired November 30, 2016.

若要查看存档文档,请参阅已存档角色中缓存文档To view archived documentation, see Archived In-Role Cache Documentation.