Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.
Atualizado em 2023-12-20 GMT+08:00

Novos recursos do DCS for Redis 5.0

O DCS for Redis 5.0 é compatível com os novos recursos do Redis 5.0 de código aberto, além de todas as melhorias e novos comandos no Redis 4.0.

Estrutura de dados do Stream

Stream é um novo tipo de dados introduzido com o Redis 5.0. Suporta persistência de mensagens e multicast.

Figura 1 mostra a estrutura de um Stream do Redis, que permite que as mensagens sejam anexadas ao fluxo.

Streams têm os seguintes recursos:
  1. Um Stream pode ter vários grupos de consumidores.
  2. Cada grupo de consumidores contém um Last_delivered_id que aponta para o último item consumido (mensagem) no grupo de consumidores.
  3. Cada grupo de consumidores contém vários consumidores. Todos os consumidores compartilham o last_delivered_id do grupo de consumidores. Uma mensagem pode ser consumida por apenas um consumidor.
  4. pending_ids no consumidor pode ser usado para registrar os IDs de itens que foram enviados ao cliente, mas não foram confirmados.
  5. Para uma comparação detalhada entre o Stream e outras estruturas de dados do Redis, consulte Tabela 1.
Figura 1 Estrutura de dados de Stream
Tabela 1 Diferenças entre Streams e estruturas de dados de Redis existentes

Item

Stream

List, Pub/Sub, Zset

Complexidade da busca de itens

O(log(N))

List: O(N)

Offset

Compatível. Cada item tem um ID exclusivo. O ID não é alterado à medida que outros itens são adicionados ou despejados.

List: incompatível. Se um item for despejado, o item mais recente não poderá ser localizado.

Persistência

Compatível. Streams são persistidos para arquivos AOF e RDB.

Pub/Sub: incompatível.

Grupo de consumidor

Compatível.

Pub/Sub: incompatível.

Reconhecimento

Compatível.

Pub/Sub: incompatível.

Desempenho

Não tem relação com o número de consumidores.

Pub/Sub: positivamente relacionado ao número de clientes.

Despejo

Streams são eficientes em memória, bloqueando para despejar os dados que são muito antigos e usando uma árvore radix e listpack.

O Zset consome mais memória porque não suporta inserir os mesmos itens, bloquear ou despejar dados

Excluir itens aleatoriamente

Incompatível.

Zset: compatível.

Comandos de Stream

Os comandos de Stream são descritos abaixo na ordem em que são usados. Para mais detalhes, consulte Tabela 2.
  1. Execute o comando XADD para adicionar um item de fluxo, ou seja, criar um Stream. O número máximo de mensagens que podem ser salvas pode ser especificado ao adicionar o item.
  2. Crie um grupo de consumidores executando o comando XGROUP.
  3. Um consumidor usa o comando XREADGROUP para consumir mensagens.
  4. Após o consumo, o cliente executa o comando XACK para confirmar que o consumo é bem sucedido.
Figura 2 Comandos de Stream
Tabela 2 Descrição dos comandos de Stream

Comando

Descrição

Sintaxe

XACK

Exclui uma ou várias mensagens da pending entry list (PEL) um grupo de consumidores do fluxo.

XACK key group ID [ID ...]

XADD

Adiciona uma entrada especificada ao fluxo em uma chave especificada. Se a chave não existir, executar este comando resultará em uma chave a ser criada automaticamente com base na entrada.

XADD key ID field string [field string ...]

XCLAIM

Altera a propriedade de uma mensagem pendente, para que o novo proprietário seja o consumidor especificado como argumento do comando.

XCLAIM key group consumer min-idle-time ID [ID ...] [IDLE ms] [TIME ms-unix-time] [RETRYCOUNT count] [FORCE] [JUSTID]

XDEL

Remove as entradas especificadas de um fluxo e retorna o número de entradas excluídas, que pode ser diferente do número de IDs passados ao comando no caso de determinados IDs não existirem.

XDEL key ID [ID ...]

XGROUP

Gerencia os grupos de consumidores associados a um stream. Você pode usar XGROUP para:

  • Criar um novo grupo de consumidores associado a um fluxo.
  • Destruir um grupo de consumidores.
  • Remover um consumidor especificado de um grupo de consumidores.
  • Definir o ID da última entrega do grupo de consumidores para outra coisa.

XGROUP [CREATE key groupname id-or-$] [SETID key id-or-$] [DESTROY key groupname] [DELCONSUMER key groupname consumername]

XINFO

Recupera informações diferentes sobre os fluxos e grupos de consumidores associados.

XINFO [CONSUMERS key groupname] key key [HELP]

XLEN

Retorna o número de entradas em um fluxo. Se a chave especificada não existir, 0 é retornado, indicando um fluxo vazio.

XLEN key

XPENDING

Obtém dados de um fluxo através de um grupo de consumidores. Esse comando é a interface para inspecionar a lista de mensagens pendentes para observar e entender quais clientes estão ativos, quais mensagens estão pendentes para serem consumidas ou para ver se há mensagens ociosas.

XPENDING key group [start end count] [consumer]

XRANGE

Retorna entradas correspondentes a um determinado intervalo de IDs.

XRANGE key start end [COUNT count]

XREAD

Lê dados de um ou vários fluxos, retornando apenas entradas com um ID maior que o último ID recebido informado pelo chamador.

XREAD [COUNT count] [BLOCK milliseconds] STREAMS key [key ...] ID [ID ...]

XREADGROUP

Uma versão especial do comando XREAD, que é usada para especificar um grupo de consumidores para ler.

XREADGROUP GROUP group consumer [COUNT count] [BLOCK milliseconds] STREAMS key [key ...] ID [ID ...]

XREVRANGE

Este comando é exatamente como XRANGE, mas com a diferença notável de retornar as entradas na ordem inversa e também tomar o intervalo de início-fim na ordem inversa.

XREVRANGE key end start [COUNT count]

XTRIM

Apara o fluxo para um número especificado de itens, se necessário, despejando itens antigos (itens com IDs inferiores).

XTRIM key MAXLEN [~] count

Confirmação de mensagem (item de fluxo)

Em comparação com o Pub/Sub, Streams não apenas suportam grupos de consumidores, mas também o reconhecimento de mensagens.

Quando um consumidor invoca o comando XREADGROUP para ler ou invoca o comando XCLAIM para assumir uma mensagem, o servidor não sabe se a mensagem é processada pelo menos uma vez. Portanto, depois de ter processado com sucesso uma mensagem, o consumidor deve invocar o comando XACK para notificar o Stream de modo que a mensagem não será processada novamente. Além disso, a mensagem é removida do PEL e a memória será liberada do servidor Redis.

Em alguns casos, como falhas de rede, o cliente não invoca XACK após o consumo. Nesses casos, o ID do item é mantido no PEL. Depois que o cliente é reconectado, defina o ID da mensagem inicial de XREADGROUP para 0-0, indicando que todas as mensagens PEL e mensagens após last_id são lidas. Além disso, a transmissão repetida de mensagens deve ser suportada quando os consumidores consomem mensagens.

Figura 3 Mecanismo de reconhecimento

Otimização do uso da memória

O uso de memória do Redis 5.0 é otimizado com base na versão anterior.

  • Desfragmentação ativa

    Se uma chave for modificada com frequência e o comprimento do valor mudar constantemente, o Redis alocará memória adicional para a chave. Para obter alto desempenho, o Redis usa o alocador de memória para gerenciar a memória. A memória nem sempre é liberada para o sistema operacional. Como resultado, ocorrem fragmentos de memória. Se a taxa de fragmentação (used_memory_rss/used_memory) for maior que 1,5, o uso da memória é ineficiente.

    Para reduzir fragmentos de memória, planeje e use adequadamente os dados de cache e padronize a gravação de dados.

    Para o Redis 3.0 e versões anteriores, os problemas de fragmentação de memória são resolvidos reiniciando o processo regularmente. Recomenda-se que os dados de cache reais não excedam 50% da memória disponível.

    Para o Redis 4.0, a desfragmentação ativa é suportada e a memória é desfragmentada enquanto estiver on-line. Além disso, o Redis 4.0 oferece suporte à desfragmentação manual de memória executando o comando memory purge.

    Para o Redis 5.0, a desfragmentação ativa aprimorada é compatível com o Jemalloc atualizado, que é mais rápido, mais inteligente e oferece menor latência.

  • Melhorias na implementação do HyperLogLog

    Um HyperLogLog é uma estrutura de dados probabilística usada para calcular a cardinalidade de um conjunto enquanto consome pouca memória. O Redis 5.0 melhora o HyperLogLog otimizando ainda mais o uso da memória.

    Por exemplo: a árvore B é eficiente na contagem, mas consome muita memória. Ao usar o HyperLogLog, é possível economizar muita memória. Enquanto a árvore B requer 1 MB de memória para contagem, o HyperLogLog precisa de apenas 1 KB.

  • Estatísticas de memória aprimoradas

    A informação retornada pelo comando INFO é mais detalhada.

Novos e melhores comandos

  1. Gerenciamento aprimorado de clientes
    • O redis-cli suporta o gerenciamento de cluster.

      No Redis 4.0 e versões anteriores, o módulo redis-trib precisa ser instalado para gerenciar clusters.

      O Redis 5.0 otimiza o redis-cli, integrando todas as funções de gerenciamento de cluster. Você pode executar o comando redis-cli --cluster help para obter mais informações.

    • O desempenho do cliente é aprimorado em cenários frequentes de conexão e desconexão.

      Essa otimização é valiosa quando sua aplicação precisa usar conexões curtas.

  2. Uso mais simples de conjuntos ordenados

    Os comandos ZPOPMIN e ZPOPMAX são adicionados para os conjuntos ordenados.

    • ZPOPMIN key [count]

      Remove e retorna até count os membros com as pontuações mais baixas no conjunto classificado armazenado na key. Ao retornar vários elementos, aquele com a pontuação mais baixa será o primeiro, seguido pelos elementos com pontuações mais altas.

    • ZPOPMAX key [count]

      Remove e retorna até count os membros com as pontuações mais altas no conjunto classificado armazenado na key. Ao retornar vários elementos, aquele com a pontuação mais baixa será o primeiro, seguido pelos elementos com pontuações mais baixas.

  3. Mais subcomandos adicionados ao comando help

    O comando help pode ser usado para visualizar informações de ajuda, poupando-lhe o trabalho de visitar redis.io todas as vezes. Por exemplo, execute o seguinte comando para exibir as informações de ajuda do stream: xinfo help

    127.0.0.1:6379> xinfo help
    1) XINFO <subcommand> arg arg ... arg. Subcommands are:
    2) CONSUMERS <key> <groupname>  -- Show consumer groups of group <groupname>.
    3) GROUPS <key>                 -- Show the stream consumer groups.
    4) STREAM <key>                 -- Show information about the stream.
    5) HELP                         -- Print this help.
    127.0.0.1:6379> 
  4. Dicas de entrada de comandos redis-cli

    Depois de inserir um comando completo, o redis-cli exibe uma dica de parâmetro para ajudá-lo a memorizar o formato de sintaxe do comando.

    Como mostrado na figura a seguir, execute o comando zadd e o redis-cli exibe a sintaxe zadd na cor clara.

RDB que armazena informações de LFU e LRU

No Redis 5.0, as políticas de remoção de chaves de armazenamento LRU e LFU foram adicionadas ao arquivo de snapshot do RDB.

  • FIFO: primeiro a entrar, primeiro a sair. Os primeiros dados armazenados são despejados primeiro.
  • LRU: menos usado recentemente. Os dados que não são usados há muito tempo são despejados primeiro.
  • LFU: menos frequentemente usado. Os dados usados com menos frequência são despejados primeiro.

O formato de arquivo RDB do Redis 5.0 foi modificado e é compatível com versões anteriores. Portanto, se um snapshot for usado para migração, os dados poderão ser migrados das versões anteriores do Redis para o Redis 5.0, mas não poderão ser migrados do Redis 5.0 para as versões anteriores.