Handle cluster data skew - Tair (Redis® OSS-Compatible): Central de Documentação do Alibaba Cloud

Se métricas de desempenho como uso de memória, utilização de CPU e uso de largura de banda em nós de dados específicos de uma instância de cluster Tair (Redis OSS-compatible) estiverem muito mais altas do que nos demais nós, a instância pode apresentar problemas de desvio de dados. Quando o desvio é severo, podem ocorrer exceções como evicção de chaves, erros de falta de memória (OOM) e respostas lentas, mesmo que o uso geral de memória da instância esteja baixo.

Tratamento rápido

Esta seção descreve como confirmar a existência de desvio de dados e como identificar e tratar chaves grandes.

No painel de navegação à esquerda da página de detalhes da instância, escolha CloudDBA > Real-time Performance para verificar se a métrica Memory Usage está equilibrada entre os nós de dados.

Neste exemplo, o Memory Usage no nó de dados db-0 é significativamente maior do que nos outros, indicando desvio de dados. Por exemplo, há desvio se o Memory Usage de um nó for 57% (9,22 GB) enquanto os demais estiverem em 33% (5,32 GB).

Nota
Você também pode usar o recurso de diagnóstico da instância para verificar se existe desvio de dados na instância atual. Para mais informações, consulte Perform diagnostics on an instance.
Visualize o número total de chaves de cada nó de dados.

Neste exemplo, o número total de chaves é de 2,59 milhões em db-0, 2,60 milhões em db-1 e 2,59 milhões em db-2. As chaves estão distribuídas uniformemente entre os nós de dados. Nesse caso, é muito provável que o nó de dados db-0 possua chaves grandes.

Nota
Se as chaves estiverem distribuídas de forma desigual entre os nós de dados, isso pode indicar um problema no design dos nomes das chaves na sua lógica de negócios. Por exemplo, o uso de hash tags pode fazer com que o cliente direcione todas as chaves para o mesmo nó de dados quando o algoritmo Cyclic Redundancy Check (CRC) é usado para distribuição. Nesse cenário, faça ajustes no nível da aplicação para evitar o uso de {} nos nomes das chaves.
Use o recurso offline key analysis para identificar rapidamente chaves grandes.

Esse recurso analisa os arquivos de backup da instância sem afetar os negócios online. Após a conclusão da análise, visualize as top 500 large keys. Neste exemplo, a chave chamada mylist foi identificada como uma chave grande.

Essa chave do tipo list usa codificação quicklist, consome 3,80 GB de memória e contém cerca de 2,04 milhões de elementos.
(Opcional) Conecte-se a um nó de dados específico para consulta e análise.
- Para uma instância de cluster no modo proxy, execute o comando SCAN no nó de dados especificado usando o comando ISCAN, desenvolvido internamente pela Alibaba Cloud. Para mais informações, consulte In-house commands for instances in proxy mode.
- Para uma instância de cluster no modo de conexão direta, chame a operação DescribeDBNodeDirectVipInfo para obter o endereço IP virtual (VIP) de cada nó de dados e conecte o cliente ao nó para análise.
Adote uma das seguintes soluções:
- Solução provisória: atualize as especificações da instância.
- Solução de longo prazo (recomendada): reestruture a lógica de negócios dividindo adequadamente as chaves grandes.

Para mais informações sobre as causas e soluções para problemas de desvio de dados, consulte a seção a seguir. Este tópico também é útil para solucionar problemas relacionados a métricas de desempenho elevadas, como uso de memória, utilização de CPU, uso de largura de banda e latência em instâncias padrão.

Por que ocorre desvio de dados?

As instâncias de cluster Tair (Redis OSS-compatible) utilizam uma arquitetura distribuída. O espaço de armazenamento de uma instância de cluster é dividido em 16.384 slots. Cada nó de dados armazena e processa os dados em slots específicos. Por exemplo, em uma instância de cluster com 3 shards, os slots são distribuídos entre os três shards da seguinte forma: o primeiro shard gerencia os slots no intervalo [0,5460], o segundo shard gerencia os slots no intervalo [5461,10922] e o terceiro shard gerencia os slots no intervalo [10923,16383]. Ao gravar ou atualizar uma chave em uma instância de cluster, o cliente determina o slot ao qual a chave pertence usando a seguinte fórmula: Slot=CRC16(key)%16384. Em seguida, o cliente grava a chave nesse slot. Teoricamente, esse mecanismo distribui as chaves uniformemente entre os nós de dados, sendo suficiente para manter métricas como uso de memória e utilização de CPU praticamente no mesmo nível em todos os nós.

No entanto, na prática, o desvio de dados pode ocorrer devido à falta de planejamento prévio, gravações de dados incomuns ou picos de acesso aos dados.

Nota

Geralmente, o desvio de dados acontece quando a demanda por recursos em nós de dados específicos é maior do que nos demais. Visualize as métricas dos nós de dados na aba Data Node da página Performance Monitor no console. Se as métricas de um nó de dados forem consistentemente 20% maiores do que as dos outros nós, pode haver desvio de dados. A gravidade do desvio é proporcional à diferença entre as métricas do nó anômalo e as dos nós normais.
Quando o uso de memória de um único nó de dados atinge 100%, o nó aciona a evicção de dados. A política de evicção padrão é volatile-lru.

A figura a seguir mostra dois cenários típicos de desvio de dados. Embora as chaves estejam distribuídas uniformemente pela instância de cluster (duas chaves por nó de dados), o desvio ainda ocorre.

O número de consultas por segundo (QPS) para key1 no nó de dados Shard 1 é muito superior ao das outras chaves. Trata-se de um caso de desvio de acesso a dados, que pode levar a alta utilização de CPU e uso elevado de largura de banda no nó. Isso afeta o desempenho de todas as chaves nesse nó de dados.
O tamanho de key5 no nó de dados Shard 2 é de 1 MB, valor muito superior ao das demais chaves. Isso configura um caso de desvio de volume de dados, podendo resultar em alto consumo de memória e largura de banda no nó. Consequentemente, o desempenho de todas as chaves nesse nó de dados é afetado.

Soluções provisórias

Caso ocorra desvio de dados em uma instância, implemente uma solução provisória para mitigar o problema a curto prazo.

Problema	Possível causa	Solução provisória
Desvio de uso de memória	Chaves grandes e hash tags	Atualize as especificações da instância. Para mais informações, consulte Change instance configuration. Importante O sistema inicia uma verificação prévia de desvio de dados durante a alteração de especificações da instância. Se o tipo de instância selecionado não conseguir lidar com o problema de desvio, o sistema reportará um erro. Selecione um tipo de instância com especificações superiores e tente novamente. Após atualizar as especificações da instância, o desvio de uso de memória pode ser aliviado. No entanto, o desvio também pode ocorrer em recursos de largura de banda e CPU.
Desvio de uso de largura de banda	Chaves grandes, hotkeys e comandos intensivos em recursos	Aumente a largura de banda de um ou mais nós de dados. Para mais informações, consulte Manually increase instance bandwidth. Nota A largura de banda de um nó de dados pode ser aumentada em até seis vezes a largura de banda padrão da instância, mas o aumento não pode exceder 192 Mbit/s. Se essa medida ainda não resolver o problema de desvio de dados, recomendamos fazer ajustes no nível da aplicação.
Desvio de utilização de CPU	Chaves grandes, hotkeys e comandos intensivos em recursos	Se as hotkeys estiverem distribuídas em slots diferentes, adicione nós de dados fora dos horários de pico para balancear a carga de forma mais uniforme no sistema. Otimize comandos intensivos em recursos. Por exemplo, reduza o número de chaves recuperadas a cada comando SCAN. Nota Dimensione a instância fora dos horários de pico, pois o processo de migração de dados que ocorre durante o dimensionamento pode consumir recursos significativos de CPU.

Para resolver temporariamente o desvio de dados, também é possível reduzir as solicitações para chaves grandes e hotkeys. Para solucionar definitivamente problemas relacionados a chaves grandes e hotkeys, faça ajustes no nível da aplicação. Recomendamos identificar prontamente a causa do desvio de dados na sua instância e tratar o problema no nível da aplicação para otimizar o desempenho. Para mais informações, consulte a seção Causes and solutions deste tópico.

Causas e soluções

Para resolver a causa raiz do desvio de dados, avalie o crescimento dos seus negócios e faça os preparativos necessários para expansões futuras. Adote medidas para dividir chaves grandes e gravar dados de maneira alinhada ao uso esperado.

Causa	Descrição	Solução
Chaves grandes	Uma chave grande é identificada com base no seu tamanho e no número de membros que contém. Normalmente, chaves grandes são comuns em estruturas de dados chave-valor como Hash, List, Set e Zset. Elas surgem quando essas estruturas armazenam um grande número de campos ou campos excessivamente grandes. Chaves grandes são uma das principais causas de desvio de dados. Para mais informações sobre como excluir chaves grandes ou hotkeys de forma segura sem afetar seus negócios, consulte Identify and handle large keys and hotkeys.	Evite a ocorrência de chaves grandes. Divida uma chave hash que contenha dezenas de milhares de membros em várias chaves hash com uma quantidade gerenciável de membros.
Hotkeys	Hotkeys são chaves que possuem um valor de QPS muito superior ao das demais. São frequentemente encontradas durante testes de estresse em uma única chave ou em cenários de vendas relâmpago envolvendo IDs de produtos populares. Para mais informações sobre hotkeys, consulte Identify and handle large keys and hotkeys.	Previna a ocorrência de hotkeys. Utilize o recurso de cache de consulta do proxy para armazenar dados quentes em cache. Para mais informações, consulte Step 2: Optimize large and hot keys.
Comandos intensivos em recursos	Cada comando possui uma métrica chamada complexidade de tempo, que mede seu consumo de recursos e tempo. Na maioria dos casos, quanto maior a complexidade de tempo de um comando, mais recursos ele consome. Por exemplo, a complexidade de tempo do comando `HGETALL` é O(n). Isso indica que o comando consome recursos proporcionalmente ao número de campos especificados. Da mesma forma, se um comando `SET` ou `GET` envolver um grande volume de dados, ele consumirá muitos recursos do nó de dados.	Consulte os logs de consultas lentas do nó de dados. Para mais informações, consulte Query slow query logs. Use o recurso de insights de latência para visualizar os comandos que consomem muitos recursos de desempenho. Para mais informações, consulte Latency insights. Evite usar comandos intensivos em recursos. Para desabilitar comandos específicos, configure o parâmetro `#no_loose_disabled-commands` na página Parameter Settings.
Hash Tags	O Tair distribui chaves para nós de dados específicos com base no conteúdo contido na parte `{}` dos nomes das chaves. Por exemplo, as chaves `{item}id1`, `{item}id2` e `{item}id3` são armazenadas no mesmo nó de dados porque compartilham o mesmo conteúdo em `{}`. Como resultado, o uso de memória e o consumo de recursos desse nó de dados aumentam significativamente.	Não use `{}` nos nomes das chaves. Nota Se precisar usar `{}` nos nomes das chaves, garanta que chaves diferentes tenham conteúdos distintos dentro de `{}`. Dessa forma, as chaves serão armazenadas em vários nós de dados.

Perguntas frequentes

Em uma instância de cluster com chaves grandes, posso atualizar as especificações apenas do nó de dados onde uma chave grande reside?

Não. O Tair (Redis OSS-compatible) não permite atualizar as especificações de nós de dados individuais separadamente. Apenas atualizações simultâneas das especificações de todos os nós de dados da instância são permitidas.
Posso adicionar nós de dados e redistribuir chaves para eliminar chaves grandes em uma instância de cluster?

Não. Embora adicionar nós de dados possa ajudar a aliviar parte da pressão de memória dos nós existentes, o Tair (Redis OSS-compatible) distribui dados no nível da chave, o que significa que chaves grandes não podem ser divididas automaticamente. Consequentemente, após a redistribuição das chaves, um nó de dados ainda pode ter uso de memória maior do que os outros, resultando em desvio de dados. A abordagem recomendada é dividir manualmente as chaves grandes em chaves menores.