Metti il proxy di ogni job Guzzle sull'operazione asincrona avviata dal pool. All'interno di un client già configurato, usa le factory di promise:

$operations = function () use ($client, $jobs) {
    foreach ($jobs as $id => $job) {
        yield $id => function () use ($client, $job) {
            return $client->requestAsync('GET', $job['url'], [
                'proxy' => $job['proxy'],
                'timeout' => 20,
            ]);
        };
    }
};

$pool = new GuzzleHttp\Pool($client, $operations(), [
    'concurrency' => 4,
]);
$pool->promise()->wait();

Ogni job validato fornisce una destinazione e un proxy. Per una richiesta pubblica consentita, un candidato HTTP dalla lista di proxy HTTP può fornire l'URL proxy senza credenziali di quel job; la selezione avviene prima che la sua factory venga eseguita. Una richiesta PSR-7 descrive il messaggio HTTP, mentre queste opzioni di invio controllano il trasporto. Stampare o memorizzare un valore proxy accanto al messaggio non può configurare un'operazione che lo invia in un altro modo.

Restituisci requestAsync() dalla factory. Chiamare request() sincrono lì può bloccare mentre il pool tenta di avviare lavoro concorrente.

Aggiungi callback per esiti completati e rifiutati usando la gestione già presente nell'applicazione. Conserva la chiave del job, l'identificatore del proxy scelto e il numero del tentativo in entrambi gli esiti; l'ordine di completamento differisce dall'ordine di input. Non scegliere di nascosto un altro endpoint nella factory dopo averne registrato uno per il job.

Il valore di concorrenza limita il lavoro di questo pool. Più job che scelgono un unico proxy o account vincolato possono comunque richiedere un budget separato per quell'endpoint.

Interpreta i risultati per fase: rifiuto della destinazione, autenticazione del proxy e timeout di connessione sono esiti diversi. Le opzioni di invio conservate con il job mostrano quale percorso ha prodotto ogni risultato.

Articoli correlati