Todos os produtos
Search
Central de documentação

ApsaraMQ for Kafka:Edições de instância

Última atualização: Aug 27, 2026

Este tópico descreve as edições de instância do Message Queue for Apache Kafka. Use estas informações para selecionar a edição mais adequada aos requisitos do seu negócio.

Tipos de instância

Nota
  • single-zone: Seu service e seus dados são implantados em uma única zona de disponibilidade. Se ocorrer uma falha no nível da zona, o service ficará indisponível e haverá risco de perda de dados. Caso escolha uma instância single-zone, recomendamos criar uma instância em outra região e utilizar um conector para fazer backup das mensagens. Para mais informações, consulte Best practices for single-zone disaster recovery.

  • multi-zone: O service e os dados são implantados em várias zonas de disponibilidade. Essa arquitetura protege contra interrupções de service e perda de dados caso uma única zona de disponibilidade falhe. Recomendamos a implantação multi-zone para services críticos.

A tabela a seguir descreve as edições de instância do Message Queue for Apache Kafka.

Item

Standard edition

(High-write)

Professional edition

(High-write)

Professional edition

(High-read)

Serverless

basic edition

Serverless

standard edition

Serverless

professional edition

Custo de armazenamento

Capacidade reservada. Os custos são comparáveis aos de um cluster autogerenciado.

Por exemplo, se você adquirir um disco de 300 GB, 100 GB estarão disponíveis para seus dados de negócio e os 200 GB restantes serão reservados para réplicas.

Capacidade reservada, com economia de até 66% em comparação a um cluster autogerenciado.

Por exemplo, se você adquirir um disco de 300 GB, todos os 300 GB estarão disponíveis para seus dados de negócio. Outros 600 GB de armazenamento para réplicas estão incluídos gratuitamente.

Modelo de pagamento conforme o uso. A cobrança é baseada no espaço de armazenamento realmente utilizado e na duração da retenção. Isso gera uma economia superior a 70% nos custos de armazenamento em comparação ao uso de discos cloud em um cluster autogerenciado.

Custo de computação

Capacidade reservada

Capacidade reservada

Modelo de pagamento conforme o uso

Interrupção de service

Dimensiona rapidamente para lidar com picos repentinos de tráfego sem exigir rebalanceamento prolongado de dados.

Arquitetura elástica

Após o scale-out, novas operações de leitura e gravação são atendidas em segundos.

A arquitetura com armazenamento e computação desacoplados permite que leituras, gravações e migrações de partição sejam concluídas em segundos.

Dimensionamento vertical contínuo

Não suportado

Não suportado

Não suportado

Requer dimensionamento manual.

  • Para throughput reservado de (0, 512] MB/s: capacidade elástica de até 2x o throughput reservado.

  • Para throughput reservado de (512, 5.120] MB/s: capacidade elástica de até 2x o throughput reservado.

  • Para throughput reservado de (5.120, 10.240] MB/s: capacidade elástica de até 1,5x o throughput reservado.

  • Para throughput reservado acima de 10.240 MB/s: capacidade elástica de até 1,2x o throughput reservado.

  • Para throughput reservado de (0, 512] MB/s: capacidade elástica de até 1 GB/s.

  • Para throughput reservado de (512, 5.120] MB/s: capacidade elástica de até 2x o throughput reservado.

  • Para throughput reservado de (5.120, 10.240] MB/s: capacidade elástica de até 1,5x o throughput reservado.

  • Para throughput reservado acima de 10.240 MB/s: capacidade elástica de até 1,2x o throughput reservado.

Proporção de tráfego pico de leitura/gravação

1:1

1:1

3:1

3:1

Arquitetura de implantação

Instância compartilhada (isolamento lógico)

Instância dedicada (cluster físico exclusivo)

Instância compartilhada (isolamento lógico)

Instância dedicada (cluster físico exclusivo)

TTL do tópico

Não suportado

Suportado para armazenamento local

Totalmente suportado

Período de retenção de mensagens

Até 7 dias

Personalizável conforme o caso de uso.

Suporta retenção ilimitada, com limite padrão de um ano. Para solicitar um período de retenção maior, submit a ticket.

Recuperação de desastres

Os nós de computação e armazenamento são implantados em uma única zona de disponibilidade.

Suporta implantação multi-zone. Se você escolher a implantação single-zone, os nós de computação e armazenamento ficarão em uma única zona de disponibilidade.

Os nós de computação e armazenamento são implantados em uma única zona de disponibilidade.

Implantação multi-zone em três zonas de disponibilidade (3AZ).

Ajuste de desempenho

Não suportado

Personalizável conforme o caso de uso.

Personalizável conforme o caso de uso.

ACL

Não suportado

Suportado

Suportado

Criptografia SSL para transmissão de mensagens em VPCs

Não suportado

Suportado

Suportado

Implantação entre zonas

Não suportado

Suportado

Não suportado

Suportado

Compatibilidade de versão do cliente

Compatível com clientes Apache Kafka versões 0,11 a 3.x.

Compatível com clientes Apache Kafka versões 0,11 a 3.x.

Compatível com clientes Apache Kafka versões 0,11 a 3.x.

Service level agreement (SLA)

99,95%

Oferece SLA de 99,99% para implantações multi-zone e 99,95% para implantações single-zone.

Oferece SLA de 99,9%, inferior ao das edições Standard e Professional. Esta edição utiliza uma proporção maior de recursos de baixo custo, como HDDs, OSS e instâncias spot. Recomendada para testes ou cargas de trabalho com tráfego estável.

Para cargas de trabalho críticas que exigem alta estabilidade, recomendamos a Serverless Standard ou Professional Edition.

Oferece SLA de 99,95%. Recomendada para ambientes de produção.

Oferece SLA de 99,99% com recuperação de desastres em três zonas de disponibilidade. Proporciona maior elasticidade para instâncias com menor throughput reservado. Esta é a edição recomendada para uso empresarial.

Criptografia de disco cloud

Suportado

Suportado

Não suportado

Especificações de tráfego e limitação

A especificação de tráfego de uma instância do Message Queue for Apache Kafka define o throughput máximo para produção (gravação) e consumo (leitura) de mensagens. Compreender como os limites de tráfego são calculados e como a limitação é acionada ajuda a diagnosticar problemas de desempenho.

Distribuição de tráfego por nó — O limite da especificação de tráfego é distribuído uniformemente entre os nós broker de uma instância. Por exemplo, em uma instância com 3 nós, o limite de tráfego de cada nó corresponde a aproximadamente um terço da especificação total. Se o tráfego real de um único nó exceder seu limite individual, a limitação será acionada para esse nó, mesmo que o tráfego geral da instância não tenha atingido o limite da especificação.

Desequilíbrio de tráfego e limitação — Por padrão, o Apache Kafka replica mensagens em 3 réplicas. Se a produção de mensagens for desigual — devido, por exemplo, a envios em lote agendados ou distribuição irregular de chaves de partição — o tráfego se concentra em nós ou partições específicos. Isso causa sobrecarga local e aciona a limitação, mesmo quando o tráfego médio no nível da instância parece estar dentro da especificação.

Visualize especificações de tráfego — No console, acesse a lista de instâncias e clique no nome da instância. Na aba Instance Information, a seção Basic Information exibe a Traffic Specification da sua instância, incluindo os valores de Maximum Read Traffic e Maximum Write Traffic em MB/s.

Definição de tráfego de pico e estimativa de contagem de partições — O valor de tráfego de pico mostrado na tabela de especificações (por exemplo, 20 MB/s) refere-se ao tráfego de pico de leitura/gravação no lado do negócio. Trata-se do throughput máximo no qual sua aplicação produz (grava) ou consome (lê) mensagens, e não do limite físico da interface de rede (NIC). O tráfego real de leitura/gravação da NIC que uma instância suporta é aproximadamente 3 vezes o valor da especificação, pois a capacidade extra é reservada para cobrir sobrecargas internas, como replicação de dados para réplicas.

Ao estimar o número de partições necessárias para o seu tópico, baseie o cálculo apenas no tráfego de pico de produção ou consumo do lado do negócio. Não é necessário dobrar a contagem de partições para considerar uma proporção de leitura/gravação de 1:1, pois o valor da especificação e o tráfego subjacente da NIC já contabilizam a sobrecarga de replicação.

Monitorar uso de tráfego — Para identificar limitação em nó único ou desequilíbrio de tráfego, acesse Prometheus Monitoring no painel de navegação à esquerda da página de detalhes da instância. Visualize as métricas Node consumption traffic e Cluster consumption traffic para comparar o tráfego real por nó com o limite por nó (especificação total ÷ número de nós).

Partições de instância

O número de partições varia conforme a edição da instância, conforme descrito nas tabelas a seguir.

Instâncias Serverless

Edition

Réplicas de partição

Máximo de réplicas de partição

Basic Edition

  • Se o throughput de produção reservado for de 1 GB/s ou menos, o cluster terá 3.000 réplicas de partição.

  • Se o throughput de produção reservado for superior a 1 GB/s, 300 réplicas de partição serão adicionadas para cada aumento de 100 MB/s no throughput.

  • Para evitar problemas de desempenho causados por fragmentação de mensagens, evite criar réplicas de partição excessivas para um único tópico. Um único tópico suporta no máximo 600 réplicas de partição.

  • Máximo de réplicas de partição por cluster: 30.000

  • Máximo de réplicas de partição por tópico: 600

Para solicitar um limite maior, submit a ticket.

Standard Edition

Professional Edition

Instâncias Subscription e pagamento conforme o uso

Standard edition (High-write)

Especificação de tráfego

Partições incluídas

Máximo de partições

alikafka.hw.2xlarge

1.000

4.000

alikafka.hw.3xlarge

1.000

4.200

alikafka.hw.6xlarge

1.000

4.400

alikafka.hw.9xlarge

1.000

4.600

alikafka.hw.12xlarge

1.000

4.800

Professional edition (High-write)

Especificação de tráfego

Partições incluídas

Máximo de partições

alikafka.hw.2xlarge

1.000

4.000

alikafka.hw.3xlarge

1.000

4.200

alikafka.hw.6xlarge

1.000

4.400

alikafka.hw.9xlarge

1.000

4.600

alikafka.hw.12xlarge

1.000

4.800

alikafka.hw.16xlarge

2.000

5.000

alikafka.hw.20xlarge

2.000

6.000

alikafka.hw.25xlarge

2.000

7.000

alikafka.hw.30xlarge

2.000

8.000

alikafka.hw.60xlarge

2.000

9.000

alikafka.hw.80xlarge

2.000

10.000

alikafka.hw.100xlarge

3.000

12.000

alikafka.hw.120xlarge

3.000

14.000

alikafka.hw.150xlarge

3.000

16.000

alikafka.hw.180xlarge

3.000

18.000

alikafka.hw.200xlarge

3.000

20.000

alikafka.hw2.220xlarge

4.000

24.000

alikafka.hw2.300xlarge

4.000

26.000

alikafka.hw2.400xlarge

4.000

28.000

alikafka.hw2.500xlarge

4.000

30.000

alikafka.hw2.600xlarge

5.000

32.000

alikafka.hw2.700xlarge

5.000

34.000

alikafka.hw2.800xlarge

5.000

36.000

alikafka.hw2.900xlarge

5.000

38.000

alikafka.hw2.1000xlarge

5.000

40.000

Professional edition (High-read)

Especificação de tráfego

Partições incluídas

Máximo de partições

alikafka.hr.2xlarge

1.000

4.000

alikafka.hr.3xlarge

1.000

4.200

alikafka.hr.6xlarge

1.000

4.400

alikafka.hr.9xlarge

1.000

4.600

alikafka.hr.12xlarge

1.000

4.800

alikafka.hr.16xlarge

2.000

5.000

alikafka.hr.20xlarge

2.000

6.000

alikafka.hr.25xlarge

2.000

7.000

alikafka.hr.30xlarge

2.000

8.000

alikafka.hr.60xlarge

2.000

9.000

alikafka.hr.80xlarge

2.000

10.000

alikafka.hr.100xlarge

3.000

12.000

alikafka.hr.120xlarge

3.000

14.000

alikafka.hr.150xlarge

3.000

16.000

alikafka.hr.180xlarge

3.000

18.000

alikafka.hr.200xlarge

3.000

20.000

alikafka.hr2.220xlarge

4.000

24.000

alikafka.hr2.300xlarge

4.000

26.000

alikafka.hr2.400xlarge

4.000

28.000

alikafka.hr2.500xlarge

4.000

30.000

alikafka.hr2.600xlarge

5.000

32.000

alikafka.hr2.700xlarge

5.000

34.000

alikafka.hr2.800xlarge

5.000

36.000

alikafka.hr2.900xlarge

5.000

38.000

alikafka.hr2.1000xlarge

5.000

40.000

FAQ

Quais são os requisitos de edição de instância para integrar o Kafka ao MQTT Rule Engine?

Não há requisitos obrigatórios de edição para usar o Message Queue for Apache Kafka com o MQTT Rule Engine. Qualquer edição — Standard, Professional ou Serverless — suporta integração básica.

No entanto, se o seu ambiente de produção exigir autenticação SASL ou controle de acesso baseado em ACL, você deve usar a Professional Edition ou Serverless Edition. A Standard Edition não suporta endpoints SASL nem ACL.

Qual é o limite máximo de capacidade de disco da Professional edition (High-write)?

A capacidade de disco é provisionada no nível do cluster e distribuída uniformemente entre todos os nós broker do cluster. A Professional edition (High-write) não possui um limite explícito de capacidade máxima de disco. Contudo, cada especificação de tráfego tem um requisito mínimo de capacidade de disco correspondente, portanto, a capacidade de disco disponível para seleção varia conforme a especificação de tráfego escolhida.

Ao criar uma instância, selecione um tamanho de disco compatível com os requisitos do seu negócio. Após escolher um tipo de disco — ultra disk ou SSD — para uma instância, não é possível alterar o tipo posteriormente.

Quantos nós Broker uma instância Kafka possui? Posso configurar o número manualmente?

O ApsaraMQ for Kafka é um service de fila de mensagens totalmente gerenciado fornecido pela Alibaba Cloud. O sistema ajusta automaticamente o número e a configuração dos nós Broker com base na especificação de tráfego da sua instância, eliminando a necessidade de acompanhar detalhes individuais dos nós. Não há suporte para configuração manual ou especificação do número de nós Broker.

Qual é o número máximo de conexões para a especificação alikafka.hw.2xlarge da Professional edition (High-write)?

Para uma instância com a especificação de tráfego alikafka.hw.2xlarge, caso não haja atualização da especificação, o número máximo inicial de conexões por nó é 1.000. Se o seu negócio exigir um limite de conexão maior, atualize a especificação de tráfego da sua instância.

Palavras-chave: conexões máximas, limite de conexão, alikafka.hw.2xlarge.