What is the consistency story of azure redis cache?

Hi @carlintveld,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

When you write data to Azure Cache for Redis with multiple replicas, it is replicated asynchronously from the primary node to the replica nodes. This means that there may be a small period of time where the data is not consistent across all replicas.

However, Azure Cache for Redis has a high availability architecture that ensures your managed instance is functioning, even when outages affect the underlying virtual machines.

Standard Replication.

• In standard replication, Azure Cache for Redis uses a primary-replica model. The primary node handles all write operations and most read operations, while replicas are updated asynchronously. This means there can be a slight delay before the replicas reflect the latest data. To achieve full consistency, you would need to ensure that reads are always directed to the primary node.

Zone redundancy.

• The primary and replica nodes are spread across different zones within a region. Clients can read and write to any node within the region, but writes are only committed to the primary node. Reads can be done from any node but may not be consistent across all nodes immediately after a write.

Geo-redundancy

• Clients connect to the region closest to them. Writes are committed to the primary node in the region and reads can be done from any node in any region. However, there may be a delay in consistency across regions due to the asynchronous replication process.

How can I achieve full consistency so that after a write all replicas report a consistent read?

You can consider the following strategies:

• Ensure that all read operations are directed to the primary node.
• You can use the WAIT command to ensure that write operations are only considered complete once they have been acknowledged by a specified number of replicas. This helps maintain consistency by confirming that the data has been replicated to the desired replicas before returning a success response to the client.
• Use client-side caching to reduce the number of read operations hitting the replicas, thereby reducing the chances of reading stale data.

For more information, please refer the document: https://redis.io/docs/latest/operate/rs/clusters/optimize/wait/

I hope this information helps. Please do let us know if you have any further queries.

Can you show me how the client configuration looks like? It seems if you want full consistency without any hassle you should stick to reading the primary replica. In the documentation diagrams I see only one endpoint. How are the other replica endpoints made available?

The WAIT command, there is no strict directive it seems that states "Wait until replicated to all replicas". How can you enforce complete replication?

Client-side caching doesn't help when you have a non-sticky sessions architecture. Any compute node will immediately hit redis for its desired state.

Hi @carlintveld,

Thanks for your response.

Can you show me how the client configuration looks like? It seems if you want full consistency without any hassle you should stick to reading the primary replica. In the documentation diagrams I see only one endpoint. How are the other replica endpoints made available?

To achieve full consistency in Azure Cache for Redis, you should configure your clients to read from the primary node. Here’s an example of how you can configure a Redis client in C# using the StackExchange.Redis library:

using StackExchange.Redis;
var connectionString = "your-primary-endpoint.redis.cache.windows.net:6380,password=yourPassword,ssl=True,abortConnect=False";
var redis = ConnectionMultiplexer.Connect(connectionString);
var db = redis.GetDatabase();
// Writing data
db.StringSet("key", "value");
// Reading data
var value = db.StringGet("key");
Console.WriteLine(value);

For more information, please refer the document: https://redis.io/docs/latest/develop/connect/clients/dotnet/.

The WAIT command, there is no strict directive it seems that states "Wait until replicated to all replicas". How can you enforce complete replication?

The WAIT command in Redis can help ensure that write operations are acknowledged by a specified number of replicas before considering the write complete. However, it doesn’t guarantee replication to all replicas.

Here’s how you can use the WAIT command:

db. Execute("WAIT", 2, 1000); 

This command ensures that the write operation is acknowledged by at least 2 replicas before returning.

For more information, please refer the document: https://redis.io/docs/latest/commands/wait/

Client-side caching doesn't help when you have a non-sticky sessions architecture. Any compute node will immediately hit redis for its desired state.

In a non-sticky sessions architecture, where any compute node can hit Redis for its desired state, client-side caching might not be effective. Instead, you should ensure that all read operations are directed to the primary node to maintain consistency. This can be achieved by configuring your Redis client to always read from the primary endpoint.

I hope this information helps. Please do let us know if you have any further queries.

Hi @carlintveld,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.