View a markdown version of this page

Opções de durabilidade - Amazônia ElastiCache

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Opções de durabilidade

ElastiCache for Valkey oferece duas opções de durabilidade: gravações síncronas e assíncronas.

Com as gravações síncronas, as operações de gravação bem-sucedidas são armazenadas de forma durável no log Multi-AZ transacional antes de serem devolvidas aos clientes. Isso gera latência de gravação de um dígito em milissegundos e garante que nenhuma operação de gravação reconhecida seja perdida em caso de falha.

Com as gravações assíncronas, as operações de gravação bem-sucedidas são devolvidas aos clientes antes de serem armazenadas de forma durável no log transacional. Multi-AZ Como as operações de gravação não esperam para serem armazenadas de forma durável no log Multi-AZ transacional, a latência da operação de gravação é equivalente à ausência de durabilidade. ElastiCache No entanto, até os últimos 10 segundos de operações de gravação bem-sucedidas podem ser perdidos em caso de falha.

Para entender a possível perda de dados com gravações assíncronas, considere o conceito de buffer de durabilidade. O buffer de durabilidade representa a idade máxima de qualquer gravação que tenha sido aceita pelo nó primário, mas que ainda não tenha persistido no log Multi-AZ transacional. O nó primário rastreia a idade da escrita não reconhecida mais antiga. Enquanto essa idade permanecer abaixo de 10 segundos, o nó continuará aceitando novas gravações normalmente. Se a idade da gravação não reconhecida mais antiga ultrapassar 10 segundos, o nó primário rejeitará todos os comandos de gravação recebidos até que sejam atualizados. As operações de leitura continuam sendo atendidas com latência de microssegundos durante esse período. Depois que as gravações pendentes persistirem, o nó retomará a aceitação das gravações automaticamente. Isso garante que a perda potencial de dados seja limitada a 10 segundos de gravações em caso de falha.

Ao configurar seu cliente para enviar tráfego para um cluster durável assíncrono, certifique-se de que o cliente tente automaticamente, com recuo exponencial, qualquer comando de gravação que seja rejeitado com a mensagem de erro de desativação do cluster. Para obter orientação sobre como configurar seus clientes para lidar com esse e outros erros transitórios, consulte Melhores práticas: clientes Valkey/Redis OSS e Amazon. ElastiCache

Diagrama mostrando como o buffer de durabilidade assíncrono funciona em cinco estados: as gravações entram no buffer, o registro transacional as persiste e, se o buffer exceder 10 segundos, as novas gravações serão rejeitadas até que o registro seja atualizado.

Escolhendo uma opção de durabilidade

Use gravações síncronas quando seu aplicativo não tolerar nenhuma perda de dados durante falhas. Com gravações síncronas, você pode usar ElastiCache para um conjunto mais amplo de casos de uso além do armazenamento em cache, onde a perda de dados não é aceitável, como bases de conhecimento para aplicativos RAG, memória do agente de IA, estado do fluxo de trabalho do agente de IA, tokenização de pagamentos, metadados de streaming, estado do jogador de jogos e gerenciamento de inventário em tempo real.

Use gravações assíncronas quando seu aplicativo prioriza o desempenho de gravação e pode tolerar a perda potencial de até 10 segundos de dados não confirmados durante uma falha. Essa opção é ideal para cargas de trabalho, como armazenamento em cache de dados de aplicativos, armazenamentos de sessões, tabelas de classificação de jogos e análises em tempo real.

Consideração da política de despejo para clusters duráveis

Os clusters duráveis usam o mesmo grupo de parâmetros padrão que os clusters não duráveis. Esse grupo de parâmetros é definido maxmemory-policy comovolatile-lru. Com essa política, a Amazon ElastiCache pode despejar chaves que tenham um tempo de vida (TTL) definido quando a memória está sob pressão. Isso pode acontecer até mesmo em um cluster durável.

Para evitar o despejo de chaves com um TTL, crie um grupo de parâmetros personalizado e defina-o como. maxmemory-policy noeviction Comnoeviction, os comandos de gravação retornam um erro quando a memória está cheia, em vez de remover as chaves.

Monitore BytesUsedForCache e DatabaseMemoryUsagePercentage certifique-se de que seu cluster tenha memória suficiente para sua carga de trabalho.