Edit

Share via

Azure Managed Redis (preview) Client libraries

  • Article

Azure Managed Redis (preview) is based on the popular in-memory data store, Redis. Azure Managed Redis can be accessed by a wide variety of Redis clients for many programming languages. Each client library has its own API that makes calls to Redis server using Redis commands, but the client libraries are built to talk to any Redis server.

Each client library maintains its own reference documentation. The libraries also provide links to get support through the client library developer community. The Azure Managed Redis team doesn't own the development, or the support for any client libraries.

Recommendations below are based on popularity and whether there's an active online community to support and answer your questions. We only recommend using the latest available version, and upgrading regularly as new versions become available. These libraries are under active development and often release new versions with improvements to reliability and performance.

Client library Language GitHub repo Documentation
StackExchange.Redis C#/.NET Link More information here
Lettuce Java Link More information here
Jedis Java Link
node_redis Node.js Link
Redisson Java Link More information here
ioredis Node.js Link More information here

Note

Your application can use any client library that is compatible with open-source Redis to connect to your Azure Managed Redis instance.

Choosing the right client library based on your clustering policy

Azure Managed Redis supports the Enterprise clustering policy and the OSS clustering policy. See more information here (add link to clustering policy information). All client libraries work with your Redis instance with Enterprise clustering policy. However, if you are using the OSS clustering policy, ensure that the client library you choose supports connecting to clustered Redis instances.

Blocked commands

Configuration and management of Azure Managed Redis instances is managed by Microsoft, which disables the following commands by default. For more information on blocked commands, see Cluster management commands compatibility

Multi-key commands

Because the AMR instances use a clustered configuration, you might see CROSSSLOT exceptions on commands that operate on multiple keys. Behavior varies depending on the clustering policy used. If you use the OSS clustering policy, multi-key commands require all keys to be mapped to the same hash slot.

You might also see CROSSSLOT errors with Enterprise clustering policy. Only the following multi-key commands are allowed across slots with Enterprise clustering: DEL, MSET, MGET, EXISTS, UNLINK, and TOUCH.

In Active-Active databases, multi-key write commands (DEL, MSET, UNLINK) can only be run on keys that are in the same slot. However, the following multi-key commands are allowed across slots in Active-Active databases: MGET, EXISTS, and TOUCH. For more information, see Database clustering.

Commands blocked for Enterprise clustering policy

  • CLUSTER INFO
  • CLUSTER HELP
  • CLUSTER KEYSLOT
  • CLUSTER NODES
  • CLUSTER SLOTS

Commands blocked for active geo-replication

  • FLUSHALL
  • FLUSHDB

Client library-specific guidance

For information on client library-specific guidance best practices, see the following links:

Redisson (Java)

We recommend you use redisson 3.14.1 or higher. Older versions contain known connection leak issues that cause problems after failovers. Monitor the Redisson changelog for other known issues can affect features used by your application. For more information, seeCHANGELOG and the Redisson FAQ.

Other notes:

  • Redisson defaults to 'read from replica' strategy, unlike some other clients. To change this, modify the 'readMode' config setting.
  • Redisson has a connection pooling strategy with configurable minimum and maximum settings, and the default minimum values are large. The large defaults could contribute to aggressive reconnect behaviors or 'connection storms'. To reduce the risk, consider using fewer connections because you can efficiently pipeline commands, or batches of commands, over a few connections.
  • Redisson has a default idle connection timeout of 10 seconds, which leads to more closing and reopening of connections than ideal.

Here's a recommended baseline configuration for cluster mode that you can modify as needed:

clusterServersConfig:
  idleConnectionTimeout: 30000
  connectTimeout: 15000
  timeout: 5000
  retryAttempts: 3
  retryInterval: 3000
  checkLockSyncedSlaves: false
  failedSlaveReconnectionInterval: 15000
  failedSlaveCheckInterval: 60000
  subscriptionsPerConnection: 5
  clientName: "redisson"
  loadBalancer: !<org.redisson.connection.balancer.RoundRobinLoadBalancer> {}
  subscriptionConnectionMinimumIdleSize: 1
  subscriptionConnectionPoolSize: 50
  slaveConnectionMinimumIdleSize: 2
  slaveConnectionPoolSize: 24
  masterConnectionMinimumIdleSize: 2
  masterConnectionPoolSize: 24
  readMode: "MASTER"
  subscriptionMode: "MASTER"
  nodeAddresses:
  - "redis://mycacheaddress:10000"
  scanInterval: 1000
  pingConnectionInterval: 60000
  keepAlive: false
  tcpNoDelay: true

For an article demonstrating how to use Redisson's support for JCache as the store for HTTP session state in IBM Liberty on Azure, see Use Java EE JCache with Open Liberty or WebSphere Liberty on an Azure Kubernetes Service (AKS) cluster.

How to use client libraries

Besides the reference documentation, you can find tutorials showing how to get started with Azure Managed Redis using different languages and cache clients.

For more information on using some of these client libraries in tutorials, see the following articles:

Next steps