Fala pessoal, tudo bem?
Quais projetos de filas e mensagerias são os mais estáveis do mercado, por que escolhê-lo e quais trade-offs?
Abraços
que legal a sua pergunta, apenas acho que vc copiou ela de alguma prova, espero estar enganado.
eu vou falar de uma forma generica: na minha empresa utilizamos RabbitMQ e ZeroMQ.
RabbitMQ não exige que vc sincronize os processos pois salva a fila em memoria/disco. ZeroMQ ja vai bloquear quem esta escrevendo se ninguem estiver lendo.
na pratica vc quer saber: para um dado problema onde vc vai usar filas, se o(s) processo(s) que lê parar de ler, quem escreve pode bloquear ( como em um unix pipe ) ?
se em hipotese nenhuma, vc vai preferir RabbitMQ. se pode, ai vc tem que analisar as duas soluções.
tivemos alguns problemas com sharding na ultima versão do RabbitMQ e resolvemos configurando o prefetch e QoS, alem de forçar a conexão diretamente com cada shard ao inves de deixar isso para o plugin. ficou bom mas ate descobrir isso demorou um bocado.
edit: existem outras tecnologias. eu citei duas. com certeza a galera vai se pronunciar aqui.
esqueci de mencionar tb q um dia eu simulei uma fila usando Redis ( com RPUSH e LPOP ) e isso funcionou redondo por varios meses exceto quando o consumidor demorava demais… mas ai é muito magaiverismo
2 curtidas
Muito obrigado pela sua ajuda.
Pode ficar tranquilo que isso não é dúvida de prova não. Já faz algum tempo que me formei.
Eu perguntei mais no sentido de entender se tem alguma coisa mais atual.
Sua resposta me ajudou, agora sei qual caminho seguir.
Abs
Uma outra dúvida.
A arquitetura que estou desenhando poderá ser síncrona (Pagamento Cartão de Crédito) ou assíncrona (cancelamento de compra).
Faz sentido alimentar alguma base de dados com isso ou o próprio RabbitMQ trata esse tipo de priorização?
Para armazenamento de retornos que será em JSON, estava pensando em Elastic Search? Faz sentido ou ficaria melhor usar um Firebase ou MongoDB?
Abs
pra ser mais divertido vc tem o padrão JMS
eis um exemplo com RabbitMQ https://blog.pivotal.io/pivotal/products/messaging-with-jms-and-rabbitmq
Oi @paulofernandesjr. Hoje, trabalho usando o Camel (ActiveMQ) e nos atende muito bem, pois chegamos a enfilerar mais de 100 mil registros, dependendo o cliente. Além disso, o motivo é que precisávamos de um processamento assíncrono e, na época (eu não estava aqui na empresa), esta foi a decisão tomada. Funciona bem, atende a demanda, é possível clusterizar e etc.
Mas também já trabalhei com fila da AWS (o Amazon SQS), porque o sistema era SaaS. O engenheiro envolvido no projeto elogiava bastante esse serviço, eu usava pouco. Tudo depende da sua demanda, o que necessita e etc para tomar a decisão de usar ou não. Se pensar apenas em processamento assíncrono, o próprio JEE disponibiliza anotações para tal, então, normalmente, vai bem além de “apenas” processo assíncrono.
Abraços.
Cara, são bastante dúvidas que, em minha opinião, a resposta é “depende”. Tu trafega JSON por que usufrui de APIs ou por que sua base de dados é não relacional? É produto on premise ou SaaS? Terá ambos?
Enfim, se tu precisa de um processamento de cancelamento de compra assíncrono, não vejo motivos para uma fila totalmente separada. Tu pode usar a anotação @Asynchronous em conjunto com a anotação @Schedule, caso queira um “job” que cancele de tempos em tempos. Enfim, avalia se realmente precisa de algo externo que o próprio JEE não suporte (desde o JEE 6 tem o que cito).
1 curtida
Vejamos: um grande desafio é o seu modelo de dados. por exemploo cancelamento de compra vai atualizar o status de uma compra que ja existe OU a compra sera imutavel e vc tem, na verdade, um historico de transações que pode incluir compra e cancelamento ( e outras coisas )?
isso faz BASTANTE diferença.
Nunca trabalhei com filas prioritarias. Eu ACHO que vc pode forçar uma dada prioridade OU talvez vc possa colocar coisas ‘na frente da fila’. Tem que ler a documentação.
Ai vc fala em “faz sentido uma base de dados”? bom, depende. pra que?
pode fazer sim sentido atualizar no banco da dados o status de uma tarefa ( ate para controle e monitoramento ). dados podem sumir então pode ser bom vc pensar nisso (tipo vc deu ACK na mensagem mas não processou tudo e o processo morreu por uma Exception do demonho).
armazenamento de retornos eu nao entendi bem.
mano vc tem um problema que vc quer resolver com filas. a primeira coisa é modelar o seu sistema de forma a compreender filas e nesse caso vc tem diferentes componentes que vão funcionar quase que de forma independente. para cada problema vc endereça uma solução. MongoDB tem vantagens e vantagens. ElasticSearch tem o problema do refresh rate.
agora pensa bem: deu um pau bizarro na aplicação e vc não sabe o que ocasionou. vc pode usar ElasticSearch para armazenar as ultimas x horas de dados na fila e, então, vc pode tentar reproduzir.
são perguntas por demais genericas. dificil de dar uma sugestão. mão sei ate que ponto vc tem exigencias por contrato de alguma coisa tipo “nao pode guardar dados do usuario em uma nuvem” ou coisas do tipo.
vc pode trabalhar com consistencia eventual? faz sentido em alguma parte do teu sistema?
perceba que uma solução robusta pode envolver diversos bancos de dados.
eu no meu trampo eu uso: mariadb, redis, riak, couchbase e elasticsearch: cada um é responsavel por algumas coisas. redis pode ser cache como tb é monitoração ( com hiper log log ). elasticsearch é otimo para algumas consultas mais complexas e monitração ( ELK ). e por ai vai.
vc precisa pensar no design da sua aplicação. as caixinhas vc preenche com o que existe no mercado.
1 curtida