Whenever I do a write into Azure redis cache with multiple replicas I suspect then it will take some small period of time to replicate the data across all replicas. What is the story there? How can I achieve full consistency so that after a write all replicas report a consistent read? It seems there are three levels of redundancy: Standard replication. Clients will mainly read/write to the primary, and will only read from secundary when configured so Zone redundancy. The story gets blurry here. The diagram seems to hint that reading is done arbitrarily across the available nodes. I would expect inconsistency can happen across zone writes/reads. Geo reundancy. Clients connect with the region closest to them. I assume there can be inconsistency across region writes/reads. Reference: https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-high-availability

What is the consistency story of azure redis cache?

carlintveld 26

Whenever I do a write into Azure redis cache with multiple replicas I suspect then it will take some small period of time to replicate the data across all replicas.

What is the story there? How can I achieve full consistency so that after a write all replicas report a consistent read?

It seems there are three levels of redundancy:

Standard replication. Clients will mainly read/write to the primary, and will only read from secundary when configured so
Zone redundancy. The story gets blurry here. The diagram seems to hint that reading is done arbitrarily across the available nodes. I would expect inconsistency can happen across zone writes/reads.
Geo reundancy. Clients connect with the region closest to them. I assume there can be inconsistency across region writes/reads.

Reference: https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-high-availability

Mahesh Kurva 1,470 Reputation points Microsoft Vendor

2024-10-16T11:33:24.1466667+00:00
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.
carlintveld 26 Reputation points

2024-10-17T08:07:03.7366667+00:00

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.
Mahesh Kurva 1,470 Reputation points Microsoft Vendor

2024-10-17T11:57:22.6633333+00:00
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.
Mahesh Kurva 1,470 Reputation points Microsoft Vendor

2024-10-18T12:17:37.21+00:00

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.
Oury Ba-MSFT 19,831 Reputation points Microsoft Employee

2024-10-18T23:18:43.06+00:00

@carlintveld

Replication between regions is batched to optimize for throughput over latency. A write operation to one cache is not immediately replicated to another region. Instead, writes that are pending replication to another region are buffered until either the buffer is filled, or a periodic timer is reached.

Share via

What is the consistency story of azure redis cache?

Your answer