Autor: Himalaya Dong Daoguang
Declaração: O cache não é uma panacéia, nem uma lata de lixo! ! !
Como um dos componentes básicos mais importantes do Ximalaya, o cache carrega uma enorme quantidade de solicitações de negócios todos os dias. Se o cache falhar, o impacto nos negócios será muito sério. Portanto, garantir o funcionamento estável e eficiente do serviço de cache é sempre um objetivo importante para nós.
A seguir está um conjunto de especificações de uso de cache que resumimos após revisar o histórico de falhas de cache Xima. Gostaríamos de compartilhá-las com você. Esperamos que amigos possam evitar armadilhas no processo de seleção e uso de cache.
1. Seleção de cache
1.1 Introdução aos tipos de cache
Existem quatro tipos principais de cache online Xima:
1. modo redis master-slave : versão original oficial
2. codis -redis : código aberto Wandoujia, solução de cluster redis
3. Redis de banco de dados em nuvem : implantação de contêiner de cluster redis
4.xcache : um conjunto de soluções de armazenamento KV massivo autodesenvolvidas baseadas em codis, pika e redis
1.2 Introdução ao modelo de uso de cache
Existem dois modos de uso principais:
1. Modo de cache : os dados não precisam ser persistidos, a recuperação da instância não precisa carregar dados e a expansão e contração não exigem migração de dados.
2. Modo de armazenamento : os dados precisam ser persistidos, a recuperação da instância precisa carregar os dados e a expansão e contração precisam migrar os dados.
A seguir está uma comparação simples de vários tipos de cache:
2. Regras de uso de cache
2.1 Especificações de uso do tipo de cache
1) O redis de banco de dados em nuvem é preferido para o modo de cluster redis e o xcache é preferido para armazenamento KV massivo.
O redis de banco de dados em nuvem adota o modo de cluster redis oficial, implantação em contêiner, suporta recuperação automática de falhas e escalonamento elástico e é a principal solução para o cluster redis atual. No entanto, não oferece suporte à persistência de dados. Se a persistência de dados for necessária, e o atraso os requisitos são muito altos. Alto, você pode usar o codis redis. A quantidade de dados é muito grande e os requisitos de latência não são particularmente altos. Você pode escolher xcache.
2) Não use redis como db.Se os dados precisarem ser persistidos, você pode escolher xcache.
Quando o redis é usado como banco de dados, a recuperação dos dados após a falha é muito lenta, afetando seriamente o SLA. E se o mestre e o escravo desligarem e a máquina escrava não puder ser restaurada, os dados serão completamente perdidos. xcache suporta naturalmente persistência de dados
3) Não use o modo de fragmentação do lado do cliente
O modo de fragmentação do cliente não possui alta disponibilidade e capacidade de escalonamento elástico. Recomenda-se usar o modo de cluster real, como codis-redis, banco de dados em nuvem redis, xcache
4) O modo cluster não oferece suporte a clientes lua e redisson. Se a empresa precisar usá-lo, você só poderá escolher o modo redis mestre-escravo.
5) A capacidade de um único nó de redis não deve exceder 10 GB, e a capacidade de um único nó de xcache não deve exceder 200 GB.
Quando a capacidade do nó Redis único for muito grande, a reinicialização da instância será lenta, afetando o tempo de recuperação.
2.2 Especificações de design de valor-chave
1) A chave deve ser mantida tão simples, legível e gerenciável quanto possível
Sob a premissa de garantir a semântica, controle o comprimento da chave ; use o nome da empresa (ou nome do banco de dados) como prefixo (para evitar conflitos de chave), separados por dois pontos, como nome da empresa: nome da tabela: id; não inclua caracteres especiais
2) Rejeite bigkey para evitar tráfego excessivo na placa de rede e consultas lentas
O tipo de string é controlado dentro de 10 KB e o número de elementos hash, list, set e zset não deve exceder 5.000.
3) Evite teclas de atalho
As teclas de atalho causarão distorção de dados e pressão excessiva em um único nó. Recomenda-se que o lado comercial disperse as teclas de atalho.
4) Controle o ciclo de vida da chave
O cache não é uma lata de lixo , é melhor definir o ttl para todas as chaves e dispersar o ttl das chaves para evitar a expiração centralizada da chave
2.3 Especificações de uso de comandos
1) Use comandos de operação completos com cuidado
Desative o comando `keys *` e tente não usar hgetall, smembers e outros comandos. Ao obter vários elementos sob a chave, use o comando de varredura correspondente para obter um pequeno número de elementos de uma vez e obtê-los várias vezes. Recomenda-se que não mais de 200 elementos sejam verificados de uma vez.
2) Controle o número de elementos de operação única de mset, mget, hmset, hmget, *scan, *range e outros comandos, é recomendado não exceder 200
3) Controle a quantidade de comandos no pipeline, é recomendado não ultrapassar 100
4) Quando o redis exclui a chave, não use o comando del, use o comando unlink
Excluir uma chave grande fará com que o redis fique preso diretamente. A chave pode ser excluída de forma assíncrona usando o comando unlink, o que não afetará o thread principal do Redis e, portanto, não afetará o tráfego comercial.
5) Os comandos set e expire são mesclados no comando setex para reduzir a pressão de escrita no servidor
6) evalsha em vez de eval
Use evalsha em vez de eval no cluster redis-cluster para reduzir a E/S da rede e também reduzir a pressão da E/S da rede redis para melhorar o desempenho
2.4 Especificações da arquitetura de cache comercial
1) redis não usa banco de dados lógico , usa apenas o banco de dados padrão 0
Pode ser isolado por meio de instâncias, e dados de diferentes negócios podem ser salvos em diferentes instâncias. (Apenas redis mestre e escravo podem selecionar banco de dados lógico, o modo cluster usa db0 por padrão)
2) Evite vários serviços reutilizando os mesmos recursos de cache
Use clusters diferentes para dados de serviços diferentes. Não misture aplicativos de nível S com aplicativos de nível B. Se muitos serviços reutilizarem o mesmo recurso, eles deverão ser divididos. As empresas devem tentar o seu melhor para fornecer interfaces RPC para outras empresas ligarem, em vez de permitir diretamente que outras empresas acessem a fonte de dados (como uma escrita comercial e outra leitura).
3) xcache tenta usar o tipo string
xcache suporta seis tipos de dados:string,hash,ehash,list,set e zset.O tipo de dados ehash é uma extensão do tipo de dados hash e suporta a definição do tempo de expiração dos campos. O tipo de string no xcache é o mais rápido, e outros tipos de dados são realizados combinando e transformando strings. O desempenho dos seis tipos de dados é o seguinte:
string > hash > set > ehash > lista > zset
Sugestão: Tente usar o tipo string
4) Reduza o uso de scripts lua
O modo cluster possui restrições ao suporte Lua, e deve-se garantir que as chaves operadas em Lua sejam fragmentadas no mesmo nó. Então tente reduzir o uso de lua tanto quanto possível
5) Nenhuma lógica complexa é executada em scripts Lua
Coloque lógica complexa no código comercial em vez de scripts Lua
6) Use métodos de serialização e métodos de compactação eficientes
Para economizar memória, se o valor for grande, você pode usar ferramentas de compactação (como snappy ou gzip) para compactar os dados e depois gravá-los no redis
7) Evite muito tráfego de tarefas em lote, tarefas agendadas e tarefas periódicas que afetam os negócios online
Tarefas em lote, tarefas agendadas e tarefas periódicas devem ter velocidade limitada
8) Mudanças nos negócios, mudanças no modelo de tráfego de armazenamento devem ser avaliadas primeiro
Mudanças no modelo de negócios, QPS, aumento de capacidade, aumento de comandos O (N), etc. devem primeiro avaliar se o cache atual pode suportá-lo, ficar online em escala de cinza e continuar a observar (especialmente durante períodos de pico de tráfego )
9) Solicite a reciclagem de recursos não utilizados o mais rápido possível
A reciclagem de recursos inativos pode não apenas reduzir o custo de armazenamento do negócio, mas também alocar recursos para as empresas que realmente precisam deles. Pode-se dizer que é uma situação vantajosa para todos.
Suplemento: OpenAtom Open Source Contest As perguntas da competição Pika são lançadas, com um prêmio de 500.000. Por favor, leia o seguinte código QR para se registrar :
Você também pode adicionar o assistente Pika e ingressar no grupo Pika WeChat para saber mais notícias dinâmicas:
