# Estudo direcionado de comparação de performance em softwares de messageria.

## links utilizados nesse estudo

* https://www.confluent.io/blog/kafka-fastest-messaging-system/?utm_medium=sem&utm_source=google&utm_campaign=ch.sem_br.nonbrand_tp.prs_tgt.kafka_mt.mbm_rgn.latam_lng.eng_dv.all&utm_term=%2Bkafka%20%2Brabbitmq&creative=&device=c&placement=&gclid=Cj0KCQjwnqH7BRDdARIsACTSAduPuqaWmf9xLnEL4Bx9tM-g580zL3zvN5X04LpZFvcNCCpN6Bp3skEaAqk7EALw_wcB

* https://www.confluent.io/kafka-vs-pulsar/

* https://blog.knoldus.com/kafka-consumer-push-vs-pull-approach/

* https://cloudplatform.googleblog.com/2014/06/rabbitmq-on-google-compute-engine.html

* http://openmessaging.cloud/docs/benchmarks/

* https://github.com/confluentinc/openmessaging-benchmark

* http://openmessaging.cloud/

## Resultados de leituras

* [Benchmark de Messageria pela Confluent](https://www.confluent.io/blog/kafka-fastest-messaging-system/?utm_medium=sem&utm_source=google&utm_campaign=ch.sem_br.nonbrand_tp.prs_tgt.kafka_mt.mbm_rgn.latam_lng.eng_dv.all&utm_term=%2Bkafka%20%2Brabbitmq&creative=&device=c&placement=&gclid=Cj0KCQjwnqH7BRDdARIsACTSAduPuqaWmf9xLnEL4Bx9tM-g580zL3zvN5X04LpZFvcNCCpN6Bp3skEaAqk7EALw_wcB): Nesse benchmark podemos notar alguns pontos importantes sobre decisão de solução baseado no volume de mensagens. Acima de 38MB/s throughput devemos desconsiderar o RabbitMQ (ou abrir mão do recurso de mirror que garante tolerância a falha das mensagens), [existe um artigo da google](https://cloudplatform.googleblog.com/2014/06/rabbitmq-on-google-compute-engine.html) mostrando os resultados de 1MM msg/s mas não vi números e resultados que possam embasar o contra-argumento. Abaixo de 38MB/s (muitas soluções com recursos dedicados podem demandar uma taxa baixa de throughput), foi visto que a solução do RabbitMQ oferece menor latencia, e pela sua simplicidade, pode ser uma solução melhor. Um detalhe também a ser mencionado é a necessidade de ter reprocessamento de mensagens consumidas, se a demanda existir, o RabbitMQ não oferece tal suporte. Por Último, acabo por descartar o Pulsar que foi alvo do benchmark por fatores como arquitetura mais complexa, e resultados inferiores do RabbitMQ, e tradeoffs complicados durante sua otimização, que pode resultar e complexibilidade de manutenção.

* [Pull vs Push consumer methods](https://blog.knoldus.com/kafka-consumer-push-vs-pull-approach/): Ótimo para entender que no pull method a responsabilidade fica maior no broker, que tem a responsabilidade de gerenciar as mensagens para seus assinantes. Contra o push que concentra a responsabilidade de gerenciamento pelos workers que terão que periodicamente extrair as mensagens em fila.

* [Artigo da Google cloud alegando capacidade de 1MM msgs/s com RabbitMQ](https://cloudplatform.googleblog.com/2014/06/rabbitmq-on-google-compute-engine.html): O artigo acaba se tornando uma propaganda rasa, e sem detalhes, o que pode fazer questionar como isso é possível dado limitações do próprio RabbtiMQ (talvez eles tenham implementado outra solução fora do vendor para tolerância a falha, conforme o primeiro artigo menciona).

Os artigos seguintes abre a mente para existencia de um protocolo chamado Open Messaging, movimento levantado por algumas clouds parceiras para reduzir a camada de vendor lock, unificando drivers para que existe interoperabilidade, e facilidade de lidar tanto quanto troca fácil entre as tecnologias, quanto uso em caso de fail-over em cenários multi-cloud.