Memória e Disco no RabbitMQ: Entendendo o Comportamento Real do Broker | RabbitMQ
- Memória e Disco no RabbitMQ: Entendendo o Comportamento Real do Broker | RabbitMQ
Visão Geral
O RabbitMQ utiliza memória e disco de forma complementar, não sequencial. Diferente de uma interpretação simplista (memória → depois disco), o broker opera com ambos simultaneamente para equilibrar:
- performance (memória)
- durabilidade (disco)
A imagem abaixo representa o estado atual de um nó RabbitMQ e será usada como base para análise:
Memória no RabbitMQ
O que representa
A métrica de memória indica o consumo total do broker, incluindo:
- mensagens em trânsito
- buffers de entrega
- índices internos
- metadados de filas
- conexões e canais
- estruturas internas do Erlang
No exemplo:
Memory: 171 MiB
High Watermark: 797 MiB
Como a memória é utilizada
Mesmo quando você usa disco, a memória continua sendo essencial:
Producer → Memória → (opcional) Disco → Consumer
A memória é usada para:
- garantir baixa latência
- armazenar mensagens “quentes”
- gerenciar filas e consumers
- controlar acknowledgements
High Watermark (controle crítico)
O RabbitMQ define um limite de uso de memória:
~40% da RAM por padrão
Quando esse limite é atingido:
- publishers são bloqueados
- o broker ativa flow control
- evita crash por falta de memória (OOM)
Isso é um mecanismo de backpressure, essencial em sistemas distribuídos.
Impactos arquiteturais
A memória cresce com:
- número de filas
- número de mensagens
- tamanho das mensagens
- número de consumers
- backlog não processado
👉 Mesmo com persistência em disco, a memória continua sendo o gargalo principal.
Disco no RabbitMQ
O que representa
A métrica de disco indica espaço disponível para:
- mensagens persistentes
- logs internos
- estruturas de fila durável
- quorum queues (log-based)
No exemplo:
Disk: 40 GiB disponível
Low Watermark: 1.9 GiB
Quando o disco é utilizado
O disco entra em ação quando:
- mensagens são persistentes (
deliveryMode = 2) - filas são duráveis
- existe backlog grande
- uso de lazy queues ou quorum queues
Low Watermark (proteção de integridade)
Quando o disco atinge o limite mínimo:
Low Watermark atingido
O RabbitMQ:
- bloqueia publishers
- evita corrupção de dados
- preserva integridade do sistema
Persistência não elimina uso de memória
Mesmo com mensagens persistentes:
- índices ficam em memória
- buffers continuam ativos
- mensagens recentes podem estar em RAM
👉 Ou seja:
Disco ≠ substituto da memória
Interação entre Memória e Disco
Modelo correto
✔ memória e disco trabalham juntos
✔ memória é o caminho crítico (performance)
✔ disco é o mecanismo de durabilidade
Modelo incorreto (comum)
❌ "usa memória e depois joga tudo no disco"
Isso não acontece dessa forma.
Comportamento real
| Situação | Comportamento |
|---|---|
| Baixo volume | tudo em memória |
| Volume moderado | memória + disco |
| Alto backlog | disco cresce, memória ainda relevante |
| Pressão de memória | ativa flow control |
| Pressão de disco | bloqueia publishers |
Tipos de fila e impacto
Classic Queue
- híbrido (memória + disco)
- comportamento adaptativo
Lazy Queue
x-queue-mode = lazy
- prioriza disco
- reduz uso de memória
- aumenta latência
Quorum Queue
- baseada em log
- sempre usa disco
- mantém índice em memória
👉 mais robusta, porém mais custosa
Relação com o mau uso (muitas filas)
Quando você cria muitas filas:
Memória
- cresce com metadados
- cresce com índices
- cresce com mensagens acumuladas
Disco
- cresce com persistência
- cresce com backlog
- cresce com logs
Resultado
Mais filas → mais memória + mais disco + mais CPU
Insight arquitetural
Sistemas de mensageria modernos seguem um princípio:
memória para throughput, disco para durabilidade
Conclusão prática
- O RabbitMQ não é um sistema disk-first
- Ele é memory-first com suporte a persistência
- Memória sempre será o fator limitante principal
- Disco protege dados, mas não resolve pressão de carga
Regra de ouro
Se você precisa de alto throughput → cuide da memória
Se você precisa de durabilidade → cuide do disco
Se você ignora um dos dois → o sistema quebra