Configurar a Cache do Azure para Redis

5 minutos

Sua equipe de desenvolvimento de estatísticas esportivas decidiu que o cache pode melhorar drasticamente o desempenho dos dados solicitados recentemente. O próximo passo é criar e configurar uma instância da Cache do Azure para Redis.

Criar e configurar a instância da Cache do Azure para Redis

É possível criar uma cache de Redis através do portal do Azure, da CLI do Azure ou do Azure PowerShell. Há vários parâmetros que você precisará decidir para configurar o cache corretamente para seus propósitos.

Nome

Seu cache Redis precisa de um nome globalmente exclusivo. O nome deve ser exclusivo no Azure, porque é usado para gerar uma URL voltada para o público para se conectar e se comunicar com o serviço.

O nome deve ter entre 1 e 63 caracteres, composto por números, letras e o - caractere. O nome do cache não pode começar ou terminar com o - caractere e os caracteres consecutivos - não são válidos.

Grupo de recursos

A Cache do Azure para Redis é um recurso gerido e necessita de um proprietário de um grupo de recursos. Você pode criar um novo grupo de recursos ou usar um existente em uma assinatura à qual você tem acesso.

Localização

Você precisará decidir onde o cache Redis estará fisicamente localizado selecionando uma região do Azure. Deve colocar sempre a instância de cache e a aplicação na mesma região. Ligar a uma cache numa região diferente pode aumentar significativamente a latência e reduzir a fiabilidade. Se você estiver se conectando ao cache fora do Azure, selecione um local próximo de onde o aplicativo que consome os dados está sendo executado.

Importante

Coloque a cache de Redis o mais próximo possível do consumidor de dados.

Escalão de preço

Conforme mencionado na unidade anterior, há três níveis de preços disponíveis para um Cache do Azure para Redis.

Básico: O cache básico é ideal para desenvolvimento/teste. É limitado a um único servidor, 53 GB de memória e 20.000 conexões. Não há SLA para essa camada de serviço.
Padrão: Este é o cache de produção, que oferece suporte à replicação e inclui um SLA de 99,99%. Ele suporta dois servidores (primário/secundário) e tem os mesmos limites de memória/conexão que a camada Basic.
Premium: esta é a camada Enterprise, que se baseia na camada Standard e inclui suporte a persistência, cluster e cache de expansão. O Premium é o nível de melhor desempenho, com até 530 GB de memória e 40.000 conexões simultâneas.

Você pode controlar a quantidade de memória cache disponível em cada camada escolhendo um nível de cache de C0-C6 para Basic/Standard e P0-P4 para Premium. Consulte a página de preços para ver os detalhes completos.

Gorjeta

A Microsoft recomenda que você sempre use a camada Standard ou Premium para sistemas de produção. A camada Basic é um sistema de nó único sem replicação de dados e sem SLA. Além disso, utilize pelo menos uma cache C1. Os caches C0 são realmente destinados a cenários simples de desenvolvimento/teste, porque eles têm um núcleo de CPU compartilhado e muito pouca memória.

O escalão Premium oferece-lhe duas formas de manter os dados para assegurar a recuperação após desastre:

A persistência RDB tira um instantâneo periódico e pode reconstruir o cache usando o instantâneo se houver uma falha.
A persistência do AOF guarda todas as operações de escrita num registo que é guardado, pelo menos, uma vez por segundo. AOF cria arquivos maiores do que RDB, mas tem menos perda de dados.

Existem várias outras configurações que só estão disponíveis para o nível Premium .

Suporte de Rede Virtual

Se você criar um cache Redis de camada premium, poderá implantá-lo em uma rede virtual na nuvem. Seu cache só estará disponível para outras máquinas virtuais e aplicativos na mesma rede virtual. A implantação em uma rede virtual fornece um nível mais alto de segurança quando seu serviço e cache estão hospedados no Azure ou conectados por meio de uma VPN de rede virtual do Azure.

Suporte de clustering

Com uma cache de Redis do escalão Premium, pode implementar o clustering para dividir automaticamente o seu conjunto de dados por vários nós. Para implementar o clustering, especifique o número de partições horizontais até um máximo de 10. O custo incorrido é o custo do nó original multiplicado pelo número de fragmentos.

Acessar a instância do Redis

O Redis suporta um conjunto de comandos conhecidos. Normalmente é gerado um comando como COMMAND parameter1 parameter2 parameter3.

Eis alguns comandos comuns que pode utilizar:

Comando	Description
`ping`	Pings o servidor. Devolve "PONG".
`set [key] [value]`	Define uma chave/valor na cache. Devolve "OK" no sucesso.
`get [key]`	Obtém um valor da cache.
`exists [key]`	Retorna "1" se a chave existir no cache, "0" se não existir.
`type [key]`	Devolve o tipo associado ao valor da chave em questão.
`incr [key]`	Incremente o valor dado associado à chave em um. O valor tem de ser um número inteiro ou um valor duplo. Devolve o novo valor.
`incrby [key] [amount]`	Incremente o valor dado associado à chave na quantidade especificada. O valor tem de ser um número inteiro ou um valor duplo. Devolve o novo valor.
`del [key]`	Elimina o valor associado à chave.
`flushdb`	Elimina todas as chaves e valores na base de dados.

O Redis tem uma ferramenta de linha de comandos (redis-cli) que pode utilizar para experimentar diretamente estes comandos. Seguem-se alguns exemplos.

> set somekey somevalue
OK
> get somekey
"somevalue"
> exists somekey
(string) 1
> del somekey
(string) 1
> exists somekey
(string) 0

Eis um exemplo de utilização dos comandos INCR. Esses comandos são convenientes porque fornecem incrementos atômicos em vários aplicativos que estão usando o cache.

> set counter 100
OK
> incr counter
(integer) 101
> incrby counter 50
(integer) 151
> type counter
(integer)

Adicionar um tempo de expiração aos valores

A colocação em cache é importante pois permite-nos armazenar valores comummente usados na memória. No entanto, também precisamos de uma maneira de expirar valores quando eles estão obsoletos. O Redis lida com a expiração aplicando um tempo de vida (TTL) a uma chave.

Quando o TTL expira, a chave é excluída automaticamente, exatamente como se o DEL comando fosse emitido. Eis algumas notas sobre expirações de TTL.

As expirações podem ser definidas com uma precisão de segundos ou milissegundos.
A resolução do tempo de expiração é sempre de um milissegundo.
O tempo passa virtualmente, mesmo quando o servidor Redis permanece parado.
As informações de expiração são replicadas e persistidas no disco.
Redis salva a data em que uma chave expirará.

Aqui está um exemplo de uma expiração:

> set counter 100
OK
> expire counter 5
(integer) 1
> get counter
100
... wait ...
> get counter
(nil)

Acessar um cache Redis de um cliente

Para ligar a uma instância da Cache do Azure para Redis, necessita de vários elementos de informação. Os clientes necessitam do nome do anfitrião, da porta e de uma chave de acesso para a cache. Você pode recuperar essas informações no portal do Azure por meio da página Chaves de Acesso de Configurações>.

O nome do host é o endereço público da Internet do seu cache, que foi criado usando o nome do cache; por exemplo, sportsresults.redis.cache.windows.net.
A chave de acesso funciona como uma palavra-passe na cache. São criadas duas chaves: primária e secundária. Você pode usar qualquer uma das chaves, e duas são fornecidas caso você precise alterar a chave primária. Você pode alternar todos os seus clientes para a chave secundária e regenerar a chave primária. No entanto, todos os aplicativos que usam a chave primária original seriam bloqueados. A Microsoft recomenda regenerar periodicamente as chaves, tal como faria com as suas palavras-passe pessoais.

Aviso

As suas chaves de acesso devem ser consideradas informações confidenciais; Trate-os como se fosse uma senha. Qualquer pessoa com uma chave de acesso pode efetuar qualquer operação na sua cache!

Continuar