Em vez de uma instância por VM, agora você pode empilhar várias instâncias atrás de um proxy Redis. Há outra grande mudança: embora você ainda use dois nós, ambos executam uma combinação de processos primários e de réplica. Uma instância primária usa mais recursos do que uma réplica, portanto, essa abordagem permite obter o melhor desempenho possível de suas VMs. Ao mesmo tempo, essa combinação de nós primários e de réplica agrupa automaticamente os dados para acelerar o acesso e permitir o suporte para replicação geográfica entre regiões.
O Azure Managed Redis tem duas políticas de cluster diferentes, OSS e Enterprise. A opção OSS é a mesma usada pela edição comunitária, com conexões diretas a fragmentos individuais. Isso funciona bem, com escalonamento quase linear, mas requer suporte específico em qualquer biblioteca cliente que você estiver usando em seu código. A alternativa, Enterprise, funciona através de um único nó proxy, simplificando os requisitos de conexão dos clientes em detrimento do desempenho.
Por que você usaria Redis em um aplicativo? Em muitos casos, é uma ferramenta para manter dados acessados regularmente em cache na memória, permitindo acesso rápido de leitura/gravação. Ele está sendo usado em qualquer lugar onde você precisa de um armazenamento rápido de chave/valor com suporte para recursos modernos, como indexação vetorial. Usar o Redis como um índice vetorial na memória ajuda a manter a latência no mínimo em aplicativos de IA com base na geração aumentada de recuperação (RAG). Os aplicativos nativos da nuvem podem usar o Redis como um armazenamento de sessão para gerenciar o estado em aplicativos de contêiner, de modo que os aplicativos de IA podem usar o Redis como cache para saída recente, usando-o como memória semântica em estruturas como o Kernel Semântico.
