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.

Central de ajuda/ Distributed Cache Service/ Visão geral de serviço/ Tipos de instância do DCS/ Comparando Tipos de Instância do DCS Redis

Atualizado em 2022-11-07 GMT+08:00

Ver PDF

Comparando Tipos de Instância do DCS Redis

Tabela 1 descreve as diferenças entre os diferentes tipos de instância do Redis em termos de recursos e comandos.

O DCS for Redis 3.0 não é mais fornecido. Em vez disso, você pode usar o DCS for Redis 4.0 ou 5.0.

**Tabela 1** Diferenças entre os tipos de instância de DCS
Item	Nó único ou principal/em espera	Cluster de proxy	Cluster do Redis
Compatibilidade da versão do Redis	Redis 3.0, 4.0 e 5.0 O Redis 6.0 é compatível com o KeyDB Open Source (disponível apenas para instâncias principal/em espera). Você pode selecionar uma versão ao criar uma instância.	Redis 3.0, 4.0 e 5.0	Redis 4.0 e 5.0 Você pode selecionar uma versão ao criar uma instância.
Apoio	Notificações do keyspace Pipelinização	Pipelining, comando MSET e comando MGET Comando SCAN, comando KEYS e registro lento do Redis Pub/Sub	Notificações do keyspace Comandos BRPOP, BLPOP e BRPOPLPUSH Pub/Sub
Restrições	A persistência de dados não é suportada para instâncias de nó único.	O script LUA é restrito: Todas as chaves devem estar no mesmo slot de hash para evitar erros. Hash tags são recomendadas. Se um comando contiver várias chaves, as chaves devem estar no mesmo hash slot para evitar erros. Hash tags são recomendadas. As notificações de keyspace não são suportadas.	O script LUA é restrito: Todas as chaves devem estar no mesmo hash slot. Hash tags são recomendadas. O SDK cliente deve oferecer suporte ao Redis Cluster e ser capaz de processar erros MOVED. Quando você estiver usando pipelining, comando MSET ou comando MGET, todas as chaves devem estar no mesmo slot de hash para evitar erros. Hash tags são recomendadas. Ao usar notificações de keyspace, estabeleça conexões com cada servidor Redis e processe eventos em cada conexão. Ao usar um comando de deslocamento ou global, como SCAN e KEYS, execute o comando em cada servidor Redis.
Cliente	Qualquer cliente Redis	Qualquer cliente Redis (não é necessário oferecer suporte ao protocolo Redis Cluster)	Qualquer cliente que suporte o protocolo Redis Cluster
Comandos desativados	Alguns comandos do Redis não são suportados. Para obter detalhes, consulte Tabela 3, Tabela 7, e Tabela 7.	Alguns comandos do Redis não são suportados. Para mais detalhes, consulte Tabela 4.	Alguns comandos do Redis não são suportados. Para obter mais detalhes, consulte Tabela 9 e Tabela 9.
Réplicas	Uma instância de nó único tem apenas uma réplica. Uma instância principal/em espera tem duas réplicas. Atualmente, o número de réplicas não pode ser personalizado para instâncias principal/em espera do DCS Redis 3.0 e do DCS Redis 6.0. Por padrão, uma instância principal/em espera tem um nó principal e um nó stand-by. Ao criar uma instância principal/em espera do DCS Redis 4.0 ou 5.0, você pode personalizar o número de réplicas, sendo uma delas a principal.	Cada fragmento no cluster tem e só pode ter duas réplicas, sendo uma delas a principal.	Por padrão, cada estilhaço no cluster tem duas réplicas. O número de réplicas pode ser personalizado, com um deles sendo o principal. Ao criar uma instância, você pode definir a quantidade de réplicas como uma, indicando que a instância tem apenas o nó principal. Neste caso, não é possível garantir uma elevada fiabilidade dos dados.