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.
- Um Stream pode ter vários grupos de consumidores.
- Cada grupo de consumidores contém um Last_delivered_id que aponta para o último item consumido (mensagem) no grupo de consumidores.
- 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.
- pending_ids no consumidor pode ser usado para registrar os IDs de itens que foram enviados ao cliente, mas não foram confirmados.
- Para uma comparação detalhada entre o Stream e outras estruturas de dados do Redis, consulte Tabela 1.
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
- 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.
- Crie um grupo de consumidores executando o comando XGROUP.
- Um consumidor usa o comando XREADGROUP para consumir mensagens.
- Após o consumo, o cliente executa o comando XACK para confirmar que o consumo é bem sucedido.
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:
|
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.
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
Novos e melhores comandos
- 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 redis-cli suporta o gerenciamento de cluster.
- 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.
- ZPOPMIN key [count]
- 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>
- 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.