As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Práticas recomendadas do Amazon MQ para RabbitMQ
Siga essas diretrizes de preparação para produção para maximizar o desempenho do agente e otimizar a eficiência de throughput de mensagens quando trabalhar com agentes do Amazon MQ para RabbitMQ.
**Importante**
Atualmente, o Amazon MQ não é compatível com [transmissões](https://www.rabbitmq.com/streams.html), nem com o uso do registro estruturado em JSON, apresentado no RabbitMQ 3.9.x.
**Topics**
+ [
# Práticas recomendadas para configuração de agentes e gerenciamento de conexões no Amazon MQ para RabbitMQ
](best-practices-broker-setup.md)
+ [
# Práticas recomendadas para durabilidade e confiabilidade de mensagens no Amazon MQ para RabbitMQ
](best-practices-message-reliability.md)
+ [
# Práticas recomendadas para otimização e eficiência de desempenho no Amazon MQ para RabbitMQ
](best-practices-performance.md)
+ [
# Práticas recomendadas para resiliência e monitoramento de rede no Amazon MQ para RabbitMQ
](best-practices-network-resilience.md)
# Práticas recomendadas para configuração de agentes e gerenciamento de conexões no Amazon MQ para RabbitMQ
O gerenciamento de conexões e a configuração do agente são a primeira etapa para evitar problemas com a taxa de throughput de mensagens do agente, a utilização de recursos e a capacidade de lidar com workloads de produção. Quando [criar e configurar um agente do Amazon MQ para RabbitMQ](getting-started-rabbitmq.md#create-rabbitmq-broker), siga as práticas recomendadas a seguir para selecionar os tipos de instância apropriados, gerenciar as conexões de forma eficiente e configurar a pré-busca de mensagens para maximizar o desempenho do agente.
**Importante**
O Amazon MQ para RabbitMQ não permite o nome de usuário “convidado” e excluirá a conta de convidado padrão quando você criar um agente. O Amazon MQ também excluirá periodicamente qualquer conta de “convidado” criada pelo cliente.
## Etapa 1: usar implantações de cluster
Em workloads de produção, recomendamos o uso de implantações de cluster em vez de agentes de instância única para garantir alta disponibilidade e resiliência de mensagens. As implantações de cluster removem pontos únicos de falha e oferecem melhor tolerância a falhas.
As implantações de cluster consistem em três nós de agente do RabbitMQ distribuídos em três zonas de disponibilidade, fornecendo failover automático e garantindo que as operações continuem mesmo se uma zona de disponibilidade inteira ficar indisponível. O Amazon MQ replica automaticamente as mensagens em todos os nós para garantir a disponibilidade durante falhas ou manutenção dos nós.
As implantações de clusters são essenciais para ambientes de produção e são suportadas pelo [Acordo de Nível de Serviço do Amazon MQ](https://aws.amazon.com/amazon-mq/sla/).
Para saber mais, consulte [Implantação de clusters no Amazon MQ para RabbitMQ](rabbitmq-broker-architecture.md#rabbitmq-broker-architecture-cluster).
## Etapa 2: Escolher o tipo correto de instância do agente
O throughput de mensagens de um tipo de instância do agente depende do caso de uso da aplicação. O `M7g.medium` deve ser usado somente para testar o desempenho da aplicação. Usar essa instância menor antes de usar instâncias maiores na produção pode melhorar o desempenho da aplicação. Em tipos de instância `m7g.large` e superiores, você pode usar implantações de cluster para obter alta disponibilidade e durabilidade de mensagens. Tipos maiores de instância do agente conseguem lidar com níveis de produção de clientes e filas, alto throughput, mensagens na memória e mensagens redundantes.
Para obter mais informações sobre como escolher o tipo de instância correto, consulte [Diretrizes de dimensionamento no Amazon MQ para RabbitMQ](rabbitmq-sizing-guidelines.md).
## Etapa 3: Usar filas de quórum
As filas de quórum, com implantação de cluster, devem ser a escolha padrão para tipos de fila replicados em ambientes de produção para os agente do RabbitMQ na versão 3.13 e posterior. As filas de quórum são um tipo de fila replicada moderna que fornece alta confiabilidade, alto throughput e latência estável.
As filas de quórum usam o algoritmo de consenso Raft para fornecer melhor tolerância a falhas. Quando o nó líder fica indisponível, as filas de quórum elegem automaticamente um novo líder por maioria de votos, garantindo que a entrega de mensagens continue com o mínimo de interrupção. Como cada nó está em uma zona de disponibilidade diferente, o sistema de mensagens permanece disponível mesmo que uma zona de disponibilidade inteira fique temporariamente indisponível.
Para declarar uma fila de quórum, defina o cabeçalho `x-queue-type` como `quorum` quando criar as filas.
Para saber mais sobre filas de quórum, incluindo estratégias de migração e práticas recomendadas, consulte [Filas de quórum no Amazon MQ para RabbitMQ](quorum-queues.md).
## Etapa 4: Usar vários canais
Para evitar a perda de conexão, use vários canais em uma única conexão. As aplicações devem evitar uma relação de conexão de 1:1 com o canal. Recomendamos usar uma conexão por processo e um canal por fio. Evite o uso excessivo de um canal para impedir vazamentos no canal.
# Práticas recomendadas para durabilidade e confiabilidade de mensagens no Amazon MQ para RabbitMQ
Antes de mover o aplicativo para a produção, siga as práticas recomendadas para evitar a perda de mensagens e a sobreutilização de recursos.
## Etapa 1: Usar mensagens persistentes e filas duráveis
Mensagens persistentes podem ajudar a proteger a durabilidade em situações em que um agente falha ou reinicia. Mensagens persistentes são gravadas no disco assim que chegam. Ao contrário das filas lazy, no entanto, as mensagens persistentes são armazenadas em cache tanto na memória quanto no disco, a menos que o agente necessite de mais memória. Nos casos em que mais memória é necessária, as mensagens são removidas da memória pelo mecanismo do agente RabbitMQ que gerencia o armazenamento de mensagens no disco, comumente chamado de *camada de persistência*.
Para habilitar a persistência de mensagens, você pode declarar suas filas como `durable` e definir o modo de entrega de mensagens como `persistent`. O exemplo a seguir demonstra declarar uma fila durável usando a [biblioteca do cliente Java RabbitMQ](https://www.rabbitmq.com/java-client.html). Ao trabalhar com o AMQP 0-9-1, você pode marcar mensagens como persistentes definindo o modo de entrega como “2”.
```
boolean durable = true;
channel.queueDeclare("my_queue", durable, false, false, null);
```
Depois de configurar sua fila como durável, você pode enviar uma mensagem persistente para a fila definindo `MessageProperties` como `PERSISTENT_TEXT_PLAIN`, da forma mostrada no exemplo a seguir.
```
import com.rabbitmq.client.MessageProperties;
channel.basicPublish("", "my_queue",
MessageProperties.PERSISTENT_TEXT_PLAIN,
message.getBytes());
```
## Etapa 2: Configurar a confirmação do publicador e o reconhecimento de entrega do consumidor
O processo de confirmar que uma mensagem foi enviada ao agente é conhecido como *confirmação do publicador*. As confirmações do publicador avisam a aplicação quando as mensagens foram armazenadas de forma confiável. As confirmações do publicador também podem ajudar a controlar a taxa de mensagens armazenadas no agente. Sem as confirmações do publicador, não há confirmação de que uma mensagem foi processada com sucesso, e o agente talvez envie mensagens que não consiga processar.
De modo similar, quando uma aplicação cliente envia uma confirmação de entrega e consumo de mensagens de volta ao agente, isso é conhecido como *confirmação de entrega do consumidor*. Os dois tipos de confirmação são essenciais para garantir a segurança dos dados ao trabalhar com agentes do RabbitMQ.
A confirmação de entrega do consumidor geralmente é configurada na aplicação do cliente. Ao trabalhar com o AMQP 0-9-1, a confirmação pode ser habilitada configurando o método `basic.consume`. Os clientes AMQP 0-9-1 também podem configurar as confirmações do publicador enviando o método `confirm.select`.
Normalmente, a confirmação de entrega está habilitada em um canal. Por exemplo, ao trabalhar com a biblioteca do cliente Java RabbitMQ, você pode usar o `Channel#basicAck` para configurar um reconhecimento positivo `basic.ack`, conforme mostrado no exemplo a seguir.
```
// this example assumes an existing channel instance
boolean autoAck = false;
channel.basicConsume(queueName, autoAck, "a-consumer-tag",
new DefaultConsumer(channel) {
@Override
public void handleDelivery(String consumerTag,
Envelope envelope,
AMQP.BasicProperties properties,
byte[] body)
throws IOException
{
long deliveryTag = envelope.getDeliveryTag();
// positively acknowledge a single delivery, the message will
// be discarded
channel.basicAck(deliveryTag, false);
}
});
```
**nota**
Mensagens não reconhecidas devem ser armazenadas em cache na memória. Você pode limitar o número de mensagens que um consumidor busca antecipadamente configurando [Pré-busca](best-practices-performance.md#configure-prefetching) para uma aplicação do cliente.
Você pode configurar o `consumer_timeout` para detectar quando os consumidores não confirmarem as entregas. Se o consumidor não enviar uma confirmação dentro do tempo limite, o canal será fechado e você receberá `PRECONDITION_FAILED`. Para diagnosticar o erro, use a [UpdateConfiguration](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/configurations-configuration-id.html)API para aumentar o `consumer_timeout` valor.
## Etapa 3: Manter as filas curtas
Em implantações de cluster, filas com um grande número de mensagens podem levar à utilização excessiva de recursos. Quando um agente é utilizado em excesso, a reinicialização de um agente do Amazon MQ para RabbitMQ pode causar maior degradação da performance. Se reinicializados, os agentes usados em excesso podem deixar de responder no estado `REBOOT_IN_PROGRESS`.
Durante as [janelas de manutenção](amazon-mq-rabbitmq-editing-broker-preferences.md#rabbitmq-edit-current-configuration-console), o Amazon MQ executa todos os trabalhos de manutenção um nó de cada vez para garantir que o agente permaneça operacional. Como resultado, as filas podem precisar sincronizar à medida que cada nó retoma a operação. Durante a sincronização, as mensagens que precisam ser replicadas em espelhos são carregadas na memória do volume correspondente do Amazon Elastic Block Store (Amazon EBS) para serem processadas em lotes. O processamento de mensagens em lotes permite que as filas sejam sincronizadas mais rapidamente.
Se as filas forem mantidas curtas e as mensagens forem pequenas, as filas serão sincronizadas com êxito e retomarão a operação conforme esperado. No entanto, se a quantidade de dados em um lote se aproximar do limite de memória do nó, o nó gera um alarme de memória alta, pausando a sincronização de fila. Você pode confirmar o uso da memória comparando as [métricas do nó `RabbitMemUsed` e do `RabbitMqMemLimit` broker em CloudWatch](amazon-mq-accessing-metrics.md). A sincronização não pode ser concluída até que as mensagens sejam consumidas ou excluídas ou o número de mensagens no lote seja reduzido.
Se a sincronização de filas estiver pausada para uma implantação de cluster, recomendamos consumir ou excluir mensagens para diminuir o número de mensagens em filas. Quando a profundidade da fila for reduzida e a sincronização da fila for concluída, o status do agente mudará para `RUNNING`. Para resolver uma sincronização de fila pausada, você também pode aplicar uma política para [reduzir o tamanho do lote de sincronização de filas](rabbitmq-queue-sync.md).
Você também pode definir políticas de exclusão automática e TTL para reduzir proativamente o uso de recursos, bem como reduzir ao mínimo o NACKs alcance dos consumidores. O enfileiramento de mensagens na corretora consome muita CPU, portanto, um grande número de mensagens pode afetar o desempenho da corretora. NACKs
# Práticas recomendadas para otimização e eficiência de desempenho no Amazon MQ para RabbitMQ
Você pode otimizar o desempenho do agente do Amazon MQ para RabbitMQ maximizando o throughput, minimizando a latência e garantindo a utilização eficiente dos recursos. Conclua as práticas recomendadas a seguir para otimizar o desempenho da aplicação.
## Etapa 1: Manter o tamanho das mensagens abaixo de 1 MB
Recomendamos manter as mensagens com menos de 1 megabyte (MB) para desempenho e confiabilidade ideais.
O RabbitMQ 3.13 é compatível com tamanhos de mensagem de até 128 MB por padrão. Porém, mensagens grandes podem acionar alarmes de memória imprevisíveis que bloqueiam a publicação e potencialmente criam pressão de alta memória quando se replica mensagens entre os nós. As mensagens superdimensionadas também podem afetar os processos de reinicialização e recuperação do agente, o que aumenta os riscos à continuidade do serviço e pode causar degradação do desempenho.
**Armazenar e recuperar cargas úteis grandes usando o padrão de verificação de reivindicações**
Para gerenciar mensagens grandes, você pode implementar o padrão de verificação de reinvindicação armazenando a carga útil da mensagem no armazenamento externo e enviando somente o identificador de referência da carga útil por meio do RabbitMQ. O consumidor usa o identificador de referência da carga útil para recuperar e processar a mensagem grande.
O diagrama a seguir demonstra como usar o Amazon MQ para RabbitMQ e o Amazon S3 para implementar o padrão de verificação de reivindicações.
![\[Diagram showing data flow between Producer, Consumer, Amazon MQ broker, and AWS S3.\]](http://docs.aws.amazon.com/pt_br/amazon-mq/latest/developer-guide/images/claim-check-pattern.png)
O exemplo a seguir demonstra esse padrão usando-se o Amazon MQ, o [AWS SDK para Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/home.html) e o [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html):
1. Primeiro, defina uma classe de mensagem que conterá o identificador de referência do Amazon S3.
```
class Message {
// Other data fields of the message...
public String s3Key;
public String s3Bucket;
}
```
1. Crie um método de publicador que armazene a carga útil no Amazon S3 e envie uma mensagem de referência por meio do RabbitMQ.
```
public void publishPayload() {
// Store the payload in S3.
String payload = PAYLOAD;
String prefix = S3_KEY_PREFIX;
String s3Key = prefix + "/" + UUID.randomUUID();
s3Client.putObject(PutObjectRequest.builder()
.bucket(S3_BUCKET).key(s3Key).build(),
RequestBody.fromString(payload));
// Send the reference through RabbitMQ.
Message message = new Message();
message.s3Key = s3Key;
message.s3Bucket = S3_BUCKET;
// Assign values to other fields in your message instance.
publishMessage(message);
}
```
1. Implemente um método de consumidor que recupere a carga útil do Amazon S3, processe a carga útil e exclua o objeto do Amazon S3.
```
public void consumeMessage(Message message) {
// Retrieve the payload from S3.
String payload = s3Client.getObjectAsBytes(GetObjectRequest.builder()
.bucket(message.s3Bucket).key(message.s3Key).build())
.asUtf8String();
// Process the complete message.
processPayload(message, payload);
// Delete the S3 object.
s3Client.deleteObject(DeleteObjectRequest.builder()
.bucket(message.s3Bucket).key(message.s3Key).build());
}
```
## Etapa 2: Usar `basic.consume` e consumidores duradouros
Usar `basic.consume` com um consumidor de longa data é mais eficiente do que pesquisar o uso de mensagens individuais do `basic.get`. Para saber mais, consulte [Pesquisa de mensagens individuais](https://www.rabbitmq.com/docs/3.13/consumers#polling).
## Etapa 3: Configurar pré-busca
Você pode usar o valor de pré-busca RabbitMQ para otimizar como seus consumidores consomem mensagens. O RabbitMQ implementa o mecanismo de pré-busca do canal fornecido pelo AMQP 0-9-1 aplicando a contagem de pré-busca aos consumidores em oposição aos canais. O valor de pré-busca é usado para especificar quantas mensagens estão sendo enviadas ao consumidor em um determinado momento. Por padrão, o RabbitMQ define um tamanho ilimitado de buffer para aplicações do cliente.
Há muitos fatores a serem considerados ao definir uma contagem de pré-busca para seus consumidores RabbitMQ. Primeiro, considere o ambiente e a configuração dos seus consumidores. Como os consumidores precisam manter todas as mensagens na memória enquanto estão sendo processadas, um alto valor de pré-busca pode ter um impacto negativo na performance de seus consumidores e, em alguns casos, pode resultar em um consumidor potencialmente travando tudo. Da mesma forma, o próprio agente RabbitMQ mantém todas as mensagens que envia armazenadas em cache na memória até receber reconhecimento do consumidor. Um valor de pré-busca alto pode fazer com que o servidor RabbitMQ fique sem memória rapidamente se a confirmação automática não estiver configurada para os consumidores e se os consumidores demorarem um tempo relativamente longo para processar mensagens.
Com as considerações acima em mente, recomendamos sempre definir um valor de pré-busca para evitar situações em que um agente RabbitMQ ou seus consumidores ficam sem memória devido a um grande número de mensagens não processadas ou não confirmadas. Se você precisar otimizar seus agentes para processar grandes volumes de mensagens, você pode testar seus agentes e consumidores usando uma gama de contagens de pré-busca para determinar o valor em que ponto a sobrecarga de rede se torna em grande parte insignificante em comparação com o tempo que um consumidor leva para processar mensagens.
**nota**
Se as aplicações do seu cliente tiverem configurado para confirmar automaticamente a entrega de mensagens aos consumidores, a definição de um valor de pré-busca não terá efeito.
Todas as mensagens pré-buscadas são removidas da fila.
O exemplo a seguir demonstra a configuração de um valor de pré-busca de `10` para um único consumidor usando a biblioteca do cliente Java RabbitMQ.
```
ConnectionFactory factory = new ConnectionFactory();
Connection connection = factory.newConnection();
Channel channel = connection.createChannel();
channel.basicQos(10, false);
QueueingConsumer consumer = new QueueingConsumer(channel);
channel.basicConsume("my_queue", false, consumer);
```
**nota**
Na biblioteca do cliente Java RabbitMQ, o valor padrão para `global` está definido como `false`, de modo que o exemplo acima pode ser escrito simplesmente como `channel.basicQos(10)`.
## Etapa 4: Usar o Celery 5.5 ou posterior com filas de quórum
O [Python Celery](https://docs.celeryq.dev/en/stable/index.html), um sistema distribuído de filas de tarefas, pode gerar muitas mensagens não críticas ao enfrentar uma alta carga de tarefas. Essa atividade adicional do agente pode desencadear [Amazon MQ for RabbitMQ: Alarme de alta memória](troubleshooting-action-required-codes-rabbitmq-memory-alarm.md) e levar à indisponibilidade do agente. Para reduzir a chance de acionar o alarme de memória, faça o seguinte:
**Para todas as versões do Celery**
1. Desative [https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-task_create_missing_queues](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-task_create_missing_queues) para mitigar a rotatividade da fila.
1. Em seguida, desative `worker_enable_remote_control` para interromper a criação dinâmica de filas do `celery@...pidbox`. Isso reduzirá a rotatividade de filas no agente.
```
worker_enable_remote_control = false
```
1. Para reduzir ainda mais a atividade de mensagens não críticas, desative o Celery [worker-send-task-events](https://docs.celeryq.dev/en/stable/userguide/configuration.html#worker-send-task-events)sem incluir `-E` ou `--task-events` sinalizar ao iniciar seu aplicativo Celery.
1. Inicie a aplicação Celery usando os seguintes parâmetros:
```
celery -A app_name worker --without-heartbeat --without-gossip --without-mingle
```
**Para as versões 5.5 e posteriores do Celery**
1. Atualize para a [versão 5.5 do Celery](https://docs.celeryq.dev/en/latest/changelog.html#version-5-5-0), a versão mínima que oferece suporte a filas de quórum, ou uma versão posterior. Para verificar qual versão do Celery você está usando, use `celery --version`. Para obter mais informações sobre quóruns, consulte [Filas de quórum do RabbitMQ no Amazon MQ](quorum-queues.md).
1. Depois de atualizar para o Celery 5.5 ou posterior, configure `task_default_queue_type` como [“quórum”](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-task_default_queue_type).
1. Em seguida, ative também a opção Publicar confirmações nas [Opções de transporte de agente](https://docs.celeryq.dev/en/stable/userguide/configuration.html#std-setting-broker_transport_options):
```
broker_transport_options = {"confirm_publish": True}
```
# Práticas recomendadas para resiliência e monitoramento de rede no Amazon MQ para RabbitMQ
A resiliência da rede e as métricas do agente de monitoramento são essenciais para manter as aplicações de mensagens confiáveis. Conclua as práticas recomendadas a seguir para implementar mecanismos de recuperação automática e estratégias de monitoramento de recursos.
## Etapa 1: Recuperação automática de falhas de rede
Recomendamos sempre habilitar a recuperação automática de rede para evitar tempo de inatividade significativo nos casos em que as conexões do cliente com os nós RabbitMQ falham. A biblioteca do cliente Java RabbitMQ é compatível com a recuperação automática de rede por padrão, começando com a versão `4.0.0`.
[A recuperação automática da conexão é acionada se uma exceção não tratada for lançada no I/O loop da conexão, se o tempo limite da operação de leitura do soquete for detectado ou se o servidor perder uma pulsação.](https://www.rabbitmq.com/heartbeats.html)
Nos casos em que a conexão inicial entre um cliente e um nó RabbitMQ falha, a recuperação automática não será acionada. Recomendamos escrever o código da aplicação para levar em conta as falhas de conexão iniciais tentando a conexão novamente. O exemplo a seguir demonstra a repetição de falhas iniciais de rede usando a biblioteca de cliente Java RabbitMQ.
```
ConnectionFactory factory = new ConnectionFactory();
// enable automatic recovery if using RabbitMQ Java client library prior to version 4.0.0.
factory.setAutomaticRecoveryEnabled(true);
// configure various connection settings
try {
Connection conn = factory.newConnection();
} catch (java.net.ConnectException e) {
Thread.sleep(5000);
// apply retry logic
}
```
**nota**
Se uma aplicação fecha uma conexão usando o método `Connection.Close`, a recuperação automática de rede não será ativada ou acionada.
## Etapa 2: Monitorar métricas e alarmes do agente
Recomendamos monitorar regularmente [CloudWatch métricas](amazon-mq-accessing-metrics.md) e alarmes de seu agente Amazon MQ for RabbitMQ para identificar e resolver possíveis problemas antes que eles afetem seu aplicativo de mensagens. O monitoramento proativo é essencial para manter uma aplicação de mensagens resiliente e garantir o desempenho ideal.
O Amazon MQ for RabbitMQ publica métricas CloudWatch que fornecem informações sobre o desempenho do agente, a utilização de recursos e o fluxo de mensagens. As principais métricas a serem monitoradas incluem o uso da memória e do disco. Você pode configurar [CloudWatch alarmes](https://docs.aws.amazon.com/Ihttps://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Metrics.html) para quando seu corretor se aproximar dos limites de recursos ou sofrer uma degradação do desempenho.
Monitore as seguintes métricas essenciais:
**`RabbitMQMemUsed` e `RabbitMQMemLimit`**
Monitore o uso da memória para evitar alarmes de memória que possam bloquear a publicação de mensagens.
**`RabbitMQDiskFree` e `RabbitMQDiskFreeLimit`**
Monitore o uso do disco para evitar problemas de espaço em disco que podem causar falhas no agente.
Em implantações de cluster, monitore também as [métricas específicas do nó](rabbitmq-logging-monitoring.md#security-logging-monitoring-cloudwatch-destination-metrics-rabbitmq) para identificar problemas específicos do nó.
**nota**
Para saber mais sobre como evitar o alarme de alta memória, consulte [Abordar e evitar o alarme de alta memória](troubleshooting-action-required-codes-rabbitmq-memory-alarm.md#address-prevent-high-memory-alarm).