![Cover image for [PT-BR] Shoryuken Vs Sidekiq](https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fhm3ly16sr2lmoie1q9am.jpg)
Quando pensamos em processamento em background no mundo Ruby, levamos em conta atualmente com algumas Gems que fazem esse trabalho. Atualmente as que mais se destacam é a Shoryuken e a Sidekiq, e nesse post vamos ver quais são suas diferenças e quando usar cada uma delas.
(Esse artigo leva em conta apenas o Sidekiq em sua versão gratuita)
Sidekiq
Visto que a Gem mais velha é a Sidekiq, é importante olharmos para ela primeiro e entender qual é a função que ela desempenha.
Diferente da Resque, a Sidekiq veio com a ideia de processar os jobs de forma concorrente usando threads. Antes era necessário aumentar o número de processos, para conseguir processar mais jobs, de forma que era usado mais memória.
Mas também há semelhanças com o Resque, uma delas é o uso do Redis para armazenar e processar os jobs. Por ser um banco in-memory, tanto a escrita como sua leitura são bem rápidas, já que essas operações serão feitas apenas sobre a memória RAM.
Levando em conta esses pontos, porque usar o Shoryuken? O que ele entrega, que o Sidekiq não entrega (pelo menos na versão Free)?
Shoryuken
A principal diferença entre o Shoryuken e o Sidekiq está no armazenamento e processamento dos jobs. O Shoryuken usa o serviço SQS da AWS, ou seja, não temos que configurar e manter uma instancia do Redis, todo esse trabalho fica a cargo da AWS.
Por que usar o SQS?
Segundo a própria AWS os beneficios de se usar o SQS são:
Segurança: você controla quem pode enviar e receber mensagens em uma fila do Amazon SQS. Você pode optar pela transmissão de dados sigilosos protegendo o conteúdo das mensagens em filas por meio da criptografia do lado do servidor (SSE) gerenciada pelo Amazon SQS ou das chaves de SSE gerenciadas no AWS Key Management Service (AWS KMS).
Durabilidade: para garantir a segurança de suas mensagens, o Amazon SQS as armazena em vários servidores. As filas comuns são compatíveis com a entrega de mensagens pelo menos uma vez, e as filas FIFO são compatíveis com o processamento de mensagens exatamente uma vez e com o modo de alto throughput.
Disponibilidade: o Amazon SQS usa infraestrutura redundante para fornecer acesso altamente simultâneo às mensagens, além de alta disponibilidade para produzir e consumir mensagens.
Escalabilidade: o Amazon SQS pode processar cada solicitação em buffer de forma independente, escalando de forma transparente para lidar com qualquer aumento ou pico de carga sem nenhuma instrução de provisionamento.
Confiabilidade: o Amazon SQS bloqueia suas mensagens durante o processamento, para que vários produtores possam enviar, e vários consumidores possam receber, mensagens ao mesmo tempo.
Personalização: suas filas não precisam ser exatamente iguais. Você pode definir um atraso padrão em uma fila, por exemplo. Você pode armazenar o conteúdo de mensagens maiores que 256 KB usando o Amazon Simple Storage Service (Amazon S3) ou o Amazon DynamoDB, com o Amazon SQS mantendo um ponteiro no objeto do Amazon S3, ou pode dividir uma mensagem grande em mensagens menores.
E o melhor, temos 1 milhão de requests grátis para cada mês de uso!
Desempenho
Assim como o Sidekiq, o Shoryuken também utiliza de threads para processar suas mensagens. Há um benchmarking de um artigo que li, mostrando que há um pequena vantagem do Sidekiq sobre o Shoryuken, porém não acredito ser um ponto tão importante quando vamos escolher entre um dos dois.
Armazenamento
Quando usamos o Redis para armazenar os nossos jobs, precisamos ter em mente que esse banco de dados PODE estar apenas na memória RAM. Falo "PODE", porque existe algumas features do Redis que é possivel configurar-lo para que armazene o que está na RAM para o disco rígido. Caso aconteça da instância que está rodando o Redis morra, podemos perder jobs importantes que não foram processados.
Já para o SQS não temos que nos preocupar com isso, poís é garantido pela AWS que não iremos perder de forma alguma nossas mensagens.
Escalabilidade
Outro ponto que temos que levar em conta é a escalabilidade.
Se houver um pico de usuário que não foi planejado anteriormente, o seu sistema está pronto para continuar atuando da mesma maneira em relação ao processamento em background?
Quando usamos o Redis para guardar nossos jobs, temos que nos preocupar com isso.
Já quando usamos o SQS não é necessário, pois de novo, a AWS garante que irá atender todos os produtores e consumidores da fila, mesmo quando houver picos de acesso.
Conclusão
A decisão entre Shoryuken e Sidekiq está mais atrelada a Redis e SQS.
Para decidir qual das duas GEMs usar, deve-se levar em conta o quão importante é não perder o job que será enfileirado e processado.
Além de também levar em conta de há hoje um time que irá conseguir dar manutenção necessária, para que no caso do Redis, não tenha grandes problemas.
Top comments (0)