Instead of one instance per VM, you can now stack multiple instances behind a Redis proxy. There’s another big change: Although you’re both still using two nodes, the nodes run a mixture of primary and replicated processes. A primary instance uses more resources than a replica, so this approach allows you to get the best possible performance from your VMs. This mix of primary and replicate nodes also automatically aggregates data to speed up access and support geographic replication across regions.
Azure Managed Redis has two different clustering policies, OSS and Enterprise. The OSS option is the same as the community edition with direct connection to individual shards. This works well, with near-linear scaling, but requires specific support in any client libraries you use in your code. The alternative, Enterprise, operates through a single proxy node, simplifying connection requests for clients at the expense of performance.
Why would you use Redis in an application? In many cases, it is a tool for keeping regularly accessed data stored in memory, allowing fast read/write access. It is used anywhere you need fast key-value storage with support for modern features like vector indexing. Using Redis as an in-memory vector index helps keep latency to a minimum in AI applications based on augmented load generation (RAG). Cloud-native applications can use Redis as a session store to manage state across containerized applications, so AI applications can use Redis to cache recent output and use it as semantic memory in frameworks like the Semantic Kernel.