O serviço de mensagens é um recurso essencial do ApsaraMQ for RocketMQ e fica ativado por padrão ao habilitar o serviço. Instâncias da Standard Edition utilizam o modelo de pagamento conforme o uso para mensagens. O custo mensal tem dois componentes:
|
Componente de faturamento |
O que cobre |
Como acumula |
|
Taxas de chamadas de API |
Mensagens enviadas e recebidas pelo servidor |
Mensalmente, por conta Alibaba Cloud |
|
Taxas de ocupação de tópicos |
Cada tópico criado na sua instância |
Diariamente, por tópico |
Cada conta Alibaba Cloud recebe uma cota gratuita de 20 milhões de chamadas de API por mês. Os preços abaixo se aplicam apenas ao uso que excede essa cota.
Taxas de chamadas de API
Fórmula:
Taxas de chamadas de API = (Mensagens recebidas + Mensagens entregues) x Preço unitário
Regras de medição
|
Dimensão de faturamento |
Forma de contagem |
Exemplo |
|
Mensagens normais |
Cada mensagem recebida pelo servidor conta como 1. Cada mensagem entregue conta como 1, independentemente do sucesso no consumo. |
Enviar 100 mensagens e entregar 100 mensagens = 200 no total |
|
Mensagens com recursos especiais |
Multiplique a quantidade por 5. Incluem mensagens transacionais, ordenadas, agendadas e atrasadas. |
1 mensagem transacional recebida + 2 entregas = (1 x 5) + (2 x 5) = 15 |
|
Tamanho da mensagem |
O faturamento utiliza 4 KB como unidade base. Cada bloco de 4 KB conta como 1 mensagem. Tamanho máximo do corpo da mensagem: 4 MB. |
Uma mensagem de 16 KB conta como 16 / 4 = 4 mensagens |
|
Long polling HTTP |
Se o servidor retornar mensagens, conte-as seguindo as regras acima. Caso nenhuma mensagem chegue durante o período de espera (até 30 segundos), a requisição conta como 1 entrega. |
1 resposta vazia de long polling = 1 entrega |
|
Short polling HTTP |
O servidor retorna uma resposta vazia imediatamente. Cada requisição conta como 1 entrega. |
10 requisições vazias de short polling = 10 entregas |
O uso de short polling em tópicos ociosos gera muitas requisições vazias faturáveis. Para reduzir custos, utilize long polling e aumente o tempo de espera. Para mais informações, consulte Operação para consumo de mensagens.
ApsaraMQ for RocketMQ oferece suporte a quatro tipos de mensagem: normal, agendada e atrasada, transacional e ordenada. Apenas mensagens normais são consideradas básicas. Todos os outros tipos são mensagens com recursos especiais e possuem um multiplicador de faturamento de 5x. Para mais informações, consulte Tipos de mensagens.
Preços unitários
As taxas de chamadas de API seguem uma precificação escalonada baseada no throughput acumulado mensalmente por conta Alibaba Cloud.
|
Nível de faturamento |
Throughput mensal (100 milhões de chamadas) |
EAU (Dubai), Singapura, China (Hong Kong), Japão (Tóquio), Reino Unido (Londres), Alemanha (Frankfurt), EUA (Virgínia), EUA (Vale do Silício) |
Malásia (Kuala Lumpur), Indonésia (Jacarta), Filipinas (Manila) |
Internet, China (Hangzhou), China (Xangai), China (Shenzhen), China (Chengdu), China (Qingdao), China (Pequim), China (Zhangjiakou), China (Hohhot) |
Arábia Saudita (Riade - Região Parceira) |
|
Primeiro |
0 - 10 |
0,45 |
0,42 |
0,31 |
0,54 |
|
Segundo |
10 - 50 |
0,41 |
0,38 |
0,28 |
0.492 |
|
Terceiro |
50 - 100 |
0,34 |
0,31 |
0,23 |
0.408 |
|
Quarto |
100 - 500 |
0,30 |
0,27 |
0,20 |
0,36 |
|
Quinto |
> 500 |
0,27 |
0,25 |
0,19 |
0.324 |
Unidade: USD/milhão de chamadas.
Se uma conta Alibaba Cloud autorizar outra conta por meio de uma função do Resource Access Management (RAM), a conta autorizadora será faturada. Quando uma conta Alibaba Cloud autoriza usuários RAM sob sua própria conta, o faturamento recai sobre a conta Alibaba Cloud principal.
Exemplos de faturamento
Cálculo do throughput de mensagens
Um produtor envia diariamente as seguintes mensagens:
7 milhões de mensagens normais (cada uma com 40 KB), resultando em 8 milhões de entregas devido a múltiplos grupos de consumidores e reentregas
3 milhões de mensagens com recursos especiais (cada uma com 2 KB), com 3 milhões de entregas
Throughput diário de mensagens = (Normais recebidas + Normais entregues) x Multiplicador de tamanho + (Especiais recebidas + Especiais entregues) x 5 x Multiplicador de tamanho
= (7M + 8M) x ceil(40 / 4) + (3M + 3M) x 5 x ceil(2 / 4)
= 15M x 10 + 6M x 5 x 1
= 180 milhões de mensagens
A função ceil() arredonda para o inteiro superior mais próximo. Uma mensagem de 2 KB utiliza a unidade mínima de 4 KB, portanto ceil(2 / 4) = 1.
Cálculo das taxas de chamadas de API
Considere que sua instância esteja na China (Xangai) e processe 500 milhões de mensagens por dia. À medida que o throughput acumula ao longo do mês, o nível aplicável e o preço unitário mudam:
|
Dia |
Throughput diário |
Throughput mensal acumulado |
Nível |
Preço unitário (USD/milhão) |
Taxa diária (USD) |
|
1º |
500M |
500M |
Primeiro |
0,31 |
155 |
|
2º |
500M |
1B |
Primeiro |
0,31 |
155 |
|
3º |
500M |
1,5B |
Segundo |
0,28 |
140 |
|
4º |
500M |
2B |
Segundo |
0,28 |
140 |
|
... |
... |
... |
... |
... |
... |
|
11º |
500M |
5,5B |
Terceiro |
0,23 |
115 |
O preço unitário diminui conforme o throughput acumulado cruza os limites dos níveis — volumes maiores pagam taxas menores por chamada.
Taxas de ocupação de tópicos
Fórmula:
Taxas de ocupação de tópicos = Preço unitário x Número de tópicos x Número de dias
Cada tópico incorre em uma taxa diária baseada no seu throughput de mensagens naquele dia.
Os tópicos são faturados mesmo quando ociosos. Exclua tópicos não utilizados para evitar cobranças desnecessárias.
Preços unitários
As taxas de ocupação de tópicos seguem uma precificação escalonada baseada no throughput diário de mensagens por tópico.
|
Nível de faturamento |
Throughput diário (10.000 chamadas/tópico) |
China (Hong Kong), Singapura, Japão (Tóquio), EAU (Dubai), EUA (Virgínia), EUA (Vale do Silício), Alemanha (Frankfurt), Reino Unido (Londres) |
Malásia (Kuala Lumpur), Indonésia (Jacarta), Filipinas (Manila) |
Internet, China (Hangzhou), China (Xangai), China (Shenzhen), China (Chengdu), China (Qingdao), China (Pequim), China (Zhangjiakou), China (Hohhot) |
Arábia Saudita (Riade - Região Parceira) |
|
Primeiro |
0 - 100 |
0,45 |
0,42 |
0,31 |
0,54 |
|
Segundo |
100 - 500 |
0,34 |
0,31 |
0,23 |
0.408 |
|
Terceiro |
500 - 1.000 |
0,11 |
0,11 |
0,08 |
0.132 |
|
Quarto |
> 1.000 |
0 |
0 |
0 |
0 |
Unidade: USD/tópico/dia.
Se uma conta Alibaba Cloud autorizar outra conta por meio de uma função RAM, a conta autorizadora será faturada. Quando uma conta Alibaba Cloud autoriza usuários RAM sob sua própria conta, o faturamento recai sobre a conta Alibaba Cloud principal.
Exemplo de faturamento
Suponha que sua instância esteja na China (Xangai) com vários tópicos. Cada tópico é faturado diariamente com base em seu próprio throughput:
|
Dia |
Tópico |
Throughput diário |
Nível |
Taxa (USD) |
|
1º |
Topic_1 |
100.000 |
Primeiro |
0,31 |
|
1º |
Topic_2 |
5.500.000 |
Terceiro |
0,08 |
|
2º |
Topic_1 |
1.200.000 |
Segundo |
0,23 |
|
2º |
Topic_2 |
800.000 |
Primeiro |
0,31 |
|
3º |
Topic_1 |
300.000 |
Primeiro |
0,31 |
|
3º |
Topic_2 |
100.000 |
Primeiro |
0,31 |
A taxa diária de ocupação de tópicos corresponde à soma das taxas de todos os tópicos ativos naquele dia. Tópicos com throughput diário superior a 10 milhões de chamadas (quarto nível) não têm cobrança de ocupação.
FAQ
Como as mensagens com recursos especiais são contadas para faturamento?
Mensagens com recursos especiais (transacionais, ordenadas, agendadas e atrasadas) são faturadas com um multiplicador de 5x. Tanto o envio quanto o recebimento utilizam esse multiplicador. Por exemplo, enviar 1 mensagem transacional e entregá-la a 2 consumidores resulta em (1 x 5) + (2 x 5) = 15 chamadas faturáveis.
Sou cobrado por entregas de mensagens com falha?
Sim. Cada tentativa de entrega conta como um evento faturável, independentemente de o consumidor processar a mensagem com sucesso ou não.
Como funciona o faturamento com usuários RAM?
Todo o uso realizado por usuários RAM é faturado na conta Alibaba Cloud pai. Se a conta A delegar acesso à conta B por meio de uma função RAM, a conta A (a conta autorizadora) será faturada.
O que acontece se eu usar short polling em um tópico ocioso?
Cada requisição de short polling para um tópico ocioso conta como 1 entrega. Isso gera chamadas faturáveis mesmo sem mensagens. Mude para long polling e aumente o tempo de espera para reduzir custos.