Tair Proxy features and routing rules - Tair (Redis® OSS-Compatible): Central de Documentação do Alibaba Cloud

Nas instâncias do Tair (Redis OSS-compatible) que utilizam a arquitetura de cluster ou a arquitetura de separação de leitura/escrita, os nós de proxy são responsáveis pelo roteamento de requisições, balanceamento de carga e failover. Os nós de proxy simplificam a lógica do lado do cliente e oferecem suporte a recursos avançados, como múltiplos bancos de dados (DBs) e cache de hotkeys. Compreender as regras de roteamento dos nós de proxy e como eles tratam comandos específicos ajuda a projetar sistemas de negócio mais eficientes.

Visão geral dos nós de proxy

O nó de proxy é um componente independente em uma instância do Tair. Ele não consome recursos dos shards de dados. O Tair utiliza múltiplos nós de proxy para implementar balanceamento de carga e failover.

Capacidade	Descrição
Transição de modo de uso para instâncias de cluster	Os nós de proxy fazem a ponte entre arquiteturas, permitindo utilizar uma instância com arquitetura de cluster como se fosse uma instância standalone. Os nós de proxy oferecem suporte a operações cross-slot para comandos que gerenciam múltiplas chaves, como DEL, EXISTS, MGET, MSET, SDIFF e UNLINK. Para mais informações, consulte List of commands supported in proxy mode. Quando uma instância com arquitetura standalone não atende mais às necessidades do seu negócio, você pode migrar os dados para uma instância com arquitetura de cluster com nós de proxy sem precisar modificar o código. Isso reduz significativamente os custos de transformação do negócio.
Balanceamento de carga e roteamento de requisições	Os nós de proxy estabelecem conexões persistentes com os shards de dados no backend e tratam o roteamento de requisições e o balanceamento de carga. Para mais informações sobre roteamento, consulte Routing rules of proxy nodes.
Gerenciamento de tráfego para réplicas de leitura	Os nós de proxy monitoram continuamente o status das réplicas de leitura e controlam o tráfego nas seguintes situações: Réplica de leitura em estado anormal: o nó de proxy reduz o peso de service da réplica. Se o nó de proxy falhar ao conectar-se à réplica múltiplas vezes, ele para de enviar tráfego para ela. O nó de proxy retoma o envio de tráfego após a recuperação da réplica. Réplica de leitura em sincronização completa de dados: o nó de proxy interrompe temporariamente o envio de tráfego para a réplica até que a sincronização seja concluída.
Proxy query cache	Após ativar o recurso de proxy query cache, os nós de proxy armazenam em cache as requisições que contêm hotkeys e suas respostas correspondentes. Quando um nó de proxy recebe a mesma requisição dentro do período de validade do cache, ele retorna o resultado diretamente ao cliente sem interagir com os shards de dados no backend. Isso ajuda a mitigar a assimetria de acesso causada por um grande volume de requisições de leitura em hotkeys. Nota Você pode ativar esse recurso definindo o parâmetro query_cache_enabled parameter. Esse recurso está disponível apenas para instâncias Tair Memory-optimized e Persistent Memory-optimized.
Suporte a múltiplos bancos de dados (DBs)	No modo cluster, o Redis nativo e os clientes de cluster não oferecem suporte a múltiplos bancos de dados (DBs). Eles utilizam apenas o banco de dados padrão `0` e não suportam o comando `SELECT`. No entanto, ao conectar-se a uma instância de cluster por meio de um nó de proxy, é possível utilizar múltiplos DBs e o comando `SELECT`. As instâncias Cluster Edition oferecem suporte a 256 DBs por padrão. Nota Se você utilizar um cliente StackExchange.Redis, é necessário usar a versão 2.7.20 ou posterior. Caso contrário, um erro ocorrerá. Para mais informações, consulte o StackExchange.Redis upgrade announcement.

Nota

À medida que a tecnologia de proxy evolui, o número de nós de proxy não é o único fator que determina a capacidade de processamento. A Alibaba Cloud garante que a proporção de nós de proxy em uma instância de cluster atenda aos requisitos especificados.

Regras de roteamento dos nós de proxy

Nota

Para mais informações sobre comandos, consulte Command overview.

Arquitetura	Regra de roteamento	Descrição
Arquitetura de cluster	Regras básicas de roteamento	Para comandos que operam em uma única chave, o nó de proxy envia a requisição ao shard de dados correspondente com base no slot ao qual a chave pertence. Para comandos que operam em múltiplas chaves armazenadas em diferentes shards de dados, o nó de proxy divide o comando em múltiplos comandos e os envia aos shards correspondentes. Nota A partir do Redis Open-Source Edition 5.0.1, e nas versões 6.0, 7.0 e posteriores, os nós de proxy dividem os comandos no nível de slot, de forma consistente com a comunidade Redis. No entanto, em versões secundárias do Redis Open-Source Edition 5.0 anteriores à 5.0.1, e nas versões 4.0 e 2.8, o Proxy divide os comandos no nível de shard. Quando essas instâncias são atualizadas para o Redis Open-Source Edition 5.0 ou posterior, a mudança nas regras de divisão de comandos pode causar um aumento no QPS e um leve aumento no tráfego. No entanto, como o Proxy entrega os comandos por meio de pipeline, o impacto no desempenho é relativamente pequeno.
Arquitetura de cluster	Regras de roteamento para comandos específicos	Comandos Pub/Sub Para comandos Pub/Sub, como SUBSCRIBE, o nó de proxy calcula um hash do nome do canal e roteia a requisição ao shard de dados correspondente. Embora os comandos Pub/Sub não gravem dados no banco de dados, eles ainda consomem memória e recursos. Esse consumo se deve principalmente a conexões de clientes, gerenciamento do estado de assinatura e buffers de mensagens. Por exemplo, se um canal pertence ao shard de dados 1, os clientes que se inscrevem nesse canal consomem memória, CPU e largura de banda de rede do shard de dados 1. Nota No console do Tair, acesse a página Performance Monitoring, selecione Data Node e, em seguida, selecione Pub/Sub Monitoring Group na lista de métricas personalizadas. Isso permite visualizar informações de monitoramento dos comandos Pub/Sub em cada shard de dados. Por padrão, os dados do primeiro shard de dados são exibidos. Comandos desenvolvidos pela Alibaba Cloud Ao utilizar comandos desenvolvidos pela Alibaba Cloud, como IINFO e ISCAN, é possível especificar o ID do shard de dados por meio do parâmetro idx. O nó de proxy então envia esses comandos ao shard de dados especificado. Para mais informações, consulte Alibaba Cloud-developed proxy commands.
Arquitetura de separação de leitura/escrita	Regras básicas de roteamento	Requisições de escrita: o nó de proxy encaminha as requisições de escrita diretamente ao nó master. Requisições de leitura: o nó de proxy distribui as requisições de leitura de forma uniforme entre o nó master e as réplicas de leitura. Não é possível personalizar a distribuição. Por exemplo, em uma instância com um nó master e três réplicas de leitura, cada um dos quatro nós processa 25% das requisições de leitura. Nota SLOWLOG e DBSIZE também são considerados comandos de leitura.
Arquitetura de separação de leitura/escrita	Regras de roteamento para comandos específicos	Comandos SCAN Ao executar os comandos HSCAN, SSCAN ou ZSCAN, o nó de proxy primeiro calcula o slot ao qual a chave pertence. Em seguida, utiliza uma operação de módulo para determinar o nó de destino. Isso garante que as requisições sejam distribuídas de forma uniforme entre o nó master e as réplicas de leitura. Comandos desenvolvidos pela Alibaba Cloud Ao utilizar comandos desenvolvidos pela Alibaba Cloud, como RIINFO e RIMONITOR, use o parâmetro ro_slave_idx para especificar a réplica de leitura de destino e o parâmetro idx para especificar o shard de dados. Para mais informações, consulte Alibaba Cloud-developed proxy commands. Outros comandos O nó de proxy encaminha comandos de transação (MULTI ou EXEC), comandos de scripts Lua (EVAL ou EVALSHA), SCAN, INFO e comandos Pub/Sub (como PUBLISH e SUBSCRIBE) ao nó master.

Proxy query cache

Os nós de proxy podem armazenar em cache requisições que contêm hotkeys e seus respectivos resultados de consulta. Quando um nó de proxy recebe a mesma requisição dentro do período de validade do cache, ele retorna o resultado diretamente ao cliente sem interagir com os shards de dados no backend. Esse recurso pode mitigar ou evitar a degradação de desempenho causada pela assimetria de acesso decorrente de um alto volume de requisições de leitura em hotkeys.

O kernel do banco de dados identifica uma hotkey por meio de algoritmos de ordenação e estatísticos, de forma semelhante ao Hot Key (QPS) do recurso Top Key Analytics. Por padrão, uma chave é identificada como hotkey quando seu QPS ultrapassa 5.000. Você também pode personalizar esse limiar por meio do parâmetro bigkey-threshold.
Se uma hotkey for modificada enquanto seus dados estiverem em cache, as alterações não serão sincronizadas com o cache. Isso significa que requisições subsequentes podem ler dados desatualizados do cache até que a entrada expire. Você pode reduzir o período de validade do cache de acordo com as necessidades do seu negócio.

Nota

Os nós de proxy não armazenam a hotkey inteira em cache. Em vez disso, eles armazenam as requisições que contêm a hotkey e os resultados de consulta correspondentes.
Esse recurso está disponível apenas para instâncias Tair Memory-optimized e Persistent Memory-optimized que utilizam a arquitetura de cluster no modo proxy ou a arquitetura de separação de leitura/escrita.

Casos de uso

Esse recurso é adequado para cenários como listas de assuntos em alta, perfis de usuários populares e anúncios de jogos, nos quais as aplicações toleram dados levemente desatualizados.

Arquitetura

Utilização

Esse recurso está desabilitado por padrão. Para ativá-lo, defina o parâmetro query_cache_enabled parameter.

Parâmetros

Parâmetro	Descrição

query_cache_enabled	query_cache_enabled: especifica se o recurso deve ser ativado. Os valores válidos são 0 (desabilitado, padrão) e 1 (habilitado). query_cache_expire: o período de validade dos dados em cache. A unidade é milissegundos. O intervalo é [100-60000]. O valor padrão é 1000. Se os dados em cache forem modificados durante o período de validade, as alterações não serão sincronizadas com o cache. Isso significa que a mesma requisição de leitura retornará dados desatualizados do cache até que ele expire. Avalie cuidadosamente o valor desse parâmetro com base no cenário específico do seu negócio e na tolerância a dados desatualizados. Definir um valor muito baixo reduz a taxa de acerto do cache, enquanto um valor muito alto faz com que os clientes leiam dados desatualizados por mais tempo. query_cache_mode: o modo de operação do recurso de proxy query cache. Valores válidos: 0 (padrão): armazena em cache apenas as hotkeys enviadas pelos shards de dados. 1: armazena em cache todas as chaves e as remove com base no algoritmo Least Recently Used (LRU). Como o espaço de cache de um nó de proxy é limitado (100 MB por thread), ao definir esse parâmetro como 1, o nó de proxy removerá chaves de acordo com o algoritmo LRU. Isso pode reduzir a taxa de acerto do cache e causar queda no desempenho geral.
query_cache_expire
query_cache_mode

Você pode usar os comandos QUERYCACHE KEYS, QUERYCACHE INFO e QUERYCACHE LISTALL, desenvolvidos pelo Tair, para visualizar a utilização do proxy query cache do Tair.

Comandos

QUERYCACHE KEYS

Sintaxe: QUERYCACHE KEYS

Descrição: consulta todas as hotkeys em cache nos nós de proxy. O comando retorna o nome do banco de dados e o nome da chave para cada hotkey.

Exemplo:

QUERYCACHE KEYS

Resposta de exemplo:

1) 1) (integer) 0
   2) "key:000000000003"
2) 1) (integer) 0
   2) "key:000000000001"
3) 1) (integer) 0
   2) "key:000000000002"
4) 1) (integer) 0
   2) "key:000000000000"

QUERYCACHE INFO

Sintaxe: QUERYCACHE INFO

Descrição: obtém o status operacional do proxy query cache.

Exemplo:

QUERYCACHE INFO

Resposta de exemplo:

1) "put_qps:4.00"
2) "get_qps:16570.00"
3) "hit_rate:99.98"
4) "memory_size:180"
5) "query_count:4"
6) "bandwidth_limit_query_cnt:0"
7) "qps_limit_query_cnt:0"

Campos da resposta:

put_qps: número de escritas no proxy query cache provenientes dos nós de dados por segundo.
get_qps: número de leituras do proxy query cache pelos clientes por segundo.
hit_rate: taxa de acerto do cache.
memory_size: uso de memória dos dados em cache, em bytes.
query_count: número de requisições em cache.
bandwidth_limit_query_cnt: número de vezes que o acesso ao proxy query cache foi limitado devido a restrições de largura de banda. O throttling está desabilitado por padrão.
qps_limit_query_cnt: número de vezes que o acesso ao proxy query cache foi limitado devido a restrições de QPS. O throttling está desabilitado por padrão.

QUERYCACHE LISTALL

Sintaxe: QUERYCACHE LISTALL

Descrição: obtém todos os comandos de requisição em cache.

Exemplo:

QUERYCACHE LISTALL

Resposta de exemplo:

1) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000000\r\n"
   3) (integer) 668
2) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000001\r\n"
   3) (integer) 668
3) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000003\r\n"
   3) (integer) 668
4) 1) (integer) 0
   2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000002\r\n"
   3) (integer) 667

Descrição da resposta de exemplo: as informações de cada comando de requisição consistem em três linhas: o nome do banco de dados, o conteúdo completo do comando de requisição (formatado de acordo com a especificação do protocolo Redis) e o tempo de vida restante (TTL) em milissegundos.

Uso de conexões

Normalmente, um nó de proxy estabelece conexões persistentes com os shards de dados para processar requisições. No entanto, quando uma requisição inclui um dos comandos a seguir, o nó de proxy cria conexões adicionais e não agregáveis nos shards de dados correspondentes com base nos requisitos do comando. Nesses casos, o número máximo de conexões da instância é limitado pelo limite de conexões de um único shard de dados. Para saber o limite de conexões de um único shard, consulte as especificações da sua instância. Utilize esses comandos com cuidado para evitar exceder o limite de conexões.

Nota

No modo proxy, o número máximo de conexões para cada shard de dados é 10.000 para instâncias Redis Open-Source Edition e 30.000 para instâncias Tair (Enterprise Edition).

Comandos de bloqueio: BRPOP, BRPOPLPUSH, BLPOP, BZPOPMAX, BZPOPMIN, BLMOVE, BLMPOP e BZMPOP.
Comandos de transação: MULTI, EXEC e WATCH.
Comandos MONITOR: MONITOR, IMONITOR e RIMONITOR.
Comandos de assinatura: SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, SSUBSCRIBE e SUNSUBSCRIBE.

Perguntas frequentes

É possível encaminhar scripts Lua que executam apenas operações de leitura para réplicas de leitura?
Sim, é possível encaminhar scripts Lua que executam apenas operações de leitura para réplicas de leitura. No entanto, os seguintes requisitos devem ser atendidos:
- Uma conta somente leitura deve ser utilizada. Para mais informações, consulte Create and manage accounts.
- O parâmetro readonly_lua_route_ronode_enable deve estar definido como 1 na sua instância Tair. O valor 1 indica que scripts Lua que executam apenas operações de leitura são roteados para réplicas de leitura. Para mais informações, consulte Configure instance parameters.
P: Qual é a diferença entre o modo proxy e o modo de conexão direta? Qual modo é recomendado?
R: Recomendamos o modo proxy. As diferenças são as seguintes:
- Modo proxy: os nós de proxy encaminham as requisições dos clientes para os shards de dados. Esse modo oferece recursos como balanceamento de carga, separação de leitura/escrita, failover, proxy query cache e conexões persistentes.
- Modo de conexão direta: você pode usar um endpoint de conexão direta para ignorar os nós de proxy e conectar-se diretamente aos shards de dados no backend. Esse modo é semelhante a conectar-se a um cluster Redis nativo. Em comparação com o modo proxy, o modo de conexão direta reduz a sobrecarga de processamento do proxy e melhora a latência de resposta.

P: Como as leituras e escritas de dados são afetadas se um shard de dados no backend ficar indisponível?

Cada shard de dados utiliza uma arquitetura de alta disponibilidade master-réplica. Se um nó master falhar, o sistema realiza automaticamente um failover para garantir a alta disponibilidade. A tabela a seguir descreve o impacto de uma falha de shard de dados nas leituras e escritas em cenários extremos e apresenta soluções de otimização.

Cenário	Impacto e otimização
Figura 1. Comandos multi-key	Impacto: Um cliente envia quatro requisições por meio de quatro conexões. Se o shard de dados 2 ficar indisponível, apenas a Requisição 1 (GET Key1) conseguirá ler os dados com sucesso. As requisições roteadas ao shard de dados 2 expiram por timeout. Otimização: Reduza o uso de comandos multi-key, como MGET, ou diminua o número de chaves em uma única requisição. Isso evita que a requisição inteira falhe devido à indisponibilidade de um único shard de dados. Reduza o uso de comandos de transação ou diminua o tamanho das transações. Isso evita que a falha de uma subtransação comprometa a transação inteira.
Figura 2. Conexão única	Impacto: Um cliente envia duas requisições separadas por meio de uma única conexão. Se o shard de dados 2 ficar indisponível, a Requisição 2 (GET Key2) expira por timeout. Como a Requisição 1 (GET Key1) compartilha a mesma conexão, ela também falha ao retornar um resultado. Otimização: Evite ou reduza o uso de pipeline. Evite clientes que suportam apenas uma única conexão. Recomendamos o uso de clientes que suportem pool de conexões. Para mais informações, consulte Client connection tutorial. Certifique-se de configurar um timeout e um tamanho de pool de conexões adequados.