Melhores práticas para durabilidade e confiabilidade de mensagens no Amazon MQ para RabbitMQ

Antes de mover seu aplicativo para produção, conclua as seguintes práticas recomendadas para evitar a perda de mensagens e a sobreutilização de recursos.

Etapa 1: use mensagens persistentes e filas duráveis

Mensagens persistentes podem ajudar a evitar a perda de dados 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. 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 as confirmações do editor e a confirmação de entrega ao 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 a confirmação do editor, não há confirmação de que uma mensagem foi processada com sucesso e seu corretor pode enviar mensagens que não consegue 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 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 UpdateConfigurationAPI para aumentar o consumer_timeout valor.

Etapa 3: mantenha 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, 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. 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.

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