Já não é tão comum, mas ainda existe quem diga que RabbitMQ é rápido porque não tem banco de dados.
Essa é uma MEN-TI-RA!!
Ele entrega resiliência e performance, por outros motivos.
É sobre isso que vamos falar hoje!
Essa semana recebi uma mensagem que dizia algo aproximadamente assim:
Gago, como coloco um banco de dados, como Oracle como backend do RabbitMQ, para que eu possa ganhar segurança?
Se ele fez essa pergunta, então suspeito que talvez outros milhares de desenvolvedores tenham a mesma dúvida.
RabbitMQ possui banco de dados SIM
Embora você não configure esse banco de dados, não precise dar manutenção nele, sim, ele tem e usa um banco de dados, o MNESIA.
Aliás, existe uma questão relacionada ao upgrade do RabbitMQ que possui a característica de ser forward-only devido ao MNESIA.
O MNESIA é um banco de dados embarcado no Erlang, que, é a tecnologia por trás do RabbitMQ.
https://www.erlang.org/doc/man/mnesia.html
Mas se o RabbitMQ possui banco, por que podemos perder mensagens?
Primeiro por ignorância do utilizador.
A persistência depende de filas duráveis e mensagens persistentes.
Não basta apenas 1, é necessário os 2.
Filas Duráveis
Quando você cria uma fila, há uma flag a ser informada dizendo se a fila é durável ou transiente.
Mensagem persistente
Toda mensagem possui propriedades, uma delas é o Delivery Mode, que define de a mensagem é persistente ou não persistente.
Filas Duráveis + Mensagens Persistentes = Persistência em Disco (no MNESIA)
Não basta somente um:
Se a fila não é durável, mas a mensagem é persistente: foda-se!
Se a fila é durável, mas a mensagem não é persistente: foda-se também.
Simples assim!
O principal do assunto persistência pode ser lido nas páginas:
https://www.rabbitmq.com/queues.html#durability
https://www.rabbitmq.com/persistence-conf.html
Separei algumas partes aqui para ilustrar.
Por esse motivo, você não vai me ver ensinando a trabalhar com filas transientes, ou mensagens não persistentes fora de ambientes controlados, como um cursos avançados. Inclusive no RabbitMQ fundamentals eu abordo a existência de filas transientes e mensagens não persistentes, mas sequer aprofundo no tema, simplesmente porque não faz sentido. É mais arriscado do que saudável.
1.º: são raros os casos em que faz sentido.
2.º: Arriscar criar um ambiente com filas não duráveis, mensagens não persistentes não é nada saudável. É comum nas empresas copiarem soluções de uns projetos para os outros, sem considerar que os requisitos dos projetos podem ser diferentes. Então propagar a ideia de filas não duráveis ou mensagens não persistentes tem mais chance de gerar problema, do que qualquer benefício prático em si que possa ser obtido com a decisão.
3.º: Eu preparo os ambientes de curso para prover alguns tipos de acompanhamento de tal forma que consiga perceber esses cenários exóticos e direcionar, se julgar necessário.
Isso é novo? Nasceu há pouco tempo?
Definitivamente não. Uso o RabbitMQ desde ~2013 e sempre foi assim!
Aliás, desde essa época eu leio, vez ou outra, besteiras resultantes de entendimentos errados sobre o RabbitMQ pela internet. Seja em blog-posts ou nas redes sociais, em comentários dos mais diversos. Exatamente por isso passei a escrever sobre o assunto após passar raiva lendo atrocidades.
Mas como ele consegue ser mais resiliente que meu Oracle, SQL Server, PostgreSQL?
Simples.
Primeiro que cada instância do RabbitMQ tem seu próprio database. E você não pode mudar isso. Você não tem meios de assumir para si a gestão.
Isso está longe de você, o que é perfeito!
Não ter esse poder, evita que você faça merdas!
Somos nós, que ao tentar produzir falsas garantias, desgraçamos nossos próprios ambientes.
Com soluções equivocadas para problemas que não existem.
Ou para problemas que se fossem resolvidos profissionalmente, demandariam soluções das quais não estão ao nosso alcance, pois não dispomos dos recursos necessários para tal.
Você não faz update do MNESIA, você faz update do RabbitMQ inteiro, que por sua vez realizará o upgrade do mnesia, e de suas tabelas. E essa tarefa acontece a cada X anos.
Enquanto isso, não existe nenhuma mudança de estrutura nas tabelas do RabbitMQ durante todo o seu ciclo de vida. Após instalado, só as operações de escrita e leitura ocorrem nelas, e somente realizado pelo próprio RabbitMQ, onde a concorrência, é única e exclusivamente daquela instância e não de várias instâncias.
Já no Oracle, SQL Server da sua aplicação você tem a IDE do DBA, tem ferramenta de monitoramento plugada no banco, tem não sei quantas instâncias de não sei quantas aplicações, cada uma fazendo um conjunto diferente de operações em tabelas de todos os tipos e estruturas. Inclusive operações blockantes de escrita e leitura e mudanças constantes nas estruturas de dados.
Um banco relacional comum, precisa lidar com esses dilemas. O RabbitMQ e o MNESIA, não.
Outro ponto é que muitas vezes para ter maior resiliência, seus bancos relacionais armazenam dados não tão perto dos servidores. Em NAS ou serviços de storage que estão a centenas de metros de cabos do servidor em si, com não sei quantas camadas de rede entre o processador e o storage. Isso aumenta a latência no I/O.
Quando se pensa em RabbitMQ, ele foi projetado para gravar no disco mais próximo, em um SSD de preferência. E nos casos de clusters, a resiliência é assegurada pelo consenso das Quorum Queues.
Conclusão
Posts não ensinam, eu já felei isso em Não estude por tutoriais. Também já falei sobre como perder mensagens no post Como perder mensagens com RabbitMQ.
Nosso amigo, que fez essa pergunta, foi apenas uma vítima. Aliás, se não fosse a pergunta dele, eu possivelmente nunca escreveria esse post aqui. Foi ela que me permitiu parar para explicar esse assunto.
Não importa o empenho e o esforço de conscientização, todo dia aparece uma bobagem nova ou velha em algum blog, ou rede social. Fruto de quem tenta estudar por posts ou tutoriais e capota, ensinando e divulgando entendimentos errados.
RabbitMQ é sério o suficiente para te dar flexibilidade, mas isso pode te induzir ao erro. Eu não sei contar quantas vezes já vi grandes erros cometidos nesse assunto por pura ignorância, desconhecimento.
Aliás, não é preciso ir muito longe, esse é o tipo de conhecimento que está na página 2 da documentação oficial.
Eu já estabeleci um canal de comunicação com um membro da equipe do RabbitMQ e mandei um e-mail para o time, falando sobre a documentação e sobre como tem se tornado problemático a qualidade do entendimento da solução pelo mercado em geral.
O que tenho feito aqui é dar foco à esses entendimentos errados, é criar um lugar onde podemos falar sobre isso, com a esperança de que você também leia.
Espero ter ajudado a evitar problemas por aí!
E se você quiser fazer parte do Mensageria .NET – RabbitMQ para Aplicações .NET você pode começar a estudar comigo hoje ainda.
0 comentários