Conteúdo original em https://twitter.com/zanfranceschi/status/1574848219833462784
Ei dev,
Quando estiver trabalhando com filas e bater aquela dor de barriga porque as mensagens não estão chegando em ordem e isso for um problemão, eu tenho uma alternativa relativamente simples pra você!
Cola mais pros detalhes!
cc @sseraphini
↓
Primeiro, vamos pensar num cenário onde a ordem da chegada das mensagens importa.
Extrapolei o diagrama de sequência, mostrando dois fluxos em um – publicação/consumo das mensagens –, para simplificar a linha do tempo dos acontecimentos.
Aqui, apenas o caminho feliz é mostrado.
Só que problemas acontecem e pode rolar da mensagem do pedido chegar antes da mensagem do seu usuário correspondente! E agora?! 😱
Uma série de coisas pode ter ocorrido:
Mensagens de usuários cadastrados podem ser lentas pra processar.
A publicação do usuário cadastrado pode ter tido um problema.
Num cenário de consumo paralelo das mensagens, a ordem calhou de estar incorreta.
Etc.
C'est la vie.
Agora que você entendeu o problema do consumo fora de ordem das mensagens, antes de ler o próximo tweet, pára e pensa como resolveria isso.
Sua ideia ficou muito mirabolante ou ficou simples? Já passou por esse problema? 👀
Como disse anteriormente, a alternativa aqui sugerida é simples. E o primeiro passo é devolver a mensagem para um canal (fila/tópico) de retry.
Cada middleware possui especificidades, mas a ideia central é a mesma para todos.
Essa mensagem deve ficar nesse canal (tópico ou fila) por um tempo configurável – segundos, minutos, horas, etc.
Após esse TTL (time to live – expiração) ocorrer, o consumidor, de alguma forma, deve processar novamente essa mensagem.
Esse passo pode se repetir algumas vezes.
Essa retentativa pode ser via canal original ou canal de retry – depende do middleware e de detalhes de implementação.
Não é uma solução computacionalmente eficiente, mas é de fácil implementação pois reusa a infraestrutura existente de filas e mantém os consumidores stateless.
Novamente, a ideia central é devolver para o middleware de mensagens/streaming as mensagens que não foram possíveis de serem processadas para que estas voltem posteriormente ao consumidor que a devolveu. Eventualmente, a ordem das mensagens ficará correta e tudo se encaixará.
Alguns pontos importantes:
Cuidado com a quantidade de retries – sempre coloque um limite.
Calibre com carinho o intervalo das retentativas – cuidado para não transformar os retries num auto-ataque!
Não use para casos em que pouco lag for essencial.
E o mais importante, procure entender como paralelismo, multithreading, altos volumes, etc. impactam em soluções de processamentos assíncronos usando filas/tópicos. Experimente, estude, faça POCs.
E não canso de recomendar Enterprise Integration Patterns para esse assunto.
Obrigado demais pra você que chegou até aqui! ♥️
Se curtiu o conteúdo, dá um RT no primeiro tweet, like, comenta, compartilha, mostra pros seus filhos, vizinhos, e no grupo do zap. 🤭
Top comments (0)