Como perder mensagens utilizando RabbitMQ

Como perder
mensagens utilizando
RabbitMQ
Arthur Santos

Agenda
• Conceitos básicos
• Connection
• Channel
• Queue
• Message
• Exchange
• Protocolos
• Cenários de possível perda de mensagens
• AutoAck
• TTL
• Mensagens não persistentes
• Mecanismos de Alta Disponibilidade
• Exemplos
• AutoAck Habilitado – Cenário Feliz
• AutoAck Habilitado – Cenário de Falha
• AutoAck Desabilitado – Cenário de Falha
• TTL
1

Conceitos Básicos - Connection
3
• Todos protocolos suportados pelo RabbitMQ são baseados em TCP/IP com conexões
duráveis (long-lived connections)
• Cada conexão de cliente com o broker utiliza uma única conexão TCP na porta
destinada ao protocolo específico que estiver sendo utilizado.
• Após conectar-se ao broker, os clientes podem publicar e consumir mensagens,
definir a topologia (queues, exchanges, bindings) e utilizar as operações suportadas por
cada protocolo.
• Como a conexão permanece ativa, as mensagens são entregues de forma push-
based, ou seja, não é necessário realizar polling, elas são enviadas de forma reativa

Conceitos Básicos - Channel
• Podem ser vistos como conexões lógicas leves que são
úteis quando uma mesma aplicação deseja ter múltiplos
canais isolados de comunicação com o broker
• Permite o compartilhamento de uma mesma conexão
TCP/IP com múltiplas conexões lógicas ao broker.
• Evita o uso excessivo de recursos de hardware
• Simplifica questões como liberação de portas em firewall.
• Se baseia em um channel number que é um número
identificador compartilhado entre o cliente e o broker.
• São excluídos quando a conexão é encerrada
• Permite o isolamento do tratamento de erros e métricas
4

Conceitos Básicos - Queue
• Estrutura sequencial de dados, que permite realizar as ações de publicação (enqueue) e
consumo (dequeue) de mensagens entre produtores e consumidores. Funciona como um
grande buffer, limitado à quantidade de memória e disco disponíveis.
• Podem ser classificadas quanto à persistência:
• Duráveis: persistem mesmo após o reinício do broker
• Transientes: são apagadas uma vez que o broker é reiniciado
• Filas também podem ser criadas como “Exclusivas”, o que significa que poderão ser
utilizadas por apenas uma conexão, e são excluídas quando essa conexão é encerrada.
5

Conceitos Básicos - Message
• São as mensagens enviadas ao broker, que podem ser classificadas quanto ao tipo
de entrega (Delivery Mode):
6
• Não Persistentes: são escritas no
disco somente quando o espaço em
memória estiver sob pressão
(memory pressure)
• Persistentes: são escritas no
disco assim que elas chegam à
fila, porém, são mantidas em
memória também na medida do
possível.
É possível configurar as operações de liberação de memória de uma fila com o parâmetro:
lazy_queue_explicit_gc_run_operation_threshold
(quanto mais alto, maior performance, porém, maior o uso de memória)

Conceitos Básicos - Exchange
• Mecanismo de roteamento de mensagens provido pelo RabbitMQ
• Permitem implementar diversos Enterprise Integration Patterns
• Permitem multiplexar uma mesma mensagem para várias filas, o que pode ser
útil quando queremos trabalhar com comunicação multicast
7
Fonte das imagens:
https://www.rabbitmq.com/tutorials/amqp-concepts.html

Conceitos Básicos - Exchange - Enterprise Integration Patterns
8
Fonte das imagens:
https://www.enterpriseintegrationpatterns.com/patterns/messaging/
https://camel.apache.org/components/latest/eips/message-router.html
https://camel.apache.org/components/latest/eips/publish-subscribe-channel.html
https://camel.apache.org/components/latest/eips/content-based-router-eip.html
• Message Router
• Publish Subscribe
• Content Based Router
Em algumas situações, por exemplo, quando uma mensagem
não pode ser roteada, ela pode ser retornada para o produtor,
descartada, ou, se o broker implementar uma extensão
específica, ser enviada para uma "dead letter queue". O produtor
determina esse comportamento definindo propriedades
específicas nas mensagens enviadas.
funciona como um filtro que roteia de um canal para outro
baseado em alguma condição - por ex.: uma routing key roteia de um canal para outro baseado no conteúdo da mensagem
roteia de um canal para N outros baseado em um
canal/tópico de interesse

Conceitos Básicos - Exchange - Tipos e Aplicações
9
Tipo de Exchange Descrição
Default Por padrão, toda fila é vinculada a esse exchange, onde a
Routing Key utilizada é o próprio nome da fila. Interessante para
a troca de mensagens simples entre produtor e consumidor.
Direct Entrega mensagens para uma fila baseado em uma routing key.
Interessante para implementar o padrão Message Router.
Fanout Entrega as mensagens para todas as filas que estiverem
vinculadas a ele, ignorando as routing keys. Interessante para
implementar comunicação anycast.
• Os tipos de algoritmos de roteamento usados dependem do tipo de Exchange e das regras
configuradas, também chamadas de bindings.

Conceitos Básicos - Exchange - Tipos e Aplicações
10
Tipo de Exchange Descrição
Topic Entrega as mensagens para uma ou mais filas
baseando-se na routing key e no padrão que foi
utilizado para vincular a fila ao exchange. Interessante
para o padrão publish/subscribe.
Headers Desenhado para rotear mensagens baseado em
múltiplos atributos que são melhores expressos como
cabeçalhos de mensagens do que uma única routing
key. Interessante para implementar o padrão Content
Based Router.

Protocolos
12
Há diversos protocolos suportados e que podem ser habilitados como plugins. O protocolo
mais comumente utilizado é o AMQP versões 0-9-*.
• AMQP 0-9-1 + extensões - é a versão mais recente do protocolo “core” suportado pelo
broker, porém, possui diversas extensões como, por exemplo:
• Controle de TTL a nível de fila ou de mensagem
• Dead letter queue - que permite rotear uma mensagem para outros tópicos caso elas
sejam expiradas ou rejeitadas
• Limite de tamanho de filas
• AMQP 1.0 - versão difere bastante do AMQP 0-9-1, possui diversas limitações, e menos
clients disponíveis. No entanto, é mais simples de adicionar suporte a ela em diferentes
brokers.
• O plugin não suporta, por exemplo, entrega do tipo Exacly Once

Protocolos
13
• STOMP - Simple Text Oriented Messaging Protocol é um protocolo simples baseado em
texto, pode ser usado, inclusive, direto via telnet.
• Suporta utilização de um adaptador para Websockets
• Por ser muito simples, possui grande variedade de clients
• https://stomp.github.io/implementations.html
• MQTT - protocolo binário leve, destinado à comunicação pub/sub.
• Se baseia em algoritmo de consenso, ficando disponível somente se a maioria dos
nós do cluster estiver online.
• Suporta armazenamento em memória ou disco
• Suporta utilização de um adaptador para WebSockets

Cenários de possível
perda de mensagens

Cenários de possível perda de mensagens - AutoAck
15
• É possível configurar os consumidores para enviarem um sinal de Acknowledgement
automaticamente, logo após realizar a leitura da mensagem.
• Esse mecanismo traz certa comodidade de implementação quando não precisamos nos
preocupar se o processamento da mensagem foi finalizado. O desenho abaixo ilustra um
cenário de sucesso com essa configuração.
1. Produtor envia M1 para o broker
2. Consumidor recebe M1 e responde com o AutoAck
3. Consumidor processa com sucesso M1
4. Broker exclui a mensagem (concorrente com 3)

16
• O ponto de atenção é que, consumidores podem falhar logo após enviar o ACK para o
broker, o que pode ser indesejado.
• O desenho abaixo ilustra um cenário de perda de mensagem utilizando AutoAck.
2. Consumidor recebe M1 e responde com o AutoAck
3. Consumidor falha e NÃO processa M1
4. Broker exclui a mensagem (concorrente com 3)
Obs.: Como o consumidor confirmou o recebimento da
mensagem, o broker não se preocupará em entregá-la
novamente

17
• A outra forma de implementar é realizando o envio manual do sinal de Acknowledgement.
• Com isso, em caso de falha, o broker tentará entregar a mensagem novamente
2. Consumidor recebe M1, falha e NÃO processa M1
3. Broker reenvia M1
4. Consumidor recebe M1 pela segunda vez e processa
M1
5. Consumidor envia ACK de M1
6. Broker exclui a mensagem (somente após 4)
Obs.: Se o processamento do consumidor não for
idempotente, é possível gerar inconsistências, por
exemplo, um pagamento realizado em duplicidade

Cenários de possível perda de mensagens - TTL - Time-to-live
18
• Dependendo do protocolo utilizado, existe suporte para a definição de um tempo máximo
de vida da mensagem na fila (TTL).
• Não há um valor default, pois, a fila pode ser criada sem essa policy.
• Essa configuração pode ser realizada para uma mensagem específica, ou para uma fila
inteira.
• Caso não seja configurada uma DLQ (Dead Letter Queue), as mensagens que não forem
lidas a tempo pelos consumidores poderão ser perdidas. Em contrapartida, se o TTL for
muito grande, pode não haver recursos disponíveis (Memória e Disco) para armazenar as
mensagens.
1. Produtor envia M1
5. M1 atinge seu TTL e é excluída da fila
6. Consumidor inicia a leitura de mensagens
7. Consumidor lê M2, pois M1 já foi excluída
da fila

Cenários de possível perda de mensagens - TTL - Time-to-live
19
• O desenho abaixo ilustra uma possível alternativa utilizando uma Dead Letter Queue.
• A configuração é realizada adicionando uma policy à fila
5. M1 atinge seu TTL
6. M1 é movida para a DLQ
7. Consumidor inicia a leitura de mensagens
8. Consumidor lê M2, pois M1 já foi excluída da
fila
Obs.: M1 pode ser reprocessada futuramente e, inclusive,
ser reenviada para a fila original
args.put("x-dead-letter-exchange", "some.exchange.name");
args.put("x-dead-letter-routing-key", "some-routing-key");

Cenários de possível perda de mensagens – Mensagens não persistentes
20
• Quando há indisponibilidade de um ou mais nós do cluster de RabbitMQ, mensagens que
estejam na memória desses nós podem ser perdidas
5. Broker é reiniciado e as mensagens
armazenadas na fila são PERDIDAS
Obs.: É possível utilizar mecanismos de High Availability
como as Mirrored Queues ou Quorum Queues para
evitar esse tipo de perda de mensagens

Mecanismos de Alta
Disponibilidade

Mecanismos de Alta Disponibilidade – Mirrored Queues
22
• Permite obter tolerância de partição, pois replica as
mensagens das filas para mais nós do cluster
• Utiliza Chained Replication Algorithm (topologia de anel -
cadeia de mirrors)
• Erlang Partition Detection é responsável pela
descoberta de novas partições.
• net_ticktime define a frequencia do heartbeat entre
os nós do cluster
• Se configurado muito lento - pode demorar para
identificar partições offline
• Muito rápido - pode dar falsos positivos em relação
aos nós que estão disponíveis
• Sincronização usa mais rede que o necessário, falhas de
partições são lentas de detectar
• Quando um broker (Nó) cai e sobe novamente, ele sobe
vazio
• Comando "queues rebalance" pode ser usado para
rebalancear as filas manualmente, ou pode ser
configurada a replicação automática
Fonte das imagens:
https://www.rabbitmq.com/blog/2020/04/20/rabbitmq-gets-an-ha-upgrade/
https://www.rabbitmq.com/nettick.html

Mecanismos de Alta Disponibilidade – Mirrored Queues – Sincronização
23
• Sincronização pode ser:
• Manual ou Automática
• Param o cluster para fazer a sincronização dos brokers
• Tornam o serviço indisponível momentaneamente
• Usadas quando queremos priorizar consistência no lugar de disponibilidade
• Ideal para filas pequenas, para minimizar o tempo de indisponibilidade
• Natural
• Normalmente usada para filas grandes, somente são replicadas as mensagens
novas para novos mirrors, isso pode causar a perda de mensagens antigas que
por ventura tenham ficado apenas no nó que estava previamente ativo, caso
ele venha a falhar
Abaixo temos um exemplo de policy onde as filas cujos nomes começam com "two." são
espelhadas para quaisquer 2 nós do cluster, com automatic synchronisation habilitada:
rabbitmqctl set_policy ha-two "^two."
'{"ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"}' Fonte do comando:
https://www.rabbitmq.com/ha.html#interstitial

Mecanismos de Alta Disponibilidade – Quorum Queues
24
• Criadas para maior Data Safety - passarão a ser a configuração padrão de HA
• Usa Raft Consensus Algorithm – Mesmo utilizado pelo Consul, Vault
• https://raft.github.io/
• Por exemplo, um cluster de 5 servidores pode continuar operando mesmo que 2
servidores falhem (N/2+1 ativos). Se mais servidores falharem, eles pararão de
progredir (mas nunca irão retornar um resultado incorreto).
• Prioriza consistência em detrimento da disponibilidade
• Utiliza a biblioteca RA, que é mais rápida para identificar queda de nós ou rede entre
os brokers
• Introduz o conceito de Replication Factor
• É tolerante a falhas, desde que seja mantida a maioria para eleição e replicação de
mensagens
• Recomendado usar números ímpares de nós para quorum
• Quanto maior o número de réplicas, menor a performance, naturalmente
• Não suportam algumas funcionalidades das mirrored queues, como:
• TTL
• Mensagens não persistentes
• Prioridades de mensagens

25
• Dividido em 2 fases
• Eleição de líder
• Assim como nas mirror queues, é necessário eleger um nó Master/Líder ao iniciar
o cluster, ou ao perder um nó líder
• RA dispara as eleições quando identifica a queda de um nó Líder
• Biblioteca RA é mais rápida para identificar queda de nós ou rede entre
os brokers
• Replicação de log - ACKs são direcionados para o líder, e não mais para cada broker
em forma de anel
• A estrutura de dados por baixo é um log
• Replica comandos de ENQUEUE e de ACKs no command log para todos os
brokers
• Baseado em replicação de logs - uma vez que a maioria dos nós possuem a
mensagem, então ela pode ser enviada para os consumers
• A queue é apenas um snapshot instantâneo do command log, o que garante
maior segurança sobre a informação armazenada em comparação às mirrored
queues
• Conforme o broker vai recebendo os ACKS, e replicando esses ACKs para os
nós, é possível rodar a limpeza do log, removendo as mensagens que já
possuem confirmação de leitura

26
• Storage
• Write ahead log – a mensagem é escrita em disco antes de replicar para todos nós
• Quando o log se torna muito grande (acima de 500GiB) é criado um novo arquivo de WAL (Write
Ahead Log) para melhor performance
• Periodicamente, WAL é lido e os dados movidos para segment files
• WAL é usado apenas para garantir que nenhum dado será perdido - como em um banco de dados
• É possível trabalhar com um ou mais segment files por queue
• A mensagem sempre será escrita uma vez
• Potencialmente ela será escrita 2 vezes (quando for movida para um segment file)
• Comparado com Mirrored Queues – onde a mensagem pode nunca ser escrita, ou escrita
apenas 1 vez
• Que é uma das causas da limitação forte entre consistência e disponibilidade
• Para criar uma Quorum Queue, basta criá-la com o argumento x-queue-type igual a quorum
• Não é possível utilizar polices para configurar uma fila como quorum queue

Exemplos – Setup do Ambiente
28
• K6
• https://k6.io/docs/
• Producer Service
• https://github.com/alvsantos/rabbitmq-
producer-service
• RabbitMQ
• https://github.com/harbur/docker-
rabbitmq-cluster
• Consumer Service
consumer-service
• Processor Service
processor-service
AutoAck
HABILITADO
DISPONÍVEL

Exemplos - AutoAck Habilitado – Cenário Feliz
29
• Com o K6, Iremos simular 10 usuários
virtuais postando uma mensagem a cada
100ms, durante 30s
• Pode gerar o máximo de 3000
mensagens, porém, devido aos tempos
de resposta da API, será menos que isso
• Manteremos o Consumer Service com
AutoAck HABILITADO
• Manteremos o Processor Service
DISPONÍVEL durante todo tempo
• O resultado esperado é que 100% das
mensagens enviadas sejam computadas no
Processor Service
AutoAck
HABILITADO
DISPONÍVEL

Exemplos - AutoAck Habilitado – Cenário de Falha
30
100ms, durante 30s
AutoAck HABILITADO
• O Processor Service ficará INDISPONÍVEL
por alguns instantes
• O resultado esperado é que as mensagens
consumidas enquanto o Processor Service
estiver INDISPONÍVEL sejam PERDIDAS
AutoAck
HABILITADO
INDISPONÍVEL

Exemplos - AutoAck Desabilitado – Cenário de Falha
31
100ms, durante 30s
AutoAck DESABILITADO, ou seja,
enviaremos o ACK manualmente
• O Processor Service ficará INDISPONÍVEL
por alguns instantes
• O resultado esperado é que 100% das
mensagens enviadas sejam processadas
no Processor Service após o
restabelecimento do serviço
AutoAck
DESABILITADO
INDISPONÍVEL
* Garantia de ordem ocorre somente se as mensagens forem publicadas em 1 channel, 1 exchange,
1 queue.
* Em versões anteriores a 2.7.0. a ordem ainda pode ser perdida por ações de requeue

Exemplos – TTL – Time-to-live
32
100ms, durante 30s
AutoAck DESABILITADO
• Manteremos o Processor Service
DISPONÍVEL durante todo tempo
• Tornaremos o Consumer Service
INDISPONÍVEL por 10s
• Configuraremos o TTL de 5s nas mensagens
• O resultado esperado é que algumas das
mensagens enviadas durante a
indisponibilidade do Consumer Service
sejam PERDIDAS
AutoAck
DESABILITADO
INDISPONÍVEL
Por 10s
TTL=5s

Referências
34
• https://www.rabbitmq.com/ha.html#interstitial
• https://www.rabbitmq.com/quorum-queues.html#replication
• https://www.rabbitmq.com/confirms.html
• https://www.rabbitmq.com/blog/2020/04/20/rabbitmq-gets-an-ha-upgrade/
• https://www.rabbitmq.com/quorum-queues.html#motivation
• https://www.rabbitmq.com/connections.html
• https://www.rabbitmq.com/persistence-conf.html
• https://blog.rabbitmq.com/posts/2015/10/new-credit-flow-settings-on-rabbitmq-3-5-5/
• https://www.rabbitmq.com/dlx.html
• https://www.rabbitmq.com/quorum-queues.html#replica-rebalancing
• https://www.rabbitmq.com/semantics.html

Como perder mensagens utilizando RabbitMQ

Como perder mensagens utilizando RabbitMQ

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Como perder mensagens utilizando RabbitMQ

Semelhante a Como perder mensagens utilizando RabbitMQ (20)

Como perder mensagens utilizando RabbitMQ