Então você já usa Redis no seu stack, e optou por usá-lo também para publicar mensagens de um lado para outro em sua aplicação. Talvez seu amigo tenha dito que “não precisa de RabbitMQ”, ou que “é um canhão para matar uma formiga”. A começar pela pergunta: Você busca resiliência nesse papel? Se a resposta for sim e você usa Redis como se fosse um Message Broker, vou lhe apresentar alguns dados para mostrar que está redondamente equivocado.
Após o Hangout sobre RabbitMQ no Canal dotNET, foi criado um grupo sobre RabbitMQ no telegram, e lá surgiu uma questão super recorrente, mas que negligenciei ao longo dos últimos anos. De fato é um tema que me deixa incomodado, então vamos à ele.
Não se assuste, esse é um título provocativo.
A pergunta: Rabbit e Redis ambos como Message Broker? E qual se encaixa melhor para cada cenário?
A primeira resposta, objetiva para essa pergunta é: Redis não é um Message Broker.
Poderíamos encerrar a discussão aqui, mas há diversos desdobramentos na decisão de usar Redis para a publicação de mensagens. Vale a pena detalhar isso para que você não construa um castelo de areia.
Sobre mensageria, você busca resiliência? Redis não irá te entregar o que você precisa no que diz respeito à troca de mensagens resilientes!
Redis Pub/Sub
O Redis oferece um mecanismo de pub/sub onde você consegue plugar diversos processos e usar sua conexão para publicar e assinar mensagens.
Leia a documentação de Pub/Sub do Redis para saber mais sobre a feature.
Para a questão original, respondi com novas perguntas. Abaixo sigo com as perguntas que fiz:
- Você busca resiliência?
- Você habilitou persistência em disco?
- Qual é o modo de persistência escolhido? RDB ou AOF?
- De quantos em quantos segundos ele está escrevendo em disco?
- Com quantas mensagens por segundo você tem trabalhado?
- O que você vai fazer quando sua instância redis cair entre um ciclo de persistência e outro?
O problema na decisão de usar Redis como se ele fosse um Message Broker, é assumir que Redis seja um Message Broker e naturalmente presumir que seja resiliente: Não é!
A maioria dos setups do Redis sequer habilita persistência em disco. Quando habilitado, em geral usa a estratégia de RDB (persiste de tempos em tempos) e raríssimos setups temos a utilização de AOF (de fato resiliente, com persistência durante a escrita). E se você ler a documentação vai encontrar ressalvas e mai ressalvas a respeito de AOF e Performance.
Persistência no Redis
O Redis oferece 2 modelos de persistência: RDB e AOF:
- RDB – Baseada em ciclos de persistência de tempos em tempos.
- AOF – Baseada em eventos de escrita no Redis
Leia a documentação de persistência do Redis. para conhecer as estratégias de persistência, benefícios e perdas de cada uma.
Se você leu a documentação no link desse card aqui acima, leu que tudo que precisava para desistir do Redis para mensageria resiliente.
Redis é ruim? Devo tirar da minha aplicação?
Não! De forma alguma, é o melhor cache que conheço. O calcanhar de Aquiles do Redis é exposto quando ocorre uma queda, seja por um shutdown, reboot, ou recriação. Esses eventos têm muito potencial para causar perda de chaves. No papel de cache, isso não é necessariamente um problema, o cache será populado novamente. Mas quando estamos falando de mensagens resilientes, Redis não é uma possibilidade muito confiável. Um segundo de mensagens perdidas pode representar 10, 20, 1000 pedidos no limbo absoluto.
Redis Pub/Sub, nunca devo utilizar?
Eu não disse isso. O ponto é que se ele pode cair e perder mensagens, ele vai cair e vai perder mensagem.
Será que alguma mensagem perdida pode representar uma compra não processada? Um pagamento não processado?
Regra
Se seu dado não estiver persistido ou residindo momentaneamente em um mecanismo resiliente, deixá-lo no Redis é um risco para o teu negócio.
Se seu dado estiver em um local resiliente, ou puder ser descartado em caso de um crash ou recriação do container, então não há problema algum.
Aplicações que trabalham com cache ativo (preenchimento do cache é um processo autônomo, geralmente executado no warmup) também precisam de atenção especial.
Conclusão
Redis é excelente, mas é preciso tomar cuidado para não dar responsabilidades demais à ele. Poucas são as vezes em que de fato existe o tal “canhão para matar formiga”. Aplicações especializadas, quando usadas corretamente, poupam tempo e dinheiro.
Os desafios para matar elefantes em geral são os mesmos para matar suas formigas… e vice-versa, isso no nosso mundo!
🎙A propósito, no chat um amigo de um amigo escreveu: “Ae, me indica uma base de dados rápida. Não precisar ser relacional…. Para produzir uma fila” 🤬🤬🤬
É cada um que aparece…
Texto simples e objetivo, parabéns pelo post.
Obrigado Braga!