Placez le proxy de chaque job Guzzle sur l'opération asynchrone lancée par le pool. Dans une configuration de client existante, utilisez des fabriques de promesses :

$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();

Chaque job validé fournit une destination et un proxy. Pour une requête publique autorisée, un candidat HTTP de la liste de proxys HTTP peut fournir l'URL de proxy sans identifiants de ce job ; la sélection a lieu avant l'exécution de sa fabrique. Une requête PSR-7 décrit le message HTTP, tandis que ces options d'envoi contrôlent le transport. Imprimer ou stocker une valeur de proxy à côté du message ne peut pas configurer une opération qui l'envoie autrement.

Renvoyez requestAsync() depuis la fabrique. Appeler request() synchrone à cet endroit peut bloquer pendant que le pool tente de lancer du travail concurrent.

Ajoutez des rappels pour les résultats remplis et rejetés en utilisant la gestion existante de l'application. Conservez la clé du job, l'identifiant du proxy choisi et le numéro de tentative dans les deux issues ; l'ordre d'achèvement diffère de l'ordre d'entrée. Ne choisissez pas secrètement un autre point de terminaison dans la fabrique après en avoir enregistré un pour le job.

La valeur de concurrence borne le travail de ce pool. Plusieurs jobs choisissant un même proxy ou compte contraint peuvent encore exiger un budget distinct pour ce point de terminaison.

Interprétez les résultats par étape : le rejet de destination, l'authentification du proxy et le délai de connexion sont des issues différentes. Les options d'envoi conservées avec le job montrent quelle route a produit chaque résultat.

Articles similaires