Scraping de larga escala com Spider Unlimited
A ferramenta é basicamente um wrapper em torno do Scrapy que remove as rate limits padrão e permite rodar milhares de requests por segundo sem se preocupar com throttling manual. A ideia começou como um projeto interno num estúdio de dados em Lisboa, cresceu no GitHub e hoje aparece em vários tutoriais porque resolve o problema mais chato do scraping: a gestão de concurrency.
O que é spider unlimited na prática
É um módulo que substitui o scheduler do Scrapy por um version com backpressure adaptativo. Em vez de deixares o Scrapy choramingar quando o target rate-limiting, o spider simplesmente ajusta o throughput dinamicamente conforme a resposta do servidor. Se o site responde rápido, sobe. Se começa a dar 429 ou timeouts, desce. Tu só configuras os limites superiores e inferiores e deixas o módulo gerir o resto. Eu configurei isto num projecto de monitorização de preços de um catálogo de 140 mil produtos. O scraper tradicional travava ao fim de 3 horas, ou por causa de bans, ou porque a fila de requests enchia até estourar a memória. Com o módulo adaptativo, rodou completo em cerca de 11 horas num servidor de 4 vCPUs e 8 GB RAM. Sem intervenção manual.
Como instalar e configurar
A instalação é direta: pip install spider-unlimited. Depois adicionas ao settings.py. O ficheiro de configuração fica numa pasta do projeto, tipo configs/my_spider.yaml. Não precisas de mudar o código do spider, apenas sobrescreves os settings que o módulo lê. Os parâmetros principais são max_concurrency, min_concurrency, response_time_threshold e error_rate_window. O max_concurrency define o teto de requisições simultâneas. O response_time_threshold é o tempo máximo em milissegundos que uma resposta pode demorar antes de o sistema reduzir a velocidade. O error_rate_window controla a janela de tempo para detectar bursts de erros e reagir.
O que a maioria dos guias não diz é que o modulo não lida bem com sites que mudam o rate limit de forma imprevisível. Num caso real, encontrei um e-commerce que ia reduzindo gradualmente os limites a cada hora durante o dia. O spider entrou num loop de ajuste constante, nunca estabilizava, e a taxa de sucesso caiu para 62%. A solução foi definir o error_rate_window para 600 segundos e adicionar um handler customizado que fazia um downgrade mais agressivo quando via padrões cíclicos. Isso elevou a taxa de sucesso para 89% no resto do crawl.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Configuração avançada para casos reais
Cookies e sessões persistentes
O Spider Unlimited suporta persistência de sessões via cookie jars. Se o alvo exige login ou mantém estado entre requests, precisas de configurar o persist_cookies como True e apontar para um ficheiro JSON. Sem isto, cada spider restart começa do zero, o que significa perder toda a sessão estabelecida e ter de refazer login.
Rotacionação de headers e proxies
O modulo tem suporte nativo para rotate_headers e proxy_pool. O rotate_headers gera variações aleatórias de User-Agent, Accept-Language e Accept-Encoding entre requests. O proxy_pool funciona com listas externas ou IPs rotativos de serviços como Bright Data ou Smartproxy. Configuras ambos no mesmo ficheiro yaml, mas há um detalhe: se usares proxy_pool com max_concurrency alto, precisas de bastante memória. Cada conexão ocupa espaço no pool e com 2000 conexões simultâneas, o consumo sobe rapidamente para 2-3 GB.
Problemas comuns que ninguém menciona
O primeiro problema é que o modulo não detecta bloqueios por IP de forma tão eficiente como se espera. Às vezes o servidor responde com 200 OK mas retorna conteúdo vazio ou incompleto. O spider continua a enviar requests, acha que está tudo bem, e gasta tempo valioso. Eu resolvi isso com um callback post_process que valida o tamanho e estrutura da resposta antes de considerar o request como bem-sucedido. O segundo problema é a gestão de memória em crawls longos. O Scrapy já é conhecido por acumular memória ao longo do tempo, e o Spider Unlimited herda isso. Depois de 24 horas de execução contínua, um spider que começava com 800 MB podia estar em 4 GB. A solução mais simples é configurar auto_restart a cada 12 horas e processar os resultados em batches. Não é elegante, mas funciona.
Alternativas quando o Spider Unlimited não serve
Se o teu alvo usa técnicas avançadas de anti-bot como JavaScript rendering complexo, fingerprinting de navegador ou challenges tipo Cloudflare Turnstile, o modulo não vai ajudar muito. Nesse caso, ferramentas como Playwright com configurações de stealth ou serviços especializados como ScraperAPI fazem melhor trabalho. O Spider Unlimited é excelente para crawls tradicionais, massivos e baseados em HTTP, mas não é varinha mágica. Para quem quer começar, o melhor caminho é pegar num spider Scrapy existente, adicionar o modulo aos requirements, criar o ficheiro de configuração yaml com os valores padrão, e testar num subconjunto pequeno de URLs. Depois é ajustar os parâmetros conforme o comportamento do alvo. O módulo compensa o esforço inicial em crawls grandes, onde a diferença entre uma configuração manual e o adaptive throttle pode ser a diferença entre terminar o projeto ou abandoná-lo.
Download e documentação
O código fonte está disponível no repositório oficial do projeto no GitHub. A documentação cobre todos os parâmetros de configuração, exemplos práticos, e troubleshooting. Recomendo ler as issues abertas antes de implementar em produção, porque muitos edge cases já foram discutidos lá e as soluções estão disponíveis sem precisar de abrir tickets. Se estiveres a lidar com um projeto de scraping de grande escala, vale a pena experimentar. O tempo perdido com gestão manual de rate limits e bans é significativo, e este módulo elimina boa parte desse trabalho. Só lembra-te de monitorizar a memória e validar respostas, caso contrário vais descobrir tarde demais que o crawler está a processar conteúdo incompleto enquanto consome recursos.
