What is Azure Redis Cache?
Azure Redis Cache is based on the popular open-source Redis cache. It gives you access to a secure, dedicated Redis cache, managed by Microsoft, and accessible from any where in the world.
Azure Redis Cache is available in the following tiers:
- Basic—Single node, multiple sizes, ideal for development/test and non-critical workloads. The basic tier has no SLA.
- Standard—A replicated cache in a two node Primary/Secondary configuration managed by Microsoft, with a high availability SLA.
- Premium—The new Premium tier includes a high availability SLA and all the Standard-tier features and more, such as better performance over Basic or Standard-tier Caches, bigger workloads, disaster recovery and enhanced security. Additional features include:
- Redis persistence allows you to persist data stored in Redis cache. You can also take snapshots and back up the data which you can load in case of a failure.
- Redis cluster automatically shards data across multiple Redis nodes, so you can create workloads of bigger memory sizes (greater than 53 GB) and get better performance.
- 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.
Basic and Standard caches are available in sizes up to 53 GB and Premium caches are available in sizes up to 530 GB with more on request.
What Redis Cache offering and size should I use?
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.
- Memory: The Basic and Standard tiers offer 250 MB – 53 GB. The Premium tier offers up to 530 GB with more available on request. 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. Also within each tier, larger size caches have more bandwidth because of the underlying VM that hosts the cache. See the following tablefor 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.
- High Availability/SLA: Azure Redis Cache guarantees that a Standard/Premium cache is available at least 99.9% of the time. To learn more about our SLA, see Azure Redis Cache Pricing. The SLA only covers connectivity to the Cache endpoints. The SLA does not cover protection from data loss. We recommend using the Redis data persistence feature in the Premium tier to increase resiliency against data loss.
- 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. We recommend using the Redis data persistence feature in the Premium tier to increase resiliency against data loss. Azure Redis Cache offers RDB and AOF (coming soon) options in Redis persistence. For more information, see How to configure persistence for a Premium Azure Redis Cache.
- 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. For more information, see How to configure clustering for a Premium Azure Redis Cache.
- 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. For more information, see How to configure Virtual Network support for a Premium Azure Redis Cache.
- Configure Redis: In both the Standard and Premium tiers, you can configure Redis for Keyspace notifications.
- 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. For more information, see Azure Redis Cache pricing.
- Dedicated Core for Redis Server: In the Premium tier, all cache sizes have a dedicated core for Redis. In the Basic/Standard tiers, the C1 size and above have a dedicated core for Redis server.
- 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.
In what region should I locate my cache?
For best performance and lowest latency, locate your Azure Redis Cache in the same region as your cache client application.
How am I billed for Azure Redis Cache?
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.
What do the StackExchange.Redis configuration options do?
StackExchange.Redis has many options. This section talks about some of the common settings. For more detailed information about StackExchange.Redis options, see StackExchange.Redis configuration.
|AbortOnConnectFail||When set to true, the connection will not reconnect after a network failure.||Set to false and let StackExchange.Redis reconnect automatically.|
|ConnectRetry||The number of times to repeat connection attempts during initial connect.||See the following notes for guidance.|
|ConnectTimeout||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.
- For ConnectRetry and ConnectTimeout, the general guidance is to fail fast and retry again. 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.
- Let StackExchange.Redis automatically reconnect instead of checking connection status and reconnecting yourself. 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. 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.
AbortOnConnectFailto false and let StackExchange.Redis reconnect for you.
- Use a single ConnectionMultiplexer instance for the application. 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.
- Set the
ConnectionMultiplexer.ClientNameproperty to an app instance unique name for diagnostic purposes.
- Use multiple
ConnectionMultiplexerinstances 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.
- You can set different values for connection timeouts and retry logic for each ConnectionMultiplexer that you use.
- Set the
ClientNameproperty on each multiplexer to help with diagnostics.
- This guidance may lead to more streamlined latency per
What are Redis databases?
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. For example a C6 cache has 53 GB of memory. You can choose to put all 53 GB into one database or you can split it up between multiple databases.
When should I enable the non-SSL port for connecting to Redis?
Redis server does not natively support SSL, but Azure Redis Cache does. If you are connecting to Azure Redis Cache and your client supports SSL, like StackExchange.Redis, then you should use SSL.