Como consumir as mensagens de forma escalável
PS: não é a solução correta para grandes projetos ou que tenham um grande volume de mensagens.
Se não é adequado para grandes volumes não é escalável
1
1
Realmente você tem razão se seguirmos o conceito de escalável, concordo.
Mas baseado no que já vi as pessoas sempre que vão construir um sistema sempre pergunta quantidade de usuários e quantidade para criar algo que seja “escalável” para aquele cenário. Exemplo: o Duolingo que tinha uma solução push notification era escalável para demanda que eles tinham, mas precisaram melhorar a solução de push notification para publicar 4.000.000 mensagens em +/- 5 segundos. Link do vídeo: https://www.infoq.com/news/2024/04/qcon-london-duolingo-super-bowl/ recomendo, pois aprendi muito com esse material.
No cenário do post o que eu faria se precisasse criar algo que precisa processar mais mensagens:
- 1º opção: incrementar o hardware do postgres que é a queue, mas você vai ter custo, então não será 100%
- 2º opção: usar unlogged queue, pois usa unlogged table que pula a operação que garante a durabilidade das informações, então se o banco reiniciar você perde as mensagens, mas você vai conseguir publicar mais mensagens na queue.
- 3º opção:
- Criar 5 contas diferentes no Supabase
- Criar 5 contas diferentes no Val.town. PS: no código pega até 8 mensagens da fila para processar, então pode ajustar o cronjob no Supabase para executar a cada 8 segundas para permitir acumular mensagens
- Criar a mesma queue nas 5 contas
- Adiciona a função do postgres nas 5 contas, é para cada url que será chamada na função você usa a link da aplicação serverless de um conta diferente do Val.town.
- Configurar o cronjob para chamar a função criada no passo anterior.
- Na hora de publicar você distribui essa demanda entre as 5 queues usando algo como round-robin algoritmo para ficar alternando entre as queues.
Então se tiver um cenário como: 1 mensagem por segundo que seria 1 x 60 x 60 x 24 é igual 86.400 mensagens por dia, então com os ajustes da 3º opção você poderia processar 432.000 por dia.
Mas você pode combinar a 1º e 3º opção, pois se incrementar o hardware do postgres você pode ter mais conexões com o banco de dados, então você poderia adicionar mais cronjobs que irão disparar mais as functions do Valtown ao mesmo tempo sem problema de limite de conexões com o banco.
1
Aqui tem outra questão, o postgres pra mensageria é lento.
Criar 5 contas diferentes no Supabase
Tudo isso se resolveria com uma instância pequena de RabbitMQ.
No meu pc (8 cores) consegui chegar a 4k/sec sem qualquer otimização.
A minha maior crítica aqui é usar uma ferramenta pra uma coisa que ela não foi proposta.
Postgres é excelente para - guardar dados -, e usar para outra finalidade exigem que sejam feitas gambiarras.
Já vi muita gente tentando usar para cache, desativando um monte de coisa, fazendo tabela customizada com um monte de regra sendo que é só subir uma instância de redis ou memcached.
Estou demonizando o fato de usar o postgres para fila? não, uso muito em projetos pequenos, que não precisam de escala. faço gambiarras? não, minha tabela de fila é uma tabela comum com (id, queue, payload, available_at), só isso.
Se eu uso porque estou criticando? pelo fato de você apresentar uma solução (que é uma gambiarra ou que não é a proposta correta dessa solução) como a solução correta e escalável
PS: todas as minhas críticas são construtivas, não tenho o objetivo de denegrir ninguem, apontar defeitos. Só estou expressando minha opinião
1
Boa noite!
Relaxa, você realmente está certo em vez de ficar criando gambiarra será melhorar usar um solução adequada como o Rabbitmq.
Eu acredito que acabo insistindo nessas gambiarras devido ao fato que todos os projetos que me lembro de ter trabalhado sempre tinha um budget baixo, então nunca consegui usar uma infraestrutura muito robusta para criar algo realmente escalável como estamos conversando aqui. É acredito que pode ser a situação de algumas pessoas na comunidade.
Gostei do seu questionamento, pois me fez pensar... se eu tivesse usando Postgresql como fila é precisar fazer essa solução para processar um demanda 5 vezes maior, como eu faria, então no final essa discussão foi muito legal pois foi um aprendizado para mim. Devido ao fato ter aprendido como posso minha solução(Postgresql como fila) lidar com mais mensagens e aprendi que o Rabbitmq pode lidar com um quantidade muito boa de mensagens por segundo.
Há possibilidade de você fazer um post ou gravar um vídeo explicando sobre como configurar o Rabbitmq para lidar com 4k de mensagens por segundo, exemplo publicando 4k por segundo na fila e consumindo 4k de mensagens por segundo? Pois acredito que seria um ótimo material para todos da comunidade, inclusive eu.
2
Eu acredito que acabo insistindo nessas gambiarras devido ao fato que todos os projetos que me lembro de ter trabalhado sempre tinha um budget baixo
Não estou demonizando esse uso. Gambiarras são necessárias!
A gente precisa saber que é uma e porque está usando.
O que mais vejo no desenvolvimento é o preciosismo: Pessoas que criam uma solução e acham que ela é a mais perfeita para todos os casos.
Acredito que esse é o maior mal que a tecnologia pode ter. Por um apego emocional a pessoa passa a ignorar qualquer solução que pode ser melhor.
Há possibilidade de você fazer um post ou gravar um vídeo explicando sobre como configurar o Rabbitmq
Sinceramente o Get Started do RabbitMQ é incrível, ele explica os fundamentos base da ferramenta de forma prática em diversas linguagens diferentes.
Como eu consegui tantas mensagens por segundo só com o meu pc? fazendo basicamente um HelloWorld com muitos produtores e consumidores.
Claro que uma aplicação real vai exigir muito mais recurso (até porque uma fila de int não é muito útil numa aplicação real, porém depende)