Como garantir a distribuição eqüitativa de mensagens SQS em uma configuração de sistemas distribuídos?

Eu tenho vários servidores, cada um com um script pesquisando uma fila SQS [todos pesquisando a mesma fila].

Portanto, existe alguma maneira de garantir uma distribuição equitativa de mensagens para todos esses clientes [ou seja, meus servidores de trabalho aqui]. Por exemplo, se houver 100 mensagens na fila, 20-20-20-20-20se houver 5 trabalhadores e assim por diante.

O AWS ELB (Elastic Load Balancer) pode me ajudar a fazer isso? Se sim, então como? Caso contrário, existe um serviço alternativo no ecossistema da AWS que pode me ajudar a fazer isso?

Ou estou pensando demais nisso? Quero dizer, isso pode ser resolvido diretamente no script de pesquisa? [Lembre-se das condições de corrida envolvidas devido a vários clientes pesquisando uma única fila]

Se houver 100 mensagens na fila e 5 consumidores, a distribuição inicial não passará de 10-10-10-10-10.

Uma única resposta nunca pode retornar mais de 10 mensagens .

Parece um problema.

As condições de corrida relacionadas a vários consumidores também devem ser um problema. O SQS foi projetado para vários consumidores simultâneos.

Use pesquisas longas e um cronômetro de espera máximo de 20 segundos e se surpreenda. (Não, uma espera de 20 segundos não atrasa as mensagens em 20 segundos. Não as atrasa. Você precisa vê-lo em ação para realmente entender como funciona.)

Você definitivamente está pensando demais em algumas coisas, eu suspeito.

Uma boa arquitetura de como você usa filas SQS resolverá seus problemas. Se considerarmos que existem, digamos, 3 minutos de processamento por mensagem, você quase poderá garantir uma distribuição igual das mensagens, pois isso é muito grande comparado ao tempo necessário para pesquisar na fila, se você excluir a mensagem da fila somente após foi processado.

Esteja ciente de que existe um limite de tempo limite de visibilidade de 12 horas em qualquer mensagem SQS; portanto, se você não excluí-lo até esse momento, ele aparecerá novamente na fila. Eu suspeito que isso provavelmente não seja uma limitação para você, mas lembre-se disso.

A pesquisa longa é sempre benéfica, pois resulta em um desempenho superior a um custo reduzido para a maioria dos casos de uso. Infelizmente, você não pode controlar o número de mensagens que cada trabalhador recebe da fila devido à natureza distribuída da fila. Mas existem algumas soluções alternativas do lado do cliente que podem ajudá-lo a equilibrar a carga para os trabalhadores.

Então, foi isso que fizemos como solução alternativa para isso:

Como uma das soluções alternativas, o script de poller pode controlar o número de mensagens que cada trabalhador recebe. Um limite pode ser definido para o número máximo de mensagens que cada trabalhador pode manipular. Esse limite pode ser um valor dinâmico e provavelmente seria ApproximateNumberOfMessagesVisibledividido pelo número de pollers / scripts de poller. Em seguida, você pode manter o tempo limite da visibilidade com qualquer valor mais baixo. Se todos os scripts do poller fizerem uma sondagem longa ao mesmo tempo, um dos pollers agarra a mensagem, decide que está sobrecarregado com base no limite, não exclui a mensagem, a mensagem volta à fila e pode ser capturado por outros pesquisadores que ainda têm capacidade para capturar a mensagem. O parâmetro threshold pode ser ajustado para atender às necessidades do aplicativo.

Além disso, ter um mecanismo de failover também ajudaria, como a descrição das respostas neste post . No entanto, não posso me permitir ter filas de failover em uma arquitetura distribuída, pois isso aumentaria a complexidade. Portanto, a solução alternativa acima foi uma ideia melhor para minha equipe.