Поставете проксито на всяка задача на Guzzle върху асинхронната операция, която пулът стартира. В съществуваща настройка на клиента използвайте фабрики за обещания:

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

Всяка валидирана задача предоставя дестинация и прокси. За разрешена публична заявка HTTP кандидат от списъка с HTTP проксита може да предостави прокси URL на тази задача без идентификационни данни; изборът се извършва преди фабриката ѝ да се изпълни. PSR-7 заявката описва HTTP съобщението, докато тези опции за изпращане управляват транспорта. Отпечатването или запазването на стойност на прокси до съобщението не може да конфигурира операция, която го изпраща по друг начин.

Върнете requestAsync() от фабриката. Извикването на синхронния request() там може да блокира, докато пулът се опитва да стартира паралелна работа.

Добавете обратни извиквания за изпълнени и отхвърлени резултати чрез съществуващата обработка на приложението. Запазете ключа на задачата, идентификатора на избраното прокси и номера на опита и в двата изхода; редът на завършване се различава от реда на въвеждане. Не избирайте тайно друга крайна точка във фабриката, след като вече е записана една за задачата.

Стойността за паралелност ограничава работата на този пул. Няколко задачи, избиращи едно ограничено прокси или акаунт, все още може да изискват отделен бюджет за тази крайна точка.

Тълкувайте резултатите по етапи: отхвърляне на дестинацията, удостоверяване на проксито и таймаут на връзката са различни изходи. Опциите за изпращане, запазени със задачата, показват кой маршрут е дал всеки резултат.

Подобни статии